in reply to P5EE ... get involved!

I don't mean to rain on anyone's parade, but when this came up in chatter I had some thoughts that people thought should be put into a post.

I read the previous announcement. I read this one. I looked at a couple of pages, and I decided not to be involved. I have more than a few reasons for this, this is just meant to give some of them.

  1. I don't think the project is well-defined.

    What does "Enterprise" mean? There are a million and one different definitions of what it could mean, everyone has their own. It has long been recognized in project management (not just software - this comment applies to everything from business plans to military exercises) that you need to have a clear project definition. Unless the statement makes it clear both what does and (more importantly) what does not belong, it is unlikely to be useful.

  2. Who is the customer of the project?

    The history of software and other projects shows that when you design in a vacuum you produce designs which are not usable by the end user. It is important to know - early - who the project is for and to involve end users early in the design process. Saying, "It is for everyone" sounds nice and all, but it has not tended to work for anyone else, and probably won't this time.

    It is OK to have different customers for different aspects of the larger project. But it is important to start defining and factoring that early, and the deliverables for different people should be different. For instance you might have an advocacy project whose job is to clearly define for management the case for using Perl, and for using your particular pre-packaged set of recommendations. Those documents should not be merged with the installation information for sysadmins. Those again are not the same as the tutorials for programmers who need to learn how to put things together.

    Two useful places to look for models are how Eric Raymond managed to aim at multiple audiences with Another is the management of the Debian project. The latter is particularly well-executed, and anyone who wants to manage an open source project that repackages the output of other packages into a coherent distribution would be well-advised to start by looking at them. As usual when trying to copy a good model, you want to start by making your own theories about what makes them work (and where they don't work as well as you would like), then act according to your theories.

  3. Don't focus on "should".

    A famous experiment that I heard about years ago is that people who are being lectured about how they should be able to lift more weight test as far weaker than when they are being told that they can lift more.

    The moral is that should is a very poor long-term way of motivating people. It tends to make them feel guilty, and when guilt is overused it quickly turns into demotivating resentment. And the reaction is actually amazingly fast. Simply hearing the word once causes a negative reaction that most people aren't even conciously aware of.

    All of the articles I have seen here encouraging people to get involved say that people should get involved because it is really important that they do. The same focus is very clear in the vision statement at Every single point starts off with a should.

    The particular ineffectiveness of the use of "should" to motivate open source developers is emphasized by Bruce Perens' famous complaint that leading Debian was like herding cats. It is underscored by the fact that the first time I saw the project announced, I barely got through the vision statement when I filed this in my personal circular bin and went on to something that was more fun.

  4. How are disagreements on design vision to be handled?

    There are two issues here. The first is that you will inevitably have disagreements between developers on what the best architectures are. When that happens, how do you decide who wins? That is faced by all projects, and is not the one that concerns me here.

    The one that concerns me is how they intend to address the case where management hears about this thing, wants to use it, but wants it to be different.

    This is not a small issue. Remember that management likes to have nice little hierarchies, and with management on top. Plus no two businesses are the same. Most vendors therefore devote considerable energy to making their enterprise systems fit customers' businesses rather than vice versa. An idea of how much this happens can be seen in an email written by a friend of mine. Among other conclusions, Karsten found that of the top 50 software firms, only 4 derive the bulk of their revenues from software. The big one being, of course, Microsoft with 86% of the total reported software revenue. For most software companies, most of their revenue is in consulting, and a very big chunk of that comes from trying to fit their "enterprise software" to the existing enterprise.

I could go on, but it would be more of the same.

No matter how much I may or may not agree with the idea that it is good to encourage the use of Perl in the commercial world, I have fundamental questions about how effective this particular project will be at it, and even bigger ones about whether contributing it is really how I want to spend my time.