Interview: Mathias Bauer, Lead, Application Framework Project and Jürgen Schmidt, Lead, API Project

-Louis Suárez-Potts

2006-07-03

Mathias Bauer and Jürgen Schmidt are two of the key developers taking OpenOffice.org to the next stage. Lead of the Application Framework (framework) project, and a manager of software engineering at Sun Microsystems, Mathias has long assisted in the development of numerous facets of OpenOffice.org growth. As lead of the API project, and also of Sun, Jürgen coordinates our API policies and development. Both projects are crucial to the future of OpenOffice.org's growth and direction as a product and open-source project. This interview, conducted via email earlier this month, is part of a series seeking to chart the shape of things to come for OpenOffice.org.

With 2.0 OpenOffice.org implemented a technology that allows for the more or less easy inclusion of extensions and thus new features on a rolling basis. Can you speak on the nature of the technology and what sort of extensions developers should be interested in working on?

From the developer's point of view OpenOffice.org 2.0 was the starting signal for an improved way of developing OpenOffice.org extensions.

We added new amazing features to UNO and started to use them in our API. This needs to develop in the future and we are are already working on this ongoing task. We added the new package manager GUI as a graphical front-end to simplify the installation of extensions. Our package format was extended and now can contain arbitrary content that is described in a structured and defined manner. One of our main goals was to extend the feature set for extensions that want to integrate with the OpenOffice.org GUI, especially for our so called Add-Ons that use a configuration file approach for their integration. These extensions can be compared to what you might know from Mozilla or Firefox, though admittedly our Add-Ons still have much less influence on the OpenOffice.org GUI; on the other hand, they also are much less prone to versioning problems. As explained later, offering more and tighter integration into the OpenOffice.org GUI without getting the ugly versioning problems is one of our main goals for subsequent versions of OpenOffice.org.

So, if you are planning to create OpenOffice.org extensions, don't ask what is possible, join us on the dev@api.openoffice.org mailing list and discuss with us what needs to be done to make something possible. We are very interested in the ideas of the developer community about what is missing and what can be improved. This includes APIs, integration interfaces, development tools and so on. [Note: as with most of our lists, you must be subscribed to post; send blank email to dev-subscribe@api.openoffice.org. All lists are public. -Ed.]

I would add that the new (and still under construction) Extensions Project, initiated by Laurent Godard last year represents a superb opportunity for new and experienced developers. The project centralizes information concerning extensions to OpenOffice.org. It's an ideal project for developers interested in extending OpenOffice.org's functionality. Extensions could range from usability modules that satisfy usability demands to accounting packages to anything else that imagination and skill allow.

Another question: OpenOffice.org uses Java for Base as well as other things. Yet, there are very few Java apps that extend OpenOffice.org functionality. What can be done to improve that?

As announced on the last OpenOffice.org conference in Koper we are working on an integration of our development tools into the NetBeans and Eclipse IDEs. Developers should be able to create UNO components and OpenOffice.org extensions with the help of wizards that free them from the boring routine work and speeds up the development. While the NetBeans work is done in Hamburg, the Eclipse integration is provided by a very active member of our development community, Cédric Bosdonnat, who joined the project by working with us on a Google Summer Of Code project last year. We and Cédric as well will present results on the next OOoCon in Lyon.

With 2.0 we made a big splash--new technology, new features, new file format. Of course, many of these things had been introduced in 1.x but 2.0 (or anyway the 1.9.x line) was clearly technologically novel. Do you see something like that for "3.0"? Can you hint (or better yet, specify) what new APIs and technology it might include? (And yes, am aware that "3.0" is a little bit of a marketing tactic.)

After 2.0 we changed our release model to having more frequent feature releases. This has an impact on the way we develop features: they will be integrated into the product when they are done and at that point in time they need to have product quality because we will not have an extended beta phase for each and every release. So on our way to a version that deserves the "3.0" version number we will release several minor and micro releases and a beta version. This beta will allow us to integrate some "big" features that we don't dare to deliver in a smaller release time frame.

We are still trying to live in this new world and so at the moment we don't have an exact plan what will be done until the 3.0 release. We don't want to talk about individual user features here, instead of this we can tell you what we are currently working on in a more general way:

