On Fri, 2004-04-23 at 20:02, David Chan wrote: > Perhaps I'll add my nickle's worth here. I have personally come to > believe that an Open Source project is characterized by an openness to > collaborate with others. If one is to work on an OS project alone then > gives it away for free - that makes the person a Santa Claus!
That's the FOSS orthodoxy. At best it needs qualification, and at worst
it is too restrictive, IMHO.
I don't disagree with respect to the centrality of collaboration in FOSS
models of production (note the deliberate plural - there is no one right
way). However, valid open source "collaboration plans/models" (akin to
"business plans/models" in the commercial world) include:
a) the orthodox "bazaar" model of "release early and often" and "develop
in a fishbowl", and open invitation for contributors
b) a collaborative (or highly consultative) requirements gathering and
functional design process, but detailed design and implementation
(cutting the code) done by a small, closed team working in private
between project releases (or until the first release).
c) a small team or individual just doing their own thing, usually to
scratch their own itch, but having the sense to see that what they are
doing might benefits others too (but maximising benefit or utility of
their work for others is not their primary goal, only a secondary one).
All of these collaborative plans/models share two very important
features:
1) Due to the use of open source licensing of the results, they are all
vastly better than any closed-source model of software production.
2) Due to the use of open source licensing, if you don't like the
"collaboration plan/model" used by the project, then you are free to
fork the project and implement your own, preferred collaboration model.
Indeed, many projects which use model c) fully intend that someone else
pick them up and undertakes collaborative refinement or development, or
they intend to switch to a more collaborative model once some basic
infrastructure or proof-of-concept is established. Indeed, I would argue
that there are some dangers in too much collaboration too early:
collaborating over a blank sheet of paper is rarely productive. better
if someone brings an idea or vision (or a working prototype) tot he
table as the starting point for collaboration. As Joseph points out
("the perfect is often the enemy of the good [enough]"), the tricky bit
is in deciding when to "open up" a project.
Finally, sometimes projects have tight deadlines and/or small
windows-of-opportunity. Collaboration takes time and resources, and my
just not be possible given the project constraints. But that doesn't
mean that such projects are not legitimate FOSS projects.
> I have in
> fact learned that there are many who have the good intention to share
> their code but few who truly embrace the OS community spirit. I
> understand Horst's frustration (and others). The fact that we keep
> hearing that a certain OS will some day be released but in the mean
> time it's not open for collaboration makes one wonder if it truly is an
> OS project at all.
I think the essence of the FOSS ethos is freedom and lack of compulsion.
If some people who are working on open source code don't wish to engage
in open collaboration, or don't have teh time or resources to do so,
then that's their business. The only qualification I would make is that
if an open source project is funded by public monies, then the
"collaboration plan" should be clearly part of the project
specifications at the outset, so that everyone understands what is
intended. Articulation of a collaboration plan by privately funded FOSS
projects is also a good idea.
--
Tim C
PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
or at http://members.optushome.com.au/tchur/pubkey.asc
Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0
signature.asc
Description: This is a digitally signed message part
