Interview: Joerg Heilig, Director, Software Engineering, Sun
-Louis Suárez-PottsJoerg Heilig has perhaps contributed more than any other person to the worldwide success of OpenOffice.org and StarOffice--and has done so quietly. Located in Hamburg, Germany, Joerg oversees the technical development of the OpenOffice.org/StarOffice code. This interview was conducted via e-mail on 2003-11-11 and 11-12. I have very lightly edited the transcript.
What is your role now in OpenOffice.org/StarOffice and what was your role in architecting the OpenOffice.org project at its inception?
I am responsible for the StarOffice engineering and in this role also responsible for all engineering work on OpenOffice.org done by Sun employees. At the time of OpenOffice.org's inception I was responsible for StarOffice's base technology and involved in all the engineering discussions around open sourcing StarOffice.
OpenOffice.org has grown exponentially since it was created several years ago. in that time, we have reduced the number of paid managers both on CollabNet's side and Sun's. What are the difficulties you have encountered in managing this project from the technical side? And, though I touch more directly on this below, how has the active presence of the OSS community affected the technical agenda?
The OpenOffice.org community has indeed grown exponentially and every contributor is special and adds value to the project. Diversity has been one of OpenOffice.org's towering strengths. Diversity created the marketing project and the local language projects to just name some. At the some time it has been a challenge to be inclusive, given the enormous diversity we are seeing. The technical agenda has to always reflect this and be inclusive to the stakeholders in the community and not only the Sun internal ones. We needed to create mechanism that are natural and work (like the Community Council) instead of just re-iterating that it is everyone's responsibility to be inclusive.
How do you envision the Sun/OSS collaboration working? In particular, what are the methods used for collaborating across corporate walls?
For the deeper issues that affect large parts of the community, I strongly believe that the Community Council is the right body to advance this collaboration. It will play an important part in balancing the interests of the stakeholders.
For all the little stuff I am big fan of personal email and, even better, telephone calls. In today's email age I believe we are not talking enough on the phone anymore. Email does not work particularly well if people do not know enough of the other person's background. Let's get things on the table and work them out together. For everything that is related to Sun as well as day-to-day management of the Project, we have several people everyone can turn to, the community manager (Louis), the OpenOffice.org marketing manager (Erwin), the engineering contact person (Stefan), all the project leads; and, if you get stuck with a Sun-related issue, please feel free to try me as well.
What does a non-Sun (or Sun) developer have to do to have his contribution considered, let alone accepted?
Provide contributions that fit into the product concept as posted on the roadmap page and adhere to the coding guidelines. It is always a good idea to discuss your potential contribution in advance with the project lead to avoid duplication of efforts and to fine tune for best efficiency.
At the moment, StarOffice sets the roadmap and technical agenda for OpenOffice.org as well as for StarOffice (the two are more than coincidentally linked, of course). Where do you see non-Sun community intervention? That is, if other community members want to build and maintain features not currently present on the roadmap, how should they go about it?
If they add value to the product without contradicting the goals on the roadmap they should go into OpenOffice.org as well as StarOffice. Please discuss with the project lead in advance to make sure that everyone agrees that the contribution adds more value than complexity or other overhead and that it fits into the OpenOffice.org architecture. If you want to do something that is not relevant for a large percentage of OpenOffice.org users go off and do it using the SDK. Do it in the Incubator area, as a project, or on your own website and offer it as an add-on.
And, finally, do you see the roadmap being decided by the Community Council?
The roadmap will need to compromise between the interests of the stakeholders. The Community Council has the authority to decide on key issues, including the roadmap. The Community Council decides by consensus. I am very confident that the people that make up the Council have the background, the integrity, and the spirit to make these difficult tradeoffs.
The 2.0 product concept document is a landmark document and includes the community early on. What are the key features of the document? That is, what should users and developers expect with 2.0? how is the XML file format evolving?
The document is intended for a large part of the community, developers as well as users. We have received great feedback and are set to incorporate it. The key areas for OpenOffice.org 2.0 include, first, to further improve the interoperability with Microsoft Office to a point where it is a minimal risk and easy choice to migrate to OpenOffice.org and continue to interoperate with MS Office documents. The second area is to improve on usability to lower the (already low) training costs when migrating to OpenOffice.org from other office suites or coming new to an office productivity suite. And the last one is to further improve performance at startup time and when working with large spreadsheets. These are the key areas but we also plan many, many smaller improvements and in the end it is the attention to detail that matters and not all the great new features.
What are the advantages of OpenOffice.org's XML file format and OpenOffice.org's approach to XML?
If you want to remember only one thing it is that all OpenOffice.org files are stored as XML. XML is the default. Any document created in OpenOffice.org can be read by any XML enabled tool and be processed, transformed, or archived in an application and vendor independent way.
The StarOffice and OpenOffice.org file format is being (or will be) used by the OASIS group as a standard. Can you speak to the implications of this not just for present use and development but for the future?
We are committed to the OASIS standardization work. We believe it is a key aspect of the program and will be adopted by many organizations worldwide. We are working hard on making sure that the standard will be implemented in OpenOffice.org as soon as possible after being released and, simultaneously, we will take OpenOffice.org requirements to the TCO (Technical Committee, OpenOffice.org Format, led by Michael Brauer of Sun) to get them incorporated into the standard. This standard will change the industry. I have no doubt about this. People will not accept that they cannot access their data without expensive tools from just one vendor. And even more importantly, that they have no influence over how they will be able to access their data in 50 years from now. Nowadays, it is sometimes impossible to access documents written even twenty years ago on a vendor whose product has changed or is no longer supported. Without standards, users are left to the whims of the vendor.
The standard in short will eliminate vendor lock in? How so?
However much we would like for OpenOffice.org and StarOffice to be successful we have also made it very clear that we do not want to be another monopoly. Transferring the rights on the file format to OASIS and open sourcing the reference implementation, OpenOffice.org eliminates vendor lock in. Any ISV can build tools utilizing the well-documented OASIS standard free of charge and anyone can use the OpenOffice.org open-source project. I leave it as an exercise for the reader to compare this situation to the Microsoft XML or even binary file formats yourself.
Microsoft has made a big to-do about its Digital Rights Management Office and security. Does OpenOffice.org have anything like that in the works? If so, what are the similarities, differences?
We do not have plans to manage rights to a document. Nevertheless the concept document states our plans on working on digital signatures and encryption using open APIs and open standards (like XML signatures). We do not have information on how to use the Microsoft DRM in apps not coming from MS, like OpenOffice.org. It would be a requirement for supporting DRM to have access to these APIs but also to be able to replace the backend infrastructure that manages the certificates and the authentication behind the APIs. I do not see any indications that this information is going to be available soon. In the end it is the people who send documents around who will decide on how useful this feature is. Remember that you need to know that the recipient has at least MS Office 2003 and that she has a MS passport account or other account managed in a MS backend certificate store. This does not sound to me like a compelling picture looking at the level of trust that people have developed towards MS. I rather see people asking for a backend infrastructure that is based on public standards and implementations from multiple vendors to choose from.
Finally, in the last two years OpenOffice.org and StarOffice have been able to prove themselves the better choice for millions of people worldwide. But the open-source nature of the code means that this is only the beginning: there is lots of room for innovation. Looking beyond 2.0, what do you see as some of the possibilities for OpenOffice.org/StarOffice?
OpenOffice.org and StarOffice with 2.0 will come to a point where it is the natural choice for most users, for the followers and not the early adopters. After 2.0 we need to spend more time in helping the ISVs in porting all their solutions that exist for MS Office to OpenOffice.org. This is THE opportunity for ISVs. Get on the train now and you will be the market leaders of the future. Sun does not want to be everything to everybody. There is plenty of room for partners and looking at the traffic on the API lists I clearly see that I am only promoting the obvious.