• performance improvements (startup, loading and saving)
• stability (not just bug fixing, more in a sense of refactoring)
• modularization of the code base (not as a "big bang", it's a continuous effort)
• looking for features that we can implement together with other members of the community
• improving the development tools (IDE support)
• improving and extending our API
• deployment of "non code" content as extensions, e.g., templates, gallery items, etc.
• improvements in the area of extension maintenance and deployment -- (versioning, dependencies, licencing, signing, updating)

A key point for the integration of extensions is the extensibility and accessibility of the application GUI and so we are currently working on the APIs for this integration and their technical base in the code. As a first step in the 2.0.3 release we have more toolbar controls for Add-Ons that allow much more complex interactions.

Another important addition in 2.0.3 is the ability to export basic libraries as UNO packages in the Basic IDE that will make the deployment of basic macros a lot easier.

Where should developers look to learn more? I would, for instance, recommend the developer wiki, but also the Development page, for starters, and then hit the key lists, such as dev@openoffice.apache.org, dev@api.openoffice.org, and so on.

In the past all development related information was collected on the tools.openoffice.org and development.openoffice.org page. Both pages also offer a lot of links to other interesting pages. While these pages will still be the point where you can get the "whole story," we started with a wiki in last November that not only allows you to add or change content more quickly but also focuses on an easier consumption. You can find the wiki at http://wiki.services.openoffice.org/wiki/ . It is a fast growing resource that already contains a lot of contributions from OpenOffice.org developers around the world.

If you are interested in component or extensions development and you have already swallowed the basics you can meet us on our development lists, especially the dev@api.openoffice.org and dev@openoffice.apache.org mailing lists.

It's also important to add that we are very interested and committed to bettering the OpenOffice.org experience for developers new to the project. For instance, there's an ongoing effort to improving the developer documentation, and a wiki has been started that features examples and tutorials. As well, our Code-Snippet Base, which has many useful snippets of code, is still growing. It's probably the easiest place for a developer's first contributions.

What new features or technology do you think merit most attention?

We think that especially the IDE integration and the extension deployment improvements will be important for extension developers. The first because it should make their life easier, the second because it makes the whole system reliable and usable even in the long term.

Speaking generally, what is the most interesting developer feature you would like to see further developed or implemented?

As we are thinking that the entry to OpenOffice.org development is still not an easy task and we would like to move away some barriers by streamlining our APIs and modularizing the code base. This will reduce the complexity that new developers face nowadays. Another very important feature is the API for GUI programming with OpenOffice.org.

What about so-called "core" development? That would seem to be in many ways one of the most vital development areas....

Now we talked a lot about APIs and UNO and how to work with it. But of course OOo development is more than this: many of us work with the C++ code, the "core modules" and this is still the preferred or even the only way to work on bigger features, especially if they need a lot of UI code.

We would love to get some more developers involved in this and work together with us. We know that there are a lot of barriers, but we are trying to lower or even remove them.

The first obstacle seems to be the build environment, but that's not my playground, so I leave it up to others like Martin Hollmichel and Kai Backmann to talk about it.

A developer that got himself used to the build environment usually will ask questions like these:

• Where do I start my development?
• How can I understand how the code works?
• How can I find the code of a particular feature?
• Where can I add a new feature I want to develop?

You can get some help from OOo developers on IRC [irc.freenode.net, #OpenOffice.org] or the [project] mailing lists, but this is a time consuming process that doesn't scale very well. We need to enable interested developers to find their way into the code with much less permanent help from our side than now. I think we can address these questions by providing more and better documentation and documented code examples. There is already some information available in the fast growing OpenOffice.org Wiki at

• http://wiki.services.openoffice.org/wiki/Main_Page

and the code snippets database at

• http://codesnippets.services.openoffice.org

but additionally we could:

• Describe the general module architecture of the code base
• Explain the general code architecture of the OOo framework and applications
• Assign features to code modules
• Describe typical implementations

and many things more. I hope to talk about this in my presentation at the OOoCon and I'd love to hear suggestions from the community about what else we could do. [The programme to the conference, which takes place 11-13 September, in Lyon, will be published shortly. But all developers of OpenOffice.org should seriously consider attending this conference, as it offers the chance to discuss core technological issues face-to-face with the lead developers.]

Thanks! As mentioned, this is the first in a series of interviews focusing on the current and future technology of OpenOffice.org. Anticipated interviews include one Martin Hollmichel, of Tools, and other projects, and probably one of the most important release engineers.