Stuff Michael Meeks is doing |
Older items: 2023: ( J F M A M J ), 2022: ( J F M A M J J A S O N D ), 2021, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html
Apparently people are trying to stick 'forks' into each other (and in particular me) these days cf. Simon & Roy's noted enthusiasm for this. Apparently (particularly according to medieval, western, knife manufacturers everywhere) the fork is hell-spawn, not to mention economically damaging, particularly when bundled with rice. But, what is a fork ? Wikipedia's write-up is helpful but extremely broad.
Back in the day - I used Slackware Linux (cue nostalgia for antique hardware etc.) but now I read up on it, I seem to have been duped: Slackware seems to have been based on a fork of SLS! - I was cheated out of using the real thing. Worse than that, apparently SLS was forked again by that Ian Murdock guy into something called Debian. Sadly, since then, SLS appears to have gone the way of the "Save the Stegosaurus" campaign.
Of course - there are now hundreds of Linux Distributions, each with different choices built in, many with different packages. Of course, there is some nuance here - is Mandriva a fork of RedHat ? is Ubuntu a fork of Debian ? is Mepis a further fork of Ubuntu ? are these cycles of creative destruction: branching, tweaking, trail-blazing new directions, including new features, and/or failing and disappearing bad ? should we have a central planning committee wielding powerful legal tools to pro-actively stamp them out ? or are they a positive side-effect of open-ness: allowing bad ideas to be weeded out by survival-of-the-fittest ?What makes a fork ? Can a budding etymologist confirm the relation to the unix 'fork' system call ? If you use that, in a miracle of copy-on-write-ness; post fork, anything you change is not shared with the parent process ?
Why are linux distributions not generally seen as forks ? I hypothesise that the answer is primarily that development is (for the most part) not independent - distros work on the same underlying code, and (hopefully) contribute their changes back to the common underlying code-pool. Of course, they tend to put different branding on top, have different configuration settings, and often include packages specific to their own distribution, some of them (sadly) not Free software.
What about branching ? is cvs tag -b gnome-2-22
a fork ?
do projects go forking themselves regularly as wikipedia suggests ? again,
usually people don't call this a fork - it's a branch, and code changes go
into both sides of the branch. What then about adding components to a package ?
is writing a new out-of-tree kernel module a fork ? what if you give it to
some of your friends ? Does this apply more broadly ? is open-sourcing
Solaris creating a fork of the GNU/Linux stack - by replacing a key component
with a duplicate ? or is that just duplication ? or is Linux itself a fork/
duplication of PrimevalNix and thus intrinsically bad ? does licensing matter ?
is duplication for licensing reasons acceptable ? how about purely for
ownership ?
David A. Wheeler's forking appendix (to his interesting paper) postulates intent here; is the intent to become a competing or replacement project ? Well, certainly I'd like go-oo to become, as long as Sun pointlessly excludes our features, a replacement distribution (NB. not fork) of OO.o to the one Sun controls: simply because I'd like to get this injustice addressed, but of course, I'd far prefer to have a single up-stream community controlled source for OO.o.
Re-applying this to the world of OO.o, lets look first at StarOffice - was that a fork of OO.o ? in the past when it included proprietary closed source pieces and custom tweaks, and clearly was intended to compete with OO.o, did Sun fork it's 'own' project ? or was that a commercial re-distribution of OO.o with bits added ? How about ooo-build / go-oo ? that includes plenty of patches that for one reason & another (mostly the pain threshold) are not yet up-stream, the snapshot looking far worse than it is, since many patches have already gone up-stream over the years. Of course go-oo also includes some pieces (mostly well separated) that Sun simply refuses to accept up-stream because it wants to own them. Does that make it a fork ? if so, who is to blame for any negative effect ?
Some issues are great for endless charged debate - to quote Yes Minister, The problem is all my facts are statistics, and all your statistics are facts. I (of course) pass on useful and relevant information; it is other people that gossip, I take a lively interest in my surroundings; it's the other people that are nosy etc. People can call go-oo a fork certainly, it's a convenient way of putting it in a box marked 'evil' without mature consideration - but perhaps for consistency they need to call rather a number of other things forks, putting us in good company. Personally, I think forking is sometimes justified, but is go-oo really a fork ? you decide. Whatever your answer, it is totally facile to insinuate that because we encourage people to work on go-oo, that none of their work will get into Sun's OO.o - some of it will (we hope), and we'd love Sun to take the components too, under the copy-left license of their choice.
My content in this blog and associated images / data under
images/
and data/
directories are (usually)
created by me and (unless obviously labelled otherwise) are licensed under
the public domain, and/or if that doesn't float your boat a CC0
license. I encourage linking back (of course) to help people decide for
themselves, in context, in the battle for ideas, and I love fixes /
improvements / corrections by private mail.
In case it's not painfully obvious: the reflections reflected here are my own; mine, all mine ! and don't reflect the views of Collabora, SUSE, Novell, The Document Foundation, Spaghetti Hurlers (International), or anyone else. It's also important to realise that I'm not in on the Swedish Conspiracy. Occasionally people ask for formal photos for conferences or fun.
Michael Meeks (michael.meeks@collabora.com)