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.
- 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.
- 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
http://www.opensource.org/. 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.
- 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
http://p5ee.perl.org/. 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.
- 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.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
|