Author: Mayank Sharma
OpenOffice.org is the most comprehensive open source office productivity suite available. Into its fifth year of existence, the project is set to release its next version, OpenOffice.org 2.0, with a major overhaul. The latest release, 1.9 (also popularly known as 2.0-beta), came out in March this year and was met with mixed reviews. While many were happy with the progress, many people criticized it for its use of Java. In this interview with Louis Suarez-Potts, Community Manager; and Martin Hollmichel, Release Manager of OpenOffice.org, they talk about what makes 2.0 different from the previous releases.
How big is OpenOffice.org 2.0? Could you give us some numbers to put that into perspective? How many lines of code has OOo swelled to now?
Louis Suarez-Potts: “Swelled?” I think the opposite. There has been, I believe, a concerted effort to tidy up the code, make it smaller. We started with something like 7.6 million [lines of code], and I’d hazard that it’s fewer now. Of course, that’s not counting the new database component, but it’s not clear that we ought to count it.
Martin Hollmichel: I think both statements are true. There were efforts to clean up the code, huge portions have been rewritten. But also new functionalities have been added besides Base which brought in new code: improved usability in almost every area, Microsoft Office interoperability, more supported file formats, more system integration, support for additional language in the scripting framework and many more new features. So in total, we had an increase with respect to lines of code.
How do you see OOo 2.0? Is it just an upgraded version of a software or is it a watershed for OO.o?
LSP: Watershed. OOo 2.0 uses the standardized OpenDocument format, so that the file format has also changed. That doesn’t directly relate to the application’s code but it’s relevant. In addition, and crucially for business and government, interoperability with Microsoft Office has
considerably improved. All in all, it’s a real departure and a good one. We expect that businesses and individuals both will find the changes pleasing.
I think one way of looking at OOo 2.0 is that it has been designed to work with others in a heterogeneous environment: Windows machines, Linux machines, what have you, and to work well. Microsoft Office, on the other hand, has been designed to work well only within the Microsoft universe. MSFT excludes others. We include others.
The list of features required for 2.0 was huge. How were these attacked by the developers? If there was preference towards some features what was the criteria?
MH: Almost all features which were planned for 2.0 were implemented by Sun engineers. Having a whole bunch of full-time developers was helpful to get most of the features done in time. With the help of the development model using child workspaces on top of CVS, we were able to postpone some of the features and to ensure high quality for the features that finally got into 2.0. But having done work on several huge features like the new Chart, will enable development teams later to integrate them while ensuring high quality.
To introduce an open specification process and have a big QA community on board was extremely helpful to get feedback on new features even before implementation has been started. Doing QA before integration of the code into the main CVS
trunk is another important process.
LSP: As to preferences: Our Q Product Concept document, released last year, spells out the set of priorities. You will notice that “Microsoft Office Interoperability” is no. 1 of the key drivers. Why? Because that’s what enterprises and other big clients want: a free office suite that is fully interoperable with MS Office and that allows users to painlessly work within heterogeneous environments or to switch. And with 2.0, switching to OOo has never been easier, as the UI is familiar and even more intuitive.
How has the 2.0 “set of releases” been planned? Will further releases see more of bug-fixes or new features?
LSP: Well, the first part of the question is difficult to answer… there will be many bug fixes, of course, and even probably new features, to cater to this or that port or version. More interestingly is the work that will now commence on 3.0.
MH: Based on the good experiences we have had with the above process, I even expect less bug-fixes than ever before. This will us give the possibility to be more flexible in certain situations to integrate new features more frequently. But there is no decision yet about a possible roadmap for major releases after 2.0. We will gather all the feedback from the OOo community and Sun’s StarOffice customers to get a final picture.
Apart from the software changes, has the development procedure also undergone some changes?
LSP: Basically, we are entering a new phase in community involvement in developing OOo. I think we are getting increasingly mature and thus better able to work with all participants. Last year, we impanelled the Engineering Steering Committee, which was charged with handling questions related to code process. At the same time, the technical project leads have made a concerted effort to give capable members more room to work. Thus, we now use child work spaces (CWS), which are effectively test CVS branches, and generally make it a lot easier for coders to dive into OOo and work on interesting things.
There is also more documentation, more of an effort to mentor newbies, and so on. A lot of this information can be found in our Development project, but it is really just a start. We have to develop the documentation and examples more, so that
interested developers can get up to speed more quickly.
MH: I would like to mention one big plus with the change of the development procedure. Since one of our main objectives was to have a stable tree all the time — which is difficult in a multi platform, multilingual development environment — we had some kind of controlled style of development. Since the introduction of child workspaces we now have an increase of non Sun Developers with commit access to the CVS repository and the speed of getting patches integrated into the main builds increased dramatically. We know this is working extremely well by seeing how the Mac porting team got in sync with the other established platforms in the last few months.
How about documentation for the new version, since lots has changed and some new things, like the database engine, have been added.
LSP: True, a lot has changed. We have rather good documentation, with spec links, here. But it is mainly geared for users. Developers would do well to look here, which gives an overview of the process and environment here. They should also download our SDK (Software Development Kit). It gives
really useful examples and code snippets.
You were in India recently. Is 00.0 2.0 a better internationalized product? How many languages will the first release be available in?
LSP: Yes, I was in India and was, as before, struck by the way in which Open Source and OOo are greeted. It’s almost a case of an embarrassment of riches. A key problem (and also hope) is marshaling all the goodwill and effort.
2.0 is a significant milestone and it is more internationalized, for it is the product of 4.5 years of building momentum among communities throughout the world. By the time we release 2.0 GM, it should be localized to at least 50 languages, 45 of which will be supported by active communities.
I am hoping that among that set we will see at least half a dozen Indic languages, including Hindi, Tamil, Gujurati, Kannada, and so on. The importance of getting more Indic languages out is of course difficult to overestimate. It also speaks to the really enormous logistical issues confronting not just us but any open source group. For we are asking commercially interested organizations, government agencies, and volunteers to work together, to collaborate on building something whose benefit to them is clear but whose benefit to others is perhaps even clearer.
How has the response been to the beta release. How many downloads till date?
LSP: At least a million, though it’s very difficult to track. I don’t track, for instance, accesses directly made to our server archipelago or duplications of CDROMs.
