This post originated from an RSS feed registered with Java Buzz
by Brian McCallister.
Original Post: Open Development
Feed Title: Waste of Time
Feed URL: http://kasparov.skife.org/blog/index.rss
Feed Description: A simple waste of time and weblog experiment
Gianugo kicked off good
discussion on a mailing list (message reposted to the
Feather blog). It gets at an idea that has been floating around
for
a
good
while, that Open Source does not equate to Open Development, and
while the difference is glaring obvious to folks who have been
around open source for a while, it is not so to many others.
Open Development is what people tend to think of with the idealized
view of grassroots (I hate that word) Open Source. Diverse
people working together on a labor of love, probably with some folks
being paid to work on, it others doing it pro bono. Open Development
generally strongly encourages outside contribution, and works to
reduce barriers to participation.
Closed Development, on the other hand, is where the community around
the project discourages outside participation. This could be a
corporate strategy ("lite" open source version, "enterprise"
commercial version; GPL or Commercial dual licensing; maintaining
control of a codebase for a core product offering with a support
revenue based business model), a side effect of circumstances (core
developers all work together, or hack on the project together in a
user group so to participate effectively requires being there).
Most of the high profile open source and free software projects (I
use Open Source so that it is inclusive of non-copyleft licenses,
but I include copyleft licenses in Open Source), which tend to drive
the perceptions of the field. FreeBSD, Apache, GNU/Linux,
PostgreSQL, and many others fit this mold to a T. The perception of
how these projects operate colors the perception of how all open
source projects operate, but it is not a valid comparison in many
cases.
The strengths of Open Community development have been highlighted
for years in much of the FSF literature, the Cathedral and the
Bazaar, and the astounding success of projects such as GNU/Linux
and the Apache HTTPD Server. On the other hand, there is an outright
explosion of Closed Community Open Source emerging over the last
couple years, and the trend is accelerating.
Closed Community projects tend to leave a bad taste in the mouths
many of folks who have been involved with Open Community development
for a while. Much of this is driven by one class of Closed Community
development, explicit attempts at profiteering on the Open Source
name. This was all the rage for a while, with everything under the
sun being "open sourced" under licenses ranging from hideously
broken, to deeply bizarre, eventually mostly settling on
GPL(-ish)/Commercial dual licensing in the tradition of
Sleepycat.
Mostly, despite the bad taste, this was still a good thing in the
short term. It opened up the ability to debug into libraries, make
local modifications, and in some cases lead to open community forks
which went on to become fabulously successful projects after the
parent company tanked. In others, there has been much less success,
for a wide range of reasons.
In other cases, companies have made long-terms bets on the viability
of closed community, open source development. Generally these are
companies with a great deal of open source experience who recruit
developers from open community projects. Some fairly high profile
"open source companies" fit this bill, including MySQL and
JBoss. They are making an interesting play, and I am very curious to
see how the model goes in coming years. By keeping development teams
tight, and ensuring wider channels of communication for developers,
this model can achieve an awful lot very quickly, while still
maintaining many of the advantages of open source. It also provides
an obvious source of support, which is very important to many users.
There are drawbacks to this model in comparison to Open Community
development, however. The viability of the product is tightly tied
to the viability of the company. For non-trivial codebases the
effort for a newcomer to learn it well enough to contribute
meaningfully, without the support of folks who know it already, is
extraordinary enough that it rarely happens in favor of a rewrite
(see Mozilla, and there folks were involved who knew the codebase
intimately). It is, also, much more difficult to leverage the user
base to fuel development as the nature of customers (ones who need
support) who are most appealing from a business sense (with deep
pockets and who really need support as compared to "put out
the fire, okay, thanks, bye") don't general become developer/users,
or if they do, there is often a "no recruiting" policy which
combined with development decisions being made by project managers
leads to a few small patches, and no ongoing growth of the developer
into the project.
When you come to have a hard, architectural, dependency on a project
the differences really starts to stand out. On one hand, with the
closed community style lends itself to a natural monopoly on
support, which for a popular project is a nice position to be in,
and lends stability (or the perception thereof) to the support
option. On the other hand, open communities allow you to actually
delve into the communty yourself, and build up better support
options. Even better, if the primary driver is bought by Oracle the developer base
is not at risk, and at worst a few people stop contributing. In the
good case the developers stick around anyway, and sometimes spin off their own companies around
the product which lost major vendor contributions. The examples go
on, and on.
I have a natural affinity for open communities, I think it is a
better long term model. It is, however, far from cut and dried. The
Really Closed Communities like Splunk (throw it over the wall), and
bait and switch shops are pretty bad; but the developing more or
less in the open, with a closed ocmmunity, and releasing under a
forkable license players... are very interesting. That said, I still
like open communities more =)
Previous Topic
