This post originated from an RSS feed registered with Java Buzz
by Brian McCallister.
Original Post: Why Apache?
Feed Title: Waste of Time
Feed URL: http://kasparov.skife.org/blog/index.rss
Feed Description: A simple waste of time and weblog experiment
People frequently ask why a project would want to move to
Apache. The most recent case of this
I have run across was in a
thread
on CouchDB's graduation, on Reddit. To answer the question, I'll
take my apache hat off for a moment and put by consumer internet
company architect (who codes as much as I can make the time for!)
hat on.
The biggest benefit, to me, is that Apache provides a known way of
doing things. We (remember, I have my $company_man hat on) don't use
Couch right now (though we have certainly talked about it), but a
major factor if we choose to use it is how the code gets developed,
and how we can influence that in the direction that we need. With
Apache, we know how it gets developed (in the open, all decisions on
public mailing lists) and how to get involved (submit bugs and
patches which will be discussed on the mailing list, if we need more
keep submitting patches until they get tired of applying them and
make me a committer, as committer keep working in the open, etc).
If you need to have influence over the project, say because you are
creating a strategic dependency on it, you absolutely know that
you can gain as much influence over an apache project as your
competence allows. This is crucial, as the alternative is the
willingness to maintain a fork if the developers go berserk, wander
away, which happens. A major part of technology selection is
balancing risks. It is not being totally risk averse, but
it is being aware of the risks in critical dependencies and
making the choice to accept the price if that risk converts into a
liability. Having a guaranteed way to provide continuity to a
project in the face of typical project killers, such as the project
leader leaving the project, trumps merely having freedom to fork.
Previous Topic
