This post originated from an RSS feed registered with Java Buzz
by Brian McCallister.
Original Post: The New Fork
Feed Title: Waste of Time
Feed URL: http://kasparov.skife.org/blog/index.rss
Feed Description: A simple waste of time and weblog experiment
David
and Chris's discussion
( 1, 2, 3, 4,
and 5)
highlights a major shift going on in open source, right now. The
shift: Forking is Good.
Historically, a fork has been seen as a sign of trouble in a
project, and folks have gone to huge and painful means to prevent
forks. Heck, not long ago the blogging rage was about which licenses
helped prevent forks, BSD-style or GPL-style. Things are
changing. It isn't really that new, though...
Aside from the big-obvious (Linux, which has encouraged forking,
well, forever (in internet time)), even staid centralists like
Apache talked
about it as a good and natural thing. In that context it wasn't
supposed to be a fork, though, it was supposed to be "a new
version", and it stayed in the same source tree and was one big
happy project.
At ApacheCon, in New Orleans,
Dirk-Willem asked the key
question, when discussing git, subversion, etc and the ASF -- "are
we shaped by the tools, or do the tools shape us?" Many leapt to say
that we shaped the tools, of course. It is, of course ;-), a
blend. The tools shape the mindset which shapes us who shape the
tools.
Forking is painful because merging changes between forks is
painful. It is seen as a huge duplication of effort, a squandering
of developer time, and a "I'm taking my ball and leaving, thbbft!"
For some high profile things, such as X.org, this has been kind of
true. Many times it can also e irreconilable goals (such as
Dragonfly). Many times, however, it is just "I need something, but a
little different, and the best path for me right now is to take
something and incompatibly change it" (nginx, for example).
Git (and others, but whatever, I am talking about git, and hwile
others support many-repos, only git really expects and
encourages many repos) removes much the effort part from the
forking equation. Github, in particular, as Chris makes clear,
allows for very easy moving of code from fork to fork. Linus, a git
I have never met, wrote software to support how Linux devlopment
works (ie, with Linus as the SCM) automating what he did, and along
the way opened the tooling door for everyone else.
Personally, I love the "please fork my stuff" mindset. I write open
source stuff to solve my problem, and hey, if it solves yours too,
bonus, have fun, don't sue me.. The bonuses add up, which is why I
bother to do it in the open -- people do take it and run. I get
patches, good feature requests, and whole ports of code I wrote and
actively disowned a couple times a week. I always hate telling folks
"I no longer maintain that, some guy named Chris, or maybe Anthony,
took over, I think -- he hasn't made a release yet, though, so not
sure what is up." If it is a bugfix someone sent me, I have done the
spelunking to apply the fix and cut a release on code I expect to
never use again (I take bugs personally), but aside from that it is
"er, yeah, svn is here I think, let me know if you want commit."
There are also projects I use every day and are in a stable state
(jdbi for example). It works great, I
know other folks use it, but frankly, it is just a utility
library. If you need changes, don't wait on me! Git, and something
like github to make it even easier, means I can say "here is the
code, fork it, go to town." A month later when I have spare time I
can pull changes back, or if the forker really takes the ball and
runs with it, I can just start using that code.
Where I think it doesn't work for people is when they have strong
financial or emotional attachement to their code. If you make your
living consulting on OpenWombat and uppity twenty year olds go and
fork it all over, your job just got tougher. Worse, one of these
forks may become more popular than OpenWombat and you won't now own
it.
My personal opinion is to let the best code win, and the best code
is a moving target. Chris's example, in the conversation with David,
assumes the most active code line is the best code. Sometimes this
is true, but more often (in my opinion) the more stable (not
abandoned) code line is probably better. This is kind of Linux vs
FreeBSD (and Linux clearly has won the popular vote) but... FreeBSD
is solid as a brick in a way I doubt Linux will be for a long time
yet, and stabilty trumps features for a lot of things. In a
free-fork world, this difference of opinion is easily resolved, and
the best features of the unstables can flow into the stables much
more easily.
I am fascinated to see the shape of how this evolves. There are huge
social and legal potholes ahead on the new fork, but in the end, as
we have all proven, the best code does tend to win despite
the efforts of trolls and zombies. Lowering the barriers to
contributing and experimenting leads, more or less directly, to more
development and experimentation, so I expect that the best code will
tend to emerge from the network of forks which make sharing changes
between them as easy as possible.