Eugene Leitl wrote:
> Adrian Tymes writes:
> > Management does not completely dissapear, but it mutates...and there is
> > certainly a lot less of it.
>
> I wonder what makes you say that. All successful OpenSource projects
> of the size beyond the trivial are extremely centralistically
> organized. The project can have (very) many contributors, but still a
> single person decides on the architecture issue and which piece of
> code gets incorporated, and which not.
True...almost.
If a large number of the developers get dissatisfied with the decisions
of the manager, any of the developers can take the code base and fork
it. The central manager would have to screw up big time in order to
provoke such a reaction, but it is possible - and that, alone, can keep
the manager honest.
As in proprietary projects, it is possible for the central person to
divide the project into multiple parts, each one headed by a different
person. Or maybe some parts arise naturally, with a de facto leader -
again, just like in proprietary projects, except that "official"
recognition can come from the developers directly even if the central
leader disagrees.
The central manager is motivated by making the project good, rather than
by marketing or sales to *any* degree. Users feed directly back into
the system, rather than going through salespersons' and marketers'
biases. (See, for example, commercial execs who honestly believe that
customers want to put the company's bottom line ahead of utility to
customers, because they're told that by those who report to them, who in
turn think that's what the exec wants to hear and they'd be fired if
they said otherwise.)
Developers can add themselves at whim; management does not have to think
to hire them - or even know that they exist - before the developers can
start making contributions. Developers who do not contribute anything
do not wind up costing the project anything; likewise, the central
manager must be a developer (probably writing code directly, but at
least be technically competent), else few other developers would be
willing to listen. This last one enforces knowledge of how to build a
good system, which is perhaps *the* single most mutating factor
(relative to proprietary development) I've cited...and I'm sure I'm
missing some factors.
> Anarchic software development does not work.
Define "anarchic". No body of law ties, say, Linux developers to Linus
Torvaldis. Linus can not hire or fire developers; he can only make
acceptance of their code more or less likely. (He can't even absolutely
reject software on his own, though his negative review can go a long way
towards rejecting certain code.) Promises, trust, and working code are
all that unify the developers - and this lack of law is, technically,
"anarchy", in the form that some promoters of anarchy envision as their
utopia.
This archive was generated by hypermail 2b29 : Mon Oct 02 2000 - 17:38:26 MDT