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:
- 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.
- I can convince you to modify your module so it meets my needs.
- I can work with you in your open source project to make the module (“our” module in this case) meet our mutual needs.
- 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.
(This post has also been translated into Serb-Croatian by Anja Skrba.)
sublui says
On 13 Jul 2011 IBM announced that “we’re going to contribute the standalone version of Lotus Symphony to the Apache OpenOffice.org project, under the Apache 2.0 license”, so this is a re-affirming of that, right ? Is there a time-line for the publication of the Symphony source code under AL2 ?
Rob says
@sublui, This is reaffirming the previous announcement, but also taking it further. In theory, we could have contributed the Symphony code but still maintained Symphony as a distinct brand, and maintained a separate code base where we pushed innovations into Symphony before later contributing them to the “community edition”. This is a pattern you see with many corporate-led open source projects, where the community edition lags behind the commercial version. But we’re not doing that. Ending the fork is not just a statement about contributing the source code. It is a statement about the orientation of the projects, in this case a statement that there will not be a separate Symphony project, but we’ll do all our feature work directly in the Apache community. We’re not even promoting an independent brand identity. We’ll work with the community to reinforce and promote the OpenOffice brand.
As for time-line, we’re actively working on putting the contribution together. I’d expect it this quarter.
KeithCu says
If you were to change the OpenOffice license to something like LGPL/MPL, you would be able to merge your work more easily with the “other forks” out there.
Last June you argued that forks aren’t a bad thing, which is why you didn’t want to join up with TDF when you were starting. Now you seem to think forks are a bad thing because you suggest that TDF join you. What facts changed that caused you to change your opinion? I only wish you were as concerned about forks last June as you appear to be now.
Rob says
@Keith, where do I say that forking is “a bad thing”? On the contrary, I say, “It [forking] 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.”
KeithCu says
If you didn’t think forks are a bad thing, you wouldn’t have bothered to end the Symphony fork, and you wouldn’t be encouraging the other forks to join up with you.
Note that I found this post via a link from another IBM-er, who wrote: “While forks in the open source world can be a tremendous way of shaking things up, they can also be very damaging. In this case, I think it’s a waste of resources and energy to keep this going.”
Rob says
@Keith, Conditions changed. That doesn’t mean that forking OpenOffice.org to create Symphony was a bad thing. It worked very well for us. But with the move of OpenOffice to Apache, there is no reason to continue as a fork. It is all about making optimal choices given the information we have today. And I never said the LibreOffice fork was created for bad reasons. In fact I shared their dissatisfaction with the way OOo was being run as a corporate-led open source project. But conditions changed. OpenOffice is now at Apache. It is not controlled by a single corporation. It is not a radical idea to suggest that this change calls for current forks of OpenOffice.org to reevaluated. We certainly did with the Symphony fork, with results as reported.
KeithCu says
I don’t think Symphony worked very well for you. I’ve never seen it, and in the Office team we never thought about it.
You didn’t explain why you wanted to end the Symphony fork. Presumably, you saw a benefit, or you wouldn’t have bothered. What is it? Did that reason also apply last June?
Why would LibreOffice switch to an “inferior” license, throw away all the infrastructure they have just built, move to your codebase which is months behind, be forced to use Subversion and other silly tools and processes, etc.?
If it didn’t make sense for TDF and Apache to join forces when you got going, what makes it a good idea now? It seems you are asking people to change their opinion with no change in facts.
Rob says
@Keith, Symphony did fine for us. For example, Symphony 3.0 won PC Mag.com’s Editor’s Choice award. So no complaints with what we accomplished in Symphony.
It is illogical to speak of one code base being older than another. Symphony has been in continuous development for far longer than LibreOffice has. Sure, there are enhancements in LibreOffice that Symphony lacks. But it is also true that there are many enhancements that Symphony has that LibreOffice lacks.
As for time spent on infrastructure, etc., you need to decide how much you are going to let the dead hand of past decisions rule over current reality. A review of sunk costs would seem to be in order.
And with respect to the license, LibreOffice had no choice in what license they could use, at least for 99% of the code. It was determined by Sun many years ago. If you want to now turn that choice in a virtue and Sun into a saint for mandating that license, then go ahead. But there is a choice available now — Apache 2.0 license — that did not exist back when LibreOffice forked.
Certainly there are some involved in this merely for power, control and self-aggrandizement. It is hard to avoid that in any large public endeavor. But there are many more who simply want to create the best open source office suite they can and bring that value to the largest number of users they can. Clearly, I’m speaking to that vast, non-ideological majority, not to you alone. It is clear to them that working together we can accomplish far more than working separately. That is why it was pragmatic to stop the Symphony fork and align ourselves 100% with the Apache OpenOffice project. The same logic suggests that others should at least consider the same. Or are you arguing that one should not consider all options available?
KeithCu says
If you think Symphony did “very well”, it is just the Kool Aid you were drinking inside IBM. Anyway, this is a minor point.
You are the one sinking costs. You are rebuilding infrastructure that TDF already has. You are also doing work to build a pure Apache-licensed product that LibreOffice is not interested in.
There might be some bits of Symphony that should be picked up and ported into LibreOffice. There are many enhancements that LibreOffice has that Symphony lacks. Everything the LibreOffice team has done since they started would be among those.
You didn’t answer a number of the questions I brought up in my previous post. Can you respond to them? I copy them below for your convenience:
Why did you end the Symphony fork?
Did that reason also apply last June?
Why should LibreOffice switch to an inferior license?
Why should LibreOffice switch to the inferior Subversion?
Why should they abandon all the other infrastructure they have just built?
If it didn’t make sense for you to join with TDF when you got started, what makes it a good idea now?
Rob says
Why did you end the Symphony fork? Answer: The conditions that led to the fork in the first place no longer exist, now that we have the Apache OpenOffice project. I’m not going to rehash the reasons why we forked back in 2006. I’d like to remain positive and forward-looking. But I will say that the reasons overlap significantly with the list of complaints that led to the recent LibreOffice fork. That is what makes me confident that the good things about Apache that led us to end our fork should also make LibreOffice participants reconsider their fork.
Did that reason also apply last June? Answer: You should not confuse the date of an announcement with the date of a decision or the date an idea first occurs. Ending the Symphony fork was something that was suggested as soon as Apache OpenOffice started, last June.
Why should LibreOffice switch to an inferior license? Answer: They should not. But I’d also argue that Apache 2.0 is not an inferior license.
Why should LibreOffice switch to the inferior Subversion? Answer: They shouldn’t. If you want to use git at Apache you can. Many Apache projects have read-only git mirrors, and a smaller number of projects are taking part in a pilot with read/write git use.
Why should they abandon all the other infrastructure they have just built? Answer: They shouldn’t. Although there is a lot of overlap, there is also a lot of unique infrastructure among the two projects that we could all benefit from. For example, at Apache we preserved the huge legacy MediaWiki instance. LO already benefits from this work, linking to it many times. We also run support forums that support LO users as well as OOo users. It is hard to argue that the project would not be stronger if we combined efforts on infrastructure.
(BTW, you should really follow that “sunk costs” link to see what it means. It does not mean what you seem to think it means.)