Symphony is alive and well and living at Apache: Explaining IBM's document strategy
Douglas Heintzman 060000Q98X email@example.com | | Emneord:  apache documents ics-strategy social-business symphony
0 kommentarer | 9.092 besøg
A few weeks ago IBM announced that it was transitioning its Symphony productivity suite development effort to Apache, to work on the OpenOffice project This news raised questions about what IBM's strategy was in the document space. I would like to set the record straight. Let me be perfectly clear — IBM is not stepping back from its investment in Symphony. We are donating our Symphony code to the Apache Software Foundation and directing our development effort to work directly on the combined code in the Apache OpenOffice community. We plan to continue to distribute OpenOffice technology, though likely not under the Symphony brand but instead under the name “Apache OpenOffice 4.0 IBM Edition”, or something like that.
I have further been asked, by many of late, to explain what IBM's document strategy is and why it has chosen to engage with the Apache Software Foundation. To properly answer that question a discussion of the back story is in order.
OpenOffice has been the leading open, multi-platform, free document editor suite in the market for a decade. Many companies distribute it, including IBM (in a version called Symphony which adds a number of IBM enhancements). The project had been led and managed by Sun and then Oracle (by virtue of their purchase of Sun). A couple of years ago a number of community members decided to fork the code and created a derivative known as LibreOffice. A little bit later, Oracle decided to donate the OpenOffice code base and trademarks to the Apache Software Foundation and encouraged a community of interested parties to co-invest and work towards delivering new innovation and value to the market in an open community foundation. IBM and many other parties, new as well as longstanding OpenOffice community members, have been working on the Apache OpenOffce code for about eight months now.
LibreOffice and Apache OpenOffice are very similar and share much of the same code. They are licensed under different licensing regimes. LibreOffice is licensed under a copyleft regime (LGPL) and Apache OpenOffice is licensed under a permissive licensing regime (Apache 2.0).
For some background on open source, licensing and open source business models I recommend taking a look at a paper I wrote a number of years ago:
So what is IBM's document strategy and why did it decide to work with the Apache OpenOffice project instead of the LibreOffice project?
We think that documents represent a very pragmatic way to capture, record and share information. They provide a powerful and flexible substrate for bringing ideas together, refining them and structuring them in a manner that efficiently communicates those ideas.
The world is awash in unstructured data. Much, if not most of it, is in the form of documents, and their number and importance in creating value will increase quite dramatically in the next number of years. Most IT storage specialists, including those managing cloud resources, are planning for unstructured data to bypass structured data in terms of storage , sometime this year. More than that, the value of those documents is being magnified dramatically as multi-user, co-editing tools become available, as they are enriched with semantic, linked data capabilities, as they understand more and more of the social business context in which they are created, evolve, and can potentially be used, and because of the emergence of advanced text analytics, pattern analytics, and social analytics which allow deeper insights to be garnered, activities to be better prioritized, and decisions to be more efficiently and better informed. All of these things represent significant value to our customers and...well... we are in the business of delivering value to our customers.
….So we care about documents.
Our interest in documents goes far beyond document composition and includes storage and content management, Big Data, various forms of insight-enhancing analytics, Deep Q&A (Watson for example), attention management, risk and trustworthiness, business intelligence, etc... and we are investing in all of them.
Of course, document composition is an important part of this value creation web, so it only makes sense that we invest in it as well. Document editing suites have long been an important fixture of the PC era, and will continue to be important for many years to come, although commoditization pressures will continue to reshape that market. Other significant document technologies have recently come to prominence, most notedly mobile editing, collaborative web editing and wiki's. Undoubtedly other new innovative models will emerge as well. Many of these new models address some of the shortcoming of the traditional document editing suite or leverage some new communication or social infrastructure, but they are also in many ways adjacent and complimentary to traditional document editing suites. That being said , document editing suites still offer very useful power features, functions, and experiences that are very useful for the document creation and editing cycle. IBM's view is that many tools will coexist and compliment each other and as a result we need to make investments in many parts of the document ecosystem and work to extend each of them towards each other of them and allow them to work together. That is where you will get serious value creation acceleration.
Along with IBM Connections social business suite, which has blogs and wiki's and such, and the content management and analytic technologies mentioned above, IBM is also making a large investment in a web-based collaborative editing tool called “IBM Docs” (you can try a pre release version at https://www.lotuslive.com/en/catalog/labs). This tool not only integrates with team content repositories seamlessly and allows for multiple people to co-edit a document simultaneously, but it also integrates with the Activities workflow engine to allow people to assign sections and reviews and to-dos, and of course complete those assignments, mark them as done, and track the progress in the Activity.
That brings us to desktop editing. Apache OpenOffice is an important piece of this ecosystem, and it needs to evolve and innovate to take its rightful place among leading document tools. Oracle's decision to donate the code and trademarks to Apache opened up a wonderful opportunity to assemble companies and individuals that have a vision for the future and to focus their energies and resources. Community development of one of the core pieces of the grander document landscape, a piece that is very mature and has been rapidly commoditizing, makes sense.
So why did IBM decide to invest its resources at Apache? Apache is an open community with a well-known brand with a mature and proven governance model. This reputation allows for the efficient recruitment of co-investors and gives confidence to customers of the technology, thereby lowering barriers to consumption. Along with its well-earned reputation, the fact that Apache is a large and diverse organization means that it comes with the obvious advantages of economies of scale. Apache also promotes a licensing regime that lends itself to innovation and participation of well-resourced organizations and has a higher comfort level with many corporate customers.
The question of licensing models is for some a key issue that merits examination. The LibreOffice community works with a copyleft regime. This is partly because, when that community forked the code from the OpenOffice project, it was the only licensing regime available to them, and partly because the core of that community comes from Linux vendors that are very comfortable with, and have had prior success with, copyleft licensing. This does not mean that they have failed with permissive licenses; it just means they have more experience, and a greater comfort level, with copyleft regimes.
Copyleft licenses rely on a viral mechanism to enforce disclosure of code modifications. Basically, if you are benefiting from the code, you contractually must disclosure any modifications or enhancements you make. By and large, there is a significant trend towards permissive licensing and away from copyleft licenses (see: http://blogs.the451group.com/opensource/2011/06/06/the-trend-towards-permissive-licensing/) . In what most people would think of as counter-intuitive, copyleft licences are more predominant amongst vendor-led open source projects. The reason for this is that some vendors choose to run a dual licensing business model where they put the code out under a restrictive copyleft license and ship a commercial license themselves. They usually combine the licensing regime with a contributor agreement. This means that the intellectual property is aggregated and owned by the sponsoring vendor. This provides the sponsoring vendor with the unique advantage of being able to distribute and package the code as they see fit under a commercial licensing regime. This is exactly the business model that Sun used with OpenOffice and, as I mentioned previously, the reason that the LibreOffice could only fork the code under a copyleft license.
A permissive licensing regime uses a different mechanism. In a permissive licensing based community, individuals and companies contribute significant value to a project because they sincerely believe that the project will be stronger for their contribution and that the marketplace, and by extension their own interests and any derived code, will be healthier because of the success of the project. Apache is but one of many communities that have demonstrated they can thrive with the driving motivation of the value of co-investment. As the term “permissive” suggests, there is more flexibility to re-package and extend the code from these projects without ceding intellectual property. This makes such projects more attractive to corporate vendors, and facilitates corporate investment of resources.
Both copyleft and permissive licensing based communities have demonstrated that they can harness community creatively and create value. With the opportunity that Oracle's donation of OpenOffice to Apache presents, IBM has decided to invest its resources there, and to actively encourage others to do the same. Furthermore, IBM has decided to contribute its Symphony code to the Apache OpenOffice project This is a very large donation, which includes an accessibility framework, bug fixes, performance enhancements, feature extensions and a significant UI enhancements.
The work at Apache is progressing. The community has been working on code and licensing hygiene. They have integrated many bug fixes and added some new and exciting function including some new SVG capabilities. The Apache OpenOffice 3.4 release will be posted shortly.
A draft of the AOO 3.4 release notes are in the wiki here:
Some more information on the graphics enhancements can be found in this blog post:
If you want to receive an email notification when Apache OpenOffice 3.4 is available you can sign up for the project's announcement list by sending an email to firstname.lastname@example.org.
Now that the absorption of the OpenOffice donation has been finalized, IBM can make the Symphony code donation. The resulting merge of all of this new capability should appear in a 4.0 release later this year.
We are very encouraged by the progress that LibreOffice is making. There are many areas where the two communities do and should work together. Security and support, document interoperability and standards compliance are obvious. A significant amount of new technology will become available from Apache OpenOffice in the near future, especially once the Symphony code gets integrated. We encourage the LibreOffice community to leverage as much of it as they want. Apache's permissive licence allows them extraordinary flexibility to do so. We would also love to see LibreOffice contributors share their work with Apache OpenOffice. While the interest of these two communities are not identical they are most definitely aligned and complimentary.
As we move towards a web of linked data, deep Q&A and analytic-driven insight, significant new value will be created. We are hopeful that a collective community effort in one of the core elements (document creation and editing) will help accelerate this.