What is a fork?

A fork is a form of software reuse.  I like your software module.  It meets some or many of my needs, but I need some additional features.

When I want to reuse existing functionality from another software product, I generally have four choices:

1. If your module is nicely designed and extensible, then I might be able to simply use your code as-is and write new code to extend it.
2. I can convince you to modify your module so it meets my needs.
3. I can work with you in your open source project to make the module (“our” module in this case) meet our mutual needs.
4. I can copy the source code of your module and change the code in my copy, and integrate that modified module into my product.

Note that options #1 and #2 are the only options available with most proprietary modules, since these techniques don’t require access to the module’s source code.  Options #3 and #4 are the additional options made possible by open source.  Option #4 is what we mean by “forking” .  Forking is enabled by open source software and is fundamental to open source ecosystems.  It is neither good nor bad.  It is a tool, part social, part technological, for overcoming an inability or unwillingness to collaborate.  The problem is not with forking.  The problem is the conditions that lead to forking.

Why do forks come about and how do they end?

Forks can come about for many reasons, including leadership conflicts, ideological differences and other political issues, as well as differences in vision and technical direction of the project.

Generally, a fork ends when the conditions that necessitated the formation of the fork have been resolved.  At least that is true for rational participants who are merely trying to optimize outcomes.  But intransigent ideological forks can continue indefinitely, and often do.

The technical side of ending a fork is typically a code merge, as different branches of the project are brought back together again.  This can be laborious, but it is a one-time task.

Ending the Symphony Fork

With the move of OpenOffice to Apache, this open source project has made the critical move from a corporate-led open source project under asymmetrical licensing terms, to a community-led open source project under a single permissive license.  This is a tremendous change and one that should lead all forks of OpenOffice,  and all those who wanted to get involved with OpenOffice before but never did,  to reexamine their orientation to the project.

John Maynard Keynes, when criticized for reversing his position in a dispute, famously quipped, “When the facts change, I change my opinion. What do you do, sir?”  The “facts” of OpenOffice have changed, with the move to Apache, and this change of venue has made a huge impact on the Symphony team, which recently announced that it was ending its fork and committing to contribute their code to Apache and to work with that community going forward.

This does not mean that Symphony enhancements are going away.  Far from it.   We’re very proud of the UI work and other innovations in performance, accessibility and interoperability we’ve brought to Symphony and we will be offering the source code of these enhancements to Apache, and if accepted, will work within that project to merge these changes into Apache OpenOffice.  The DNA of Symphony is not going away.  What is going away is Symphony as a fork, as a divided effort.  The Symphony DNA, the cool work the Symphony team has worked so hard on, will live on, in Apache OpenOffice, combined with other ongoing contributions from the community, in a larger, stronger development effort.

Now that the Symphony fork is ending, the obvious question is:    Who will be next?    If we can end a four-year old fork and merge in our work with Apache, then so much easier it should be for forks that have been around for far less time.  “When the facts change, I change my opinion.  What do you do, sir?”

If you are interested in learning more about the Apache OpenOffice project, I recommend browsing the project’s website and blog.  If you want to get involved, you can sign up for the ooo-dev mailing list and post a note to introduce yourself.  As we push closer to our 3.4 release candidate we’re in particular need of volunteers to help us test this release, on Windows, Mac or Linux.  If you are interested in helping with that, be sure to say so in your note.

Related posts:

1. The Legacy of OpenOffice.org
2. OpenOffice, LibreOffice and the Scarcity Fallacy
3. First release of the Apache ODF Toolkit

As expected, my first attempt at a Family Tree for Star/Open/LibreOffice has resulted in some useful feedback (thank you), so here is a new version of the chart (and I suspect it may not be the last revision…).

When a 16 year old German started work on a word processor in 1984, I bet he had little idea of the software dynasty he was founding. At one stage there were at least six distinct descendants, all claiming to offer something special to computer users looking for an alternative to Microsoft’s Office software.

For those interested in such matters, I’m proposing this little genealogical chart of the family. Any comments, corrections, etc will be gratefully acknowledged!

Welcome to the sequel to The Alexandria Project, a cybersecurity thriller.  If you'd like to read the book this series is based on, you can read the first three chapters for free here (just click on the cover of the book).

 This series highlights aspects of my experience self-publishing The Alexandria Project.   If you'd like to read the book this series is based on, you can read the first three chapters for free here (just click ...