I'll present a few scenarios in which a fork is a good thing. I think in
doing so, I'll show why it is necessary.
___
|
|
|
---
Let's start with a hypothetical situation in which there is a single
person, Bob, who owns the sole copyright of an OpenSource program known as
BobWare. BobWare is a great office suite, approximately twenty-thousand
times better than MicroSoft office. But let's give this a setting at the
beginning of the PC era.
Everyone is happy with Bob and BobWare for quite some time. Bob does a good
job deciding which patches to accept and which to reject. He does a good
job maintaining BobWare.
Bob, however, eventually grows tired of supporting BobWare. He lets
maintainence like accepting patches lapse. No new versions are released,
and no patches are accepted. And Bob does not answer his email, either.
But thus does not stop BobWare. People still use it -- it still works. And
people still have the source, so they can still modify it. But they can't
get their patch in the official version, because Bob is no longer around.
So they just release them at scattered sites around the Internet.
One day, another developer, named Larry, shows up. He decides that he will
support BobWare. He forks from it -- after all, Bob is doing nothing -- and
calls his fork LarryWare. He collects all the available changes to BobWare,
and applies them. He then distributes his new package, and people once
again have support for their favorite office suite.
_____
| |
| |
| |
-----
Larry continues to support LarryWare. However, a newcomer named Steve wants
to change things. He has seen LarryWare, and has used it a lot. He,
however, does not like the CLI [command-line interface]. He decides that it
would be real nice if he could use a GUI, instead.
Steve begins his work, and finally, after a year of work, finishes a GUI
version of LarryWare. He shows it to a few people. They think it's great,
and advise him to submit the changes.
Steve submits the changes to Larry. Larry, however, does not want a GUI. He
wants a CLI. So, he rejects the changes.
Our friend Steve, however, does not give up. He forks, and calls his new
product SteveWare. Eventually, it turns out that almost no one likes a CLI
over a well-done GUI, and SteveWare prevails over LarryWare.
_______
| | |
| | |
| | |
-------
Then enters a new developer to the arena named John. John wants to port
SteveWare to another operating system. In order to do this, he proposes
major changes which will take a while to do. Steve replies that while its a
great goal, he's not going to put SteveWare on hold for a year to make
those changes, nor does he want to go through the debugging necessary to do
so.
So, John forks. He starts making his changes. Eventually he, with the help
of many other developers, succeeds. They get the software fully debugged
and running on many platforms.
They then email Steve, who agrees to merge. They leave the product under
the name SteveWare.
Someday, of course, someone will add to this. Maybe Steve quits. Maybe
someone comes up with another new idea which Steve does not like. But the
point is forking prevents dictatorial control (notice how Larry could not
stop the GUI), it allows innovation (Steve and John), and permits software
to go on even if the guy in charge does not want it to (change from Bob to
Larry).
Some of these stories and people are based (loosely) upon real people and
stories. Some are so general as to apply to many stories. Bonus points to
whomever can guess what the story and people are based on.
