{"id":1927,"date":"2012-02-01T22:59:47","date_gmt":"2012-02-02T03:59:47","guid":{"rendered":"http:\/\/2d823b65bb.nxcli.io\/?p=1927"},"modified":"2013-06-17T09:18:07","modified_gmt":"2013-06-17T13:18:07","slug":"ending-the-symphony-fork","status":"publish","type":"post","link":"https:\/\/www.robweir.com\/blog\/2012\/02\/ending-the-symphony-fork.html","title":{"rendered":"Ending the Symphony Fork"},"content":{"rendered":"<h3>What is a fork?<\/h3>\n<p>A fork is a form of software reuse.\u00a0 I like your software module.\u00a0 It meets some or many of my needs, but I need some additional features.<\/p>\n<p>When I want to reuse existing functionality from another software product, I generally have four choices:<\/p>\n<ol>\n<li>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.<\/li>\n<li>I can convince you to modify your module so it meets my needs.<\/li>\n<li>I can work with you in your open source project to make the module (&#8220;our&#8221; module in this case) meet our mutual needs.<\/li>\n<li>I can copy the source code of your module and change the code in my copy, and integrate that modified module into my product.<\/li>\n<\/ol>\n<p>Note that options #1 and #2 are the only options available with most proprietary modules, since these techniques don&#8217;t require access to the module&#8217;s source code.\u00a0 Options #3 and #4 are the additional options made possible by open source.\u00a0 Option #4 is what we mean by &#8220;forking&#8221; .\u00a0 Forking is enabled by open source software and is fundamental to open source ecosystems.\u00a0 It is neither good nor bad.\u00a0 It is a tool, part social, part technological, for overcoming an inability or unwillingness to collaborate.\u00a0 The problem is not with forking.\u00a0 The problem is the conditions that lead to forking.<\/p>\n<h3>Why do forks come about and how do they end?<\/h3>\n<p>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.<\/p>\n<p>Generally, a fork ends when the conditions that necessitated the formation of the fork have been resolved.\u00a0 At least that is true for rational participants who are merely trying to optimize outcomes.\u00a0 But intransigent ideological forks can continue indefinitely, and often do.<\/p>\n<p>The technical side of ending a fork is typically a code merge, as different branches of the project are brought back together again.\u00a0 This can be laborious, but it is a one-time task.<\/p>\n<h3>Ending the Symphony Fork<\/h3>\n<p>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.\u00a0 This is a tremendous change and one that should lead all forks of OpenOffice,\u00a0 and all those who wanted to get involved with OpenOffice before but never did,\u00a0 to reexamine their orientation to the project.<\/p>\n<p>John Maynard Keynes, when criticized for reversing his position in a dispute, famously quipped, &#8220;When the facts change, I change my opinion. What do you do, sir?&#8221;\u00a0 The &#8220;facts&#8221; 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 <a href=\"http:\/\/www.edbrill.com\/ebrill\/edbrill.nsf\/dx\/ibm-lotus-symphony-3.0.1-is-now-available\">announced<\/a> that it was ending its fork and committing to contribute their code to Apache and to work with that community going forward.<\/p>\n<p>This does not mean that Symphony enhancements are going away.\u00a0 Far from it. \u00a0 We&#8217;re very proud of the UI work and other innovations in performance, accessibility and interoperability we&#8217;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.\u00a0 The DNA of Symphony is not going away.\u00a0 What is going away is Symphony as a fork, as a divided effort.\u00a0 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.<\/p>\n<p>Now that the Symphony fork is ending, the obvious question is: \u00a0\u00a0 Who will be next?\u00a0\u00a0\u00a0 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.\u00a0 &#8220;When the facts change, I change my opinion.\u00a0 What do you do, sir?&#8221;<\/p>\n<p>If you are interested in learning more about the Apache OpenOffice project, I recommend browsing the <a href=\"http:\/\/incubator.apache.org\/openofficeorg\/\">project&#8217;s website<\/a> and <a href=\"http:\/\/blogs.apache.org\/OOo\/\">blog<\/a>.\u00a0 If you want to get involved, you can sign up for the <a href=\"http:\/\/incubator.apache.org\/openofficeorg\/mailing-lists.html#development_mailing_list\">ooo-dev mailing list<\/a> and post a note to introduce yourself.\u00a0 As we push closer to our 3.4 release candidate we&#8217;re in particular need of volunteers to help us test this release, on Windows, Mac or Linux.\u00a0 If you are interested in helping with that, be sure to say so in your note.<\/p>\n<p>(This post has also been <a href=\"http:\/\/science.webhostinggeeks.com\/zavrsetak-symphony-fork\">translated into Serb-Croatian<\/a> by Anja Skrba.)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>What is a fork? A fork is a form of software reuse.\u00a0 I like your software module.\u00a0 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, [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[211,64,22],"tags":[],"class_list":{"0":"post-1927","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-apache","7":"category-open-source","8":"category-openoffice","9":"entry"},"_links":{"self":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts\/1927","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/comments?post=1927"}],"version-history":[{"count":11,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts\/1927\/revisions"}],"predecessor-version":[{"id":1937,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts\/1927\/revisions\/1937"}],"wp:attachment":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/media?parent=1927"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/categories?post=1927"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/tags?post=1927"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}