How Software is Built » cross platform

Interview with Wade Olson – KDE

campsean — Fri, 02 May 2008 23:56:55 +0000

Interviewers: Scott Swigart and Sean Campbell

Interviewee: Wade Olson

In this interview we talk with Wade Olson from the KDE project. In specific, we talk about:

Sean Campbell: Wade, give us a little bit of background on your role in KDE.

Wade Olson: I have been involved with KDE for several years now, both as a contributor and as a member of the e.V., which is the nonprofit organization that represents and takes care of our KDE members. And for three years, I’ve also been in the Marketing Working Group.

I think the origins of KDE are fairly common knowledge; it’s one of the desktop environments for Linux and other operating systems, and we have thousands of contributors worldwide. Its a full-blown desktop environment that handles not only window management, but also the entire application framework, to allow for an integrated experience for the end user.

Sean: What do you see as the key differences are between KDE and GNOME? That seems to be the obvious comparison.

Wade: Obviously, there are a lot of similarities, and there has been a lot of work in building relationships between the two communities. The most obvious technical difference is that they are built upon two different toolkits–C versus C++, GTK+ versus the Qt toolkit. And then also philosophically speaking, GNOME has really put a lot of fantastic effort into the usability and GNOME interface guidelines to allow for a streamlined experience, and they really make sure that their interfaces are consistent. We focus more on the advantages of an interface that gives the user control, flexibility, and configurability.

That being said, when I talk about the similarities between the two desktops, don’t forget that there are various Linux architecture and desktop architecture groups that ensure that everything is done so that the different desktops and their applications are more integrated than ever before.

That might involve such things as the D-Bus system, on which we’ve both standardized, as well as smaller but important things like naming conventions and directory standards for icons so that the different theming engines can make sure to apply icons as expected for Tango or Oxygen or whatever icon themes you’re using.

Scott Swigart: The industry in general has a pretty laser-like focus on usability these days. How do you ensure and test for that? Just like you can’t have a developer check their own code, you definitely can’t let them police usability on their own code, so how do you handle that operationally?

Wade: It’s a fairly complex process. Unlike commercial software efforts, there’s not a strong business analyst layer where they actually go through use cases and make sure that the software adheres to some list of requirements or extra documentation.

Typically, you have members of a technical community who have to put on multiple hats or play multiple roles in the software design, requirements, and analysis phases. That’s how in the past, some Free Software projects have gotten into a little bit of a bind, in terms of usability adherence or making offerings that end up being as pretty or flexible or intuitive as commercial offerings.

To improve usability, we’ve been putting a lot of energy into making sure that all of our development staff understand the importance of usability as a key component for adoption and how to look at their code from a user’s perspective. Fortunately, we have talented usability experts in the KDE community that not only educate sub-communities on usability, they also do reviews and provide constructive feedback.

There have been plenty of instances where there may be competing software applications that are quite similar in what they can accomplish, but in the Free Software world, if one is more intuitive and usable than the other, then the uptake of that one is going to be larger.

The problem is always the person hours needed to do all the things you need to keep up on, like writing the documentation, building the web pages, writing the code, deploying it, and talk to distros that use it.

We’re expanding our user base to more and more people who are not technical and people who are used to commercial operating systems like Windows or Mac, where a lot of money gets spent on interface work and usability work.

Those users have expectations about how easy something should be to pick up, and frankly, it doesn’t matter if it’s free. If they install something or see a friend using it and it looks completely foreign or confusing to them, they’re going to stick with Windows and Mac, and we’re going to miss a chance to get someone to change over.

Sean: There seem to be a lot of retailers trying out selling Linux boxes now–how much are you guys driving towards the desktop Linux user?

Wade: KDE focuses on the desktop environment and the desktop experience, so we are somewhat biased towards that experience. Now, obviously, Linux kernel hackers and BSD kernel hackers can certainly deal with virtualization, hypervisors, and whatever they want, and we have hooks into those layers through the hardware abstraction layer and so forth.

We are certainly interested in general in hooking to the various operating system layers and kernels and being as stable and flexible as we can be with the plugging in of devices, unplugging of devices, hardware recognition, et cetera. But, just by the nature of KDE, more likely than not we’re going to focus on the desktop experience and what we can do to make that the best experience possible.

This is also another layer–people typically don’t go straight to KDE when talking about desktop experience. So if you’re buying a pre-built system off the shelf, there’s a distro in between KDE and the hardware manufacturer. A couple of obvious cases are PC BSD, which is working with iXsystems to make hardware boxes that they sell throughout the U.S., as well as Xandros and the ASUS Eee PC, which is extremely popular throughout the U.S.

So we have hardware from ASUS and iXsystems that help KDE target specific markets. There are people from Xandros and PC BSD that obviously have industry connections that benefit us–we don’t necessarily sit down and think about what markets we want to target.

Scott: There are a lot of components from independent projects that come together, and in a sense, KDE is almost a distro within a distro. How much work does it take to get all of those independent pieces to work together smoothly, especially since it has to work on so many different OSs?

Wade: Everything is obviously driven off the Trolltech Qt Toolkit, and then on top of that there is an additional layer with the KDE Libraries, which is very specific to our desktop environment.

In terms of interoperability, there’s kind of a natural, organic process that subcommunities take when growing out and branching. When you think about the natural growth or evolution, not just KDE but with free software projects in general, something might start with just one or two people that are writing some code. That might grow into a couple more people, and then maybe they have the need for a web page, and then maybe they have the need to be in a larger source code repository. Later, they might start promoting, then start translating it, and so on and so forth.

Typically there’s a natural trajectory that applications take in their growth. Along the way, as individual KDE applications get more sophisticated. they naturally begin to use pre-existing code and connect with other KDE applications. Time spent on development is precious; it should be as productive as possible. It’s not coincidence that community members have created a software atmosphere to enable developers. It has taken a massive amount of effort to make it happen effortlessly, if that makes any sense.

Scott: It sounds, then, like KDE is built up of a lot of different components, but each one of those components is responsible for ensuring their portability to the different platforms, and those different components work together to interoperate with the other components that comprise the overall shell.

Wade: Right, exactly. The first key to interoperability is actually the e.V. organization that I mentioned before, which is a worldwide group that basically keeps track of everybody and makes sure that they all play nicely together. We also rely heavily on IRC and mailing lists, which is where a lot of the communication is done. And that communication is typically involved in adhering to coding guidelines, adhering to usability standards, and really allowing people to say, “Hey, I want to do this,” and that’s where the technical discussions come in–”What’s the best way to implement that?”

We also have working groups. As I mentioned, I’m part of the marketing working group, but we also have a usability working group and other organizations that help keep people in sync in different ways. With KDE 4–as you may have read in some of my blog entries and articles–a very large part of what we tried to accomplish was to set up a common language and infrastructure in what we called the Pillars of KDE. So if you look at a multimedia framework with Phonon, the look and feel across websites and our desktop environment via Oxygen, hardware interaction, PIM data storage with Akonadi, almost everything we did was to create a pillar for a common language in a common technology to allow people to quickly and easily build applications.

If you abstract away all that complexity, almost by nature you get people working on the same page, when you take away the difficulty of connecting to a CD ROM or an FTP server, for example. It’s important for code consistency, it’s important for code complexity, and it’s also important for making developers as productive as possible during their limited time, since, for many people, this isn’t their day job.

Sean: Let’s talk about the Trolltech/Qt acquisition, starting with the question of why you think Nokia bought it, and what do you think they’re going to do with it, and what effect does it have on you?

There’s an interesting dynamic happening in the past year or so, where companies decide they love a certain open source project, so they buy it and plan to build on top of it. A lot of nervousness tends to develop around those acquisitions, about things like how much there is still going to be a community process behind it and how comfortable developers are going to be continuing to contribute.

There are successes all around, like Red Hat’s been great with CentOS. The jury is still out about MySQL with Sun, since it’s still a brand new thing, but Qt must have cut right to the bone with you guys–what’s your feeling about it?

Wade: Let me preface by stating that I’m neither a Trolltech nor Nokia employee, so opinion has the same weight as any other observer. If you look at issues that people have had philosophically and historically with KDE, from a Free Software standpoint, it was with the affiliation with Trolltech and Qt and the licensing. So because of that, for the past several years, Trolltech has truly gone out of their way to try to eliminate all of those obstacles and barriers and frustrations that some of the people that are on the very free side of the open source spectrum have had with this affiliation.

They’ve created various poison pill contracts and things that have really said that no matter what happens, Qt is going to be there for KDE to use. And there’s no reason to expect that there was anything nefarious going on. This was with best intentions, and they have certainly spent time and money with lawyers to make sure that everything was locked up from a licensing standpoint. We take them at their word, and we are obviously appreciative of that work.

I don’t think there’s a lot of necessary concern or fear from the fact that it might go away, because certainly there are various abilities to fork and continue to use this freely. It’s not as if it just goes away, and KDE is left standing out in the cold.

With Trolltech lately, we’ve been hitting this great stride. You may or may not realize that they do sponsor several KDE developers, as well as get-togethers and meetings that we have. Some of the code they write now with WebKit is beneficial to us from a browser perspective. They have integrated WebKit into their code repository, based off of KHTML and work by Apple in the WebKit community. And very recently, they’ve been doing all of the Phonon multimedia work in our SVN repository, completely openly.

So, really, I think the only concern that I’ve seen in the KDE community is the fact that things have been going so well that we just are praying that it continues with Nokia and that things don’t slow up. Might they fund as much? I have no idea. Might the developers be forced to work on other things? I have no idea. I just know that things have been going so swimmingly, that’s the only apprehension.

I do know that people are talking with Nokia, and Nokia is doing all the right things thus far, as I understand, as far as scheduling meetings and talking about intentions. I don’t think they want to screw up a good thing, and trust me, with that toolkit, there is certainly a hugely beneficial relationship between KDE and Trolltech. Who better to test your toolkit and provide feedback than hundreds of talented programmers stressing its capabilities and millions of users?

Sean: How does a closed source company not screw up the acquisition of an open source one, in your mind?

Wade: I think the key is to really go back and actually look at the various motivations of why someone would commit their own personal time and vested interest to work on something like this. We’ve already talked about why some open source projects work and why some fail. It’s all about people having an emotional connection and attachments that make it more worthwhile to them than doing something else, whether it’s working down at a soup kitchen, working for a nonprofit, or sanding their hardwood floors, for that matter.

Some people spend their free time doing it, and some people get paid to do it. But either way, it’s the emotional connection, and it’s the passion, and it’s the community that builds around it, and the friendships. Trust me, KDE’s code is exciting, but it’s not that exciting. People love to work on it because they love to get together and talk about it, and they have the same passions and interests. That’s where companies really need to look. They cannot screw up that ecosystem.

Even a company that really gets open source–like Red Hat, when they buy JBoss–has to think about the community. And the fear is, what if all of the people go away? Because now it’s a corporate entity that people might not be interested in, instead of their little, home grown, comfortable part of the world.

Scott: Old-school open source projects like Linux and Apache don’t really have a chief sponsor that’s driving the development. But some of the more modern open source projects–like Alfresco, Zed, and PHP–have a company wrapped around them that’s really driving a lot of the innovation, and we’re starting to see a wave of those companies being acquired by these much larger companies.

The thing that I wonder is, if these large companies do screw it up, they have essentially paid a whole bunch of money for nothing, because one thing open source lets you do is fork the code. It isn’t far enough into the future yet to see how this all plays out, but one could imagine that if Sun really mismanages MySQL, somebody else could form a company around it. The same thing with Qt or Zen or any of these other things.

Wade: Obviously, because of licensing considerations, different projects have different options when things like this happen. I have not pored through the licensing on Qt in particular, and I can’t tell you what will or will not happen, or how poison pills are engaged, or what the ability is to fork it.

In general, though, not only are companies paying for historical results, but they’re paying for future results as well. They are certainly are not just paying for the MySQL historical codebase and saying, “OK, thanks, we’ll take it over now,” but they still want those people to contribute, and they still want it built upon.

Scott: Right–they’re paying for the mindshare. To me, what they acquire when they acquire these companies is not the code, but the expertise around the code.

Wade: A somewhat similar situation could be considered with any open source community that relies on Java, for example, like the Eclipse community or JUnit, or any one of many Sourceforge projects. Sun could have taken them any which way. They could have closed down Java, or locked it down, or stopped working on it, or open sourced it. That was up to some speculation as well.

You have to hook your horse up to a cart, and that has obviously played some role in the GNOME community saying “We want GTK. We want our own toolkit, and we want it to be free.” There are benefits and detriments of closed source versus open source. Qt is what it is, and it’s incredibly powerful, but it’s not entirely free because of that.

Scott: Remind me what different platforms KDE runs on outside of Linux.

Wade: It runs on BSD and Linux and any *nix platform, and there’s actually a lot of renewed interest in having it run on Solaris. Obviously when we talk about Plasma, the desktop itself, that’s only going to run on Unix like systems that we already do. On the application level, as long as you have the KDE libraries and the Qt framework–which is cross platform–then it is game on. Going forward, we’ll see KDE applications run and run well on Windows and Mac platforms.

It’s just a matter of figuring out all the nuances–what exactly makes something cross platform in theory as well as practice: installation directories, multimedia engines, rendering models–the stuff that makes Windows and Mac different.

Scott: I guess the reason I ask is that to projects like OpenOffice for example, cross-platform is very important, whereas it seems like KDE could get away with being mainly a Linux thing.

On the other hand, OSs like Solaris and OpenSolaris might be important because they create a little bit of competition with Linux, which is probably healthy for both Solaris and Linux. In your view, how important is it for KDE to be cross platform?

Wade: There actually has been a fair amount of debate on that approaching the 4.0 release. Obviously, when people work on things that they want to work on, there’s really no stopping anyone. It’s not as if you can just assign someone to work on a task. It’s not a development job where you can say, “I’m sorry, I don’t want you working on that anymore. I’m assigning you to project 123.”

If you don’t want to waste resources having someone work on KDE and Solaris, you can’t just say “Go back to working on BSD. We need to fix that up.” It’s really all based on people’s interest level, and that’s the secret to great code–when someone has passion for an area.

It comes down to the “can do” versus “should do” question–we can do a lot, but should we do it? From a marketing standpoint, my stance is that if someone’s going to work on it, just please do it well. If you think about how people get exposed to KDE and open source and Free Software, you always want the first impression to be a good one.

KDE is obviously at home on Unix and Unix-like operating systems, and then there was the expanded ability that people could view it through VNC or RDP servers to actually connect to a remote client and see what KDE and open source and Free Software is like.

Then it was expanded further with the Live CDs like Knoppix that spin up. Then it was expanded again with VMware Server and other virtualized servers, where you could literally be on Windows and just get a VMware image and boot it up and see what it’s like. The final frontier, then, is the application layer where we’re actually installing and deploying applications on other platforms.

Again, from a marketing standpoint, I just say please make it a good first impression. I am not interested in leaving a Windows or a Mac user with the impression that it’s half baked or not as good as it should be.

There was debate about whether would it drive people to use KDE or Free Software in general. We talked about whether OpenOffice and Firefox have necessarily gotten more users onto platforms like Linux or BSD or Solaris. A lot of Windows users probably say, “Hey, that’s great. I’m going to continue using Windows with these free applications.” Is that a good thing or a bad thing?

So, if you’re porting for KDE adoption and recognition from an application perspective, you’ve got millions more people that you could reach. However, if you’re looking for people to make the move philosophically to Free Software and to have that desktop environment, maybe you’re actually hindering your cause. That’s where the debate comes in, and that was an interesting period of time.

People basically said do what you want to do, and please do it well. If nothing else, what we’re looking for is to increase visibility and awareness of KDE and the world class software that we’re making. In addition, we want to let developers know that a lot of people that write free software for Windows and Mac, and that there are other options that they have as well that they might take an interest in, and we might grow our developer base.

Scott: That’s always been one of the things that’s interesting to me about open software. Closed source sometimes has to guess what people are going to want. They have to be very speculative about the features and plan the next release and try to make sure they have “killer features” that are going to make people upgrade and that kind of stuff.

Open source often takes the approach that if a feature or capability is really important, it’s important enough that somebody will show up to do the work.” And if nobody does, it shows that maybe it’s not that important.

Wade: Right. You figure out the source of the priority and the urgency. Was it Sun Microsystems saying, “I want this to work well”? Was it a couple of influential users? Was it something strategically that needed to be done? It’s very interesting what is worked on and not worked on in free software, and that’s obviously not specific to KDE.

Scott: Great. A lot of times, when we get to this point in these conversations, we’ll hand the microphone to the interviewee and say, “What did we not ask about that you think is interesting?”

Wade: This interview is happening just after our big 4.0 release, which we worked on in parallel to the 3.5 series for years. That’s a big deal, and it really is like the architecting and building a house analogy, where we have worked on the foundation to make this series one that is just going to be modern and performant and stable, like any other commercial offering, or better, over the next several years.

And certainly, there has been much press and discussion about whether we released too late, too soon, what the expectations were, did we over-hype it, etc. A lot of people were saying, “It should’ve had another release cycle,” or “It should have had more QA,” or “Why didn’t you just wait for the next thing?” Everybody chimes in with their pet project and why it should have just waited just a little bit longer, until their particular area of interest had been satisfied. So that’s certainly one thing that was tough.

Obviously, there was a massive amount of forethought and discussion and reasoning, because the 4.0 release was very significant, and any time you’re planning on something to be the foundation of your entire community for the next 5, 6, 17 years, you don’t do so lightly.

We’re very excited about it, and I think people are going to see that the upcoming releases are going to show very accelerated development. During the crunch time leading up to the 4.0 release, when you looked at the speed of commits to our code base, as well as the number of people working on it, just as with any software project right before the release, you saw a swelling of activity.

What’s been amazing is that it hasn’t slowed sown, now that the release is out. People did not take a breather and say, “Oh my God, I made it across the finish line. We got Version 4 out.” It’s actually only grown. Week after week, we have more and more application developers going in and saying, “I’m going to use that framework and port my application over to the KDE 4 code base. I’m going to use these new libraries and toolkits and Pillars of KDE that you’ve given me.”

With upcoming releases, I think that’s going to prove out how quickly this code base matures and how quickly things become stable.

Scott: There’s no better measure of success than people adopting it and moving toward it. In any community, but especially in open source, you’re always kind of herding cats, and there are always going to be strong opinions and outspoken people. You can never be everything to everybody, but if you’re getting good adoption, that’s the best validation that you could ask for.

Wade: I think, historically, things are going to point to this being the correct decision, to release at this time, because the foundation, the architecture, the pillars were sufficiently mature, from an API freezing standpoint. We’ve really seen an uptick in the QA loop, the feedback, and the amount of people that are going in and reporting bugs. A lot of applications are going in and using this technology now.

Obviously, if we would have delayed to work further on some things, we would have postponed the involvement of other groups, such as translators and documentation writers and QA and things like that.

The important thing is that at our release event, we announced that we have a very standardized release schedule going forward, so that distros can plan on those releases happening, where we have smaller sub point releases every month. And we’ve adhered to that thus far, where, in February, and now in March, we’ve had 4.0.1 and 4.0.2, and that the major point releases are going to be every six months, and so we plan on 4.1 coming out late this July.

Scott: Well, thanks for talking today. This has been a great conversation.

Wade: Thank you.

Bookmark this:

Interview with John McCreesh – Marketing Program Lead – OpenOffice

campsean — Sun, 05 Aug 2007 21:03:49 +0000

Interviewers: Scott Swigart, and Sean Campbell

Interviewee: John McCreesh – Open Office

John McCreesh

In this interview with John who is the Marketing Program Lead for Open Office we asked him about:

Scott Swigart: John, thanks for taking the time to chat. Could you take a minute and tell us a little about yourself?

John McCreesh: I have been doing work on a voluntary basis for OpenOffice.org for five or six years now. For the last year I have been leading the worldwide Marketing Project.
My day job is in big commercial IT shops. I got into open source during the .com era – I suddenly found this wonderful world outside! As I’ve got a technical background, I started hacking for projects and then after a time decided I could probably do less damage by marketing than hacking. So that’s where I am now.

Scott: OpenOffice.org is interesting to us because a lot of the open source projects that we look at are things like the Linux kernel or Apache. Those are almost by developers for developers, to some degree. The feature set is driven by the developers who work on it. OpenOffice.org is different in that it doesn’t target IT professionals so much. It targets end users, right? The users are people who are producing documents, essentially.

So I’m curious, with OpenOffice.org, what’s the mechanism for features to get proposed, to be slated to be worked on? What’s the process for people deciding they are going to work on a particular feature? How does that work? Because it seems that it would be different from something like Apache.

John: That’s right. I think the traditional open source model is very much about scratching the itch. If you are a developer and you are not happy with the editor that you are using then you go off and write your own. That model does not apply in OpenOffice.org where as you say, it is much more of an end-user tool.
I suspect a lot more of our developers would sit down and write a document with Emacs than they probably would with OpenOffice.org.
The thing is though, lots of people get a big kick out of developing for a project that their mom and dad use, or the kids use, or they can take around and hand out at the school and say, “Look, you can use it for free and I am one of the people who helped develop it.”
Another thing is that this is a huge piece of code. So, for developers that poses challenges, compared to a lot of traditional open source projects which are comparatively small in terms of code and have a small number of developers.
The development methodology of breaking things down into small modules makes it easy for more people to work in open-source. But, OpenOffice.org has grown up over 15 years, so there is some very old code there and there is some very new code there.
Getting developers in to find their way around and to make contributions can take a bit of time. But equally, if you’re technically inclined, to get some code in there, to build OpenOffice.org, and see your work coming up the other end, again, that’s a big achievement.

Scott: Right.

Sean: When we talked to Stormy Peters, one of the things we talked about is how products take in end user requests, But So with that in mind what is your the overall process with OpenOffice.org for taking in a user’s request likesuch as, “I would like the ability to handle text editing just a little differently here because my boss wants me to.” But they have no ability to write it. In other words: What’s the process for getting those things integrated?

John: Yeah, we sometimes get interesting conversations between developers who say, “Well if people want this, why don’t they just write it, or find someone that can write it?” I think one of the challenges for us is to bring together people who’ve got the ability to respond to the user’s requests, and to get the users to put the request together.

We have the standard open source toolkits. Anyone can raise an issue or raise a request for an enhancement on our website. It will get checked to make sure it is valid. Other people can go in and support it, add notes to it and so on. So there is that traditional open-source process: people vote for things. It is an entirely open process and you can see whether what you’re looking for is commanding support in the community.

But equally we have a fair number of developers who are paid to work on the project. So, Sun Microsystems’ developers take the OpenOffice.org code and release it as StarOffice. Like any commercial software house, they have big customers who say to them, “Hey, you know this particular feature of StarOffice is poor. Can you do something about it?” If they’ve got a support contract with Sun, then Sun will put some developers onto it and they will get into the OpenOffice.org code base that way.
Similarly, when Novell started looking at the code base and decided to take OpenOffice.org and make it a significant part of their SUSE offering, they started using it internally themselves. There were things that they thought, “Yeah, we need to do this. We need to add this feature. This is important to the kind of market we are going to sell in.” So again, they took some of their developers and put them to work on it.
So OpenOffice.org is a combination of the traditional software model where you have a software company who listens to its users, plus input from users around the world.

Sean: What percentage of the new features that go into OpenOffice.org do you think are driven by a developer request mostly from soup to nuts or vs. what is onethose that is are driven predominantly by an end-user request but then just implemented by a developer?

John: That’s a tricky one.

Sean: Do you think it is equal or is the product still driven by developer input more than end-user input?

John: Well, it’s hard to say. One of the things that people said to us at the launch when we released the Version 2 product was, “Yeah, you’ve got all the functionality that we want but can you make it run faster?”

Now, from a developer point of view, a lot of the hacker community was really motivated by this. The thing about making more efficient code and making it smaller and leaner and all the rest of it really rang bells with a lot of people. That was something that had tremendous developer appeal, but it also has real marketplace end-user appeal. So I don’t know whether you would say that was driven by end-users or driven by developers. It was a happy area where the two interests coincided.

Sean: OK.

Scott: So on an open source project there is usually a chief maintainer right? If you take a look at the Linux kernel, it’s Linus Torvald who ultimately gets to decide what’s in or not. Is it Sun Microsystems that’s the final arbitrator of what gets checked into the main source tree and what doesn’t?

John: We have an Engineering Steering Committee, or ESC. It’s the ultimate arbiter if there are disputes about what goes into the code or what doesn’t, and the general technical direction of products is decided there.
On a day-to-day basis, the project is too big for any one person to sit there and say, “That goes in and that goes out.”

Scott: Right.

John: So OpenOffice.org is divided into a number of different projects, where the project leads have the ultimate say as to what goes in or what doesn’t go into a particular build.

Scott: OK. But I’m guessing that because Novell and Sun are so involved in it that some of their people would be owners of these different subsystems?

John: Yes. And I think that’s perhaps going to continue more and more as more commercial companies sponsor developers.

Scott: And that’s not uncommon. The one thing that I have heard across the board with open source is that company involvement is not a bad thing. Open source owes a lot of its success to the fact that IBM, Sun, Novell, Intel, AMV; other corporations are paying developers full time to work on it. So that’s an integral part of the process.

John: Yeah, I saw some analysis years ago about the Linux kernel. At that stage most of the contributions were coming from people who were paid by corporations.

Scott: Yeah, I would guess OpenOffice.org isn’t any different. I mean, when you take a look at a product that’s this large, that is this complex, there is a decent barrier to entry—I would guess—in really being able to get in there and really understand the code base, really develop experience with it, really understand the architecture and just get to the point to where you can make good, clean contributions that are going to add features or fix bugs and do it the right way.
For a lot of these projects, they have grown to the point where there is a high barrier to get to the skill level you need to get that to be able to do that. So it makes sense that the people who are being paid to work on it are naturally going to have an advantage in just really be able to produce the quality of code that is going to ultimately make it in.

John: One of the changes we have tried to make with the architecture in the past couple of releases is to open up the product more for extensions.

Scott: Yeah.

John: People who aren’t as technically skilled, and will find it a real challenge to go through pages and pages of code (some of which might be commented in German) and try and make sense of it, are quite capable of providing functionality in the form of a plug-in.

Scott: That also seems to be a key factor in the success of a given open source product—that it has a good extensibility story. It has a good modularity story. Apache is a great example of that. To work on the Apache core there is a high bar. But to write modules—anybody can do it, essentially.

John: Firefox is another classic example of that. It’s used a lot. Again, the developer gets a real kick out of seeing their piece of code looking as if it is part of the core product. Once you have incorporated the extension into the menus and in the help system, etc. then as far as anyone looking at the product is concerned, you have written a piece of Firefox or a piece of OpenOffice.org code.

Scott: Right, right.

Sean: I have a question about the new features. How is the QA process handled? A lot of our conversations have taken us in interesting directions as we talk to people who submit stuff, not in any pejorative sense for an open source but it just is interesting how who are contributors as the process of checking in code, andgoing through the process of validating it differs from project to project in terms of the rigor or the processes that go about it. So how does that work for OpenOffice?

John: There are two schools of thought. In OpenOffice.org there is the “Community OpenOffice.org”. So if you go onto our website and download OpenOffice.org, that is what you get. There’s also a hacker’s version of OpenOffice.org, which doesn’t go through the Community QA process. This version feeds into some of the Linux distros, who will take this code and will do whatever QA they feel is appropriate around it.

So if you want an absolute leading edge of OpenOffice.org, you go to the hacker’s version. If you want something that has been through quite a structured QA process, you go for the community version, which is what we do.

Scott: The community version, is that…? Who is ultimately responsible for doing that QA? Are there QA teams within some of the corporate sponsors of OpenOffice? Is it more of the responsibility of the distros to do that QA as part of putting their distro together?

John: QA is one of the OpenOffice.org community projects, which runs one of the most widely geographically distributed QA processes I have ever seen, because it’s not just a matter of getting the American English master version correct.

Scott: Right.

John: The native language teams in all the various countries will go ahead and do a QA process on their own build. Ultimately that’s one of the things that controls how quickly we can release. We used to go for long periods of time between releases. A couple of years back we looked at that and decided it was putting developers off. If you have to wait a year before you can see your code emerging into the marketplace, you’re not really very interested. We’re now down to about four releases for the year.
We would like to do more but the QA process is a limiting factor.

Scott: Sure.

John: Similarly for the hacker’s version of the code: if Red Hat or Ubuntu decide to use that as their source, they have to put it through whatever QA process they feel is appropriate for their marketplace. We all have tradeoffs between features and a stable product.

Scott: Yeah, yeah. And things like documentation also—is there a documentation team as part of the project as well? I would guess that would run into the same localization challenges because the product is such a global product.

John: That’s right. We also have a Documentation Project that does user guides and manuals and how-tos and all that good stuff. But there must be about a dozen other independent sites on the web where people have set up help forums or wikis or whatever.

Scott: Gotcha.

Sean: How much of the documentation creation is deflected or is tuned based on gaps you find that users are asking for? How much documentation is written because someone feels a personal need to write that documentation, or because they know people have struggled with it—similar to a developer adding a feature just because they need it?.

And how much of it is driven top-down from OpenOffice, such as, “We see X amount of requests for this, we need to build a doc set out to cover that need?”

John: It’s a mixture of the two. The way that I got into the OpenOffice.org project in the first place was I wrote a piece of documentation – a ‘how-to’. I’d been playing with the database stuff, thinking “Hey, this is really cool.” But it wasn’t not obvious how you got into it or how you found it in the menus.

So, I asked a few questions on the lists, and wrote the how-to. That got a fair amount of circulation, so I realized there was obviously more to OpenOffice.org than meets the eye. And that was how I got into the project.

So, an awful lot of that goes on. You can never have too much documentations and how-tos for a product as big as this, because different people have different learning styles and different needs.

Sean: One last follow-up on that. Are there types of documentation or areas of the product where you find that maybe there’s a pocket missing content-wise because it’s more community-driven versus top-down?

And are there any defined areas where you feel there is a gap and you have to motivate the community to contribute in a particular area?

John: I think the problem we have is the old Google phenomenon, that there is now such a mass of stuff out there on the web, it’s tricky finding the stuff that may be current, knowing what versions it applies to, and then finding the information in the form that you require.

We usually do one big master user guide, which we publish on the web. It’s also available from one of the publish-on-demand organizations, so you can order paper copies of it from there.

But apart from that we don’t try and have a monopoly on documentation because there are just so many other people out there who want to do it.

Sean: But you would say that if there is a pain point of sorts, it is that, “OK, I’ve Googled how to do mail mergex, but I don’t know if it’s the appropriate steps for this version of the product.” You know what I mean?

Or if it is, it might be missing an extra step that could accelerate ithe process of getting the job done from a user perspective. It’s like you said, you could solve a lot of developer problems by Googling them. That’s almost like Step 1. But on the other hand, you’ve got to make sure it maps to your version of the API, your version of the development tools, those kinds of things.

So, that’s a fairly accurate reflection of the main pain point.

John: I think so. We can produce a master reference manual, but it is in reference manual style, and some people find that off-putting and they’d like it more conversational style.

Sean: So, one question that I have is in OpenOffice, one of the key features is its cross-platform nature. It runs on Windows, it runs on Mac, it runs on every Linux distribution. Do you have any sense of how much development effort goes into ensuring that it is supported and runs well on all of those different platforms compared to the effort that is put into building new features?

John: I think it’s back to the QA limitation, that the more that we officially support, then the more testing that you have to go through. It’s also a major technical challenge because, if you’re completely cross-platform, then in a sense you’re always slightly sub-optimum on any given platform.

Scott: Well, that’s another question. Does OpenOffice.org strive to have full fidelity across all platforms? Because I know that some open source products go the route of they’re really optimized for Linux, and they’ll run on Windows or Mac or things like that. But they’re not 100% the same experience. Do you know if the philosophy of OpenOffice.org is that the experience and the features be 100% and the same, even if it means that it’s not really optimized for any platform?

John: That’s effectively where we find ourselves.

Scott: OK.

John: This is why the Mac port has taken such a long time, because the Mac is such a specialized platform and Mac users want all their applications to look just exactly like a Mac application should do. So, it’s quite hard to do that and still maintain the cross-platform thing.

Scott: So, there’s a core that’s really generic, but then for some of the presentation layer stuff, there’s actually Windows-specific code, Mac-specific code, you know, Gnome- and KDE-specific code.

John: We provide for example a common file selector out of the box. Or you can switch it off and say, “Just use the native file selector for my platform.” But the more of this you offer, the more your documentation has to be platform-specific. The common look and feel that makes the documentation piece easy to do.

Scott: Right.

Sean: This is in a different direction, but there’s an argument that goes that certain products in the open source world tend to follow rather than innovate. Sometimes OpenOffice.org is held up by that, right?

It’s trying to get to some base level of parity with either the most recent or the current version of the obvious competitor, which is Microsoft Office. But adding features that leap ahead beyond the current evolution of the office product isn’t typical.

I mean, just this statement, what’s your general response to that, when you bump into that? Because I’m sure you must have, at least at one point or another.

John: The problem is that office productivity software is a mature market. It’s been around a long time and we’ve been through the WordPerfect and the SuperCalcs etc.. By now, people know what they want out of an office software product, and they also have an expectation about how it’s going to look and feel. You know, where they’ll find things on menus.

So, you need quite a strong driver to go out and break out and produce something radically different. Chances are that unless it fundamentally gives people a better way of working, then they’re not going to accept it. Why would they learn this whole new thing if they only want to write a memo? They already know how to do that.

Sean: I guess in a product like OpenOffice, what would be the path to innovation? If you’re saying, let’s imagine a world where both are free, right? And we’re trying to equate it based on our level of productivity benefit to the end user and those kinds of things alone.
Where do you think OpenOffice.org or another product that’s a productivity suite, can have a leverage point there, I guess?.

John: Let me tell you where I think this happened. When we launched Openoffice.Org 2, we closed all the functionality gaps between OpenOffice.org and Microsoft Office. So for the average user, what they do 90% of the time is absolutely no different on either package. We recognized that and Microsoft recognized that.

So, our response was, well, the one thing that people are telling us is that, “OK, maybe we’ll move to your software, but every time we move we’ve got all these data conversion errors, or data conversion problems”. Or “I spend all my time writing these documents, but unless I’ve got your brand of software, I still can’t access my documents.”

So, we were hearing a demand from users that they wanted to own their intellectual property, the documents and spreadsheets that they’d created, independent of any software supplier. This took us off down this road that is ultimately the OpenDocument Format that you’re well aware of.

Sean: Yeah.

John: So users got an ISO standard for how office data should be stored. Once you’ve got that, then no software vendor can ever lock you into a product again. And it makes it easier to get your data and use it in corporate systems and all that good stuff.

So, that was our response to “how do we differentiate ourselves in the marketplace from Microsoft?” We knew that Microsoft would have grave philosophical difficulties going down that route.

At the same time, Microsoft looked at the same problem from their side and went, “What can we do to put a gap between ourselves and OpenOffice.org?” And their response was not actually to add new features or change the core of the product, but to change its look and feel.

This is where we got the Ribbon and all this other stuff. Sure, it looks different. Their response was pretty much a consumer-driven thing. “Let’s make it look sexier in the marketplace. Let’s get it looking so sexy so that people see it at home and then they go back to work and say, ‘Hey, we’ve got to have this Ribbon thing at work.’” It doesn’t actually add anything to their productivity, but it looks cool.

So, Microsoft has gone off in one way, which is a consumer-sexy-look-and-feel thing, and we’ve gone down the more technical route. What people are telling us on the domestic side is they want to know that their grandchildren will be able to pull up Granddad’s diary from 50 years ago and still be able to access it in whatever office software they’ll be using then. On the commercial side, public administrations worry that 20 years from now, someone’s going to come slap on with a Freedom of Information Act requirement to dig out some documents they’ve filed today. Are they going to have the word processor that wrote that document 20 years ago? Absolutely no chance!

So, the ODF development was our response to that demand for freeing the data from the application. So, was that innovative? I think that was hugely innovative. I think it was far more innovative than Microsoft’s response – . they got a few bells and whistles and their menus look a bit different.

Scott: Something like the Ribbon, that’s an interesting point, because how does OpenOffice.org make a decision about whether or not OpenOffice.org will adopt that look and feel or not?

Because I think that’s been a debate. OK, Microsoft significantly changed their look and feel, should OpenOffice.org do the same or not? What’s the thinking on that? And, I guess, how do you make decisions like that?

Sean: And –before you answer that—one of the things that I’m pretty cognizant of is that part of the change for the Ribbon was obviously just change itself. And then the other part of the change was driven by some studies that said, “Well, let’s put the first thing a user wants to use first in the Ribbon, etc.”

There are a lot of arguments about the decisions that were made, right? One person’s choice might not be another’s. But that was the driving influence too. But And to Scott’s point, how would something like that come to fruition in the OpenOffice.org environment? If it was deemed necessary, obviously…

John: OK. The Ribbon thing is one of the best things that happened for us for a long, long time, because over the years, we were sick of hearing arguments that said, “OpenOffice.org menus are slightly different from Microsoft Office’s, therefore, if we’re going to have to migrate people, it’ll cost us billions of dollars to retrain everybody to know that option isn’t here, it’s somewhere else.”

Scott: And now they’ve given you even a bigger change on their own end, right? So, yeah, there you go.

John: It’s a much simpler migration path from an end user perspective to go from current Microsoft Office to OpenOffice.org than it is to go to completely new Ribbon-style interface.
Will it catch on in the marketplace? I don’t know. I think it’s a big gamble on Microsoft’s part. They’ve tried a couple of times in the past to push the market in ways the market has eventually revolted against. They have had marketing failures in the past.

And it also takes an awful long time to get people off legacy versions of Office. There’s never very much more than low double-digit numbers of people using the latest version. So when latest version is such a big step change, it’s a big gamble for them.

Would we ever go the same route? Well, if five years from now, if everybody in the world has decided that Ribbon is the way to go and that’s what they want in a product, I suspect we will have to do something similar or come up with something better and convince the world that’s there’s a better way to do it. But at the moment the jury is very much out.

Scott: So in other words something like that, the prudent thing to do is to take a wait and see approach, in other words.

John: Exactly, just as Microsoft is doing around ODF. It’s doing its usual thing of trying to say, “Well, OK, if you want a standard, we’ll invent the Microsoft standard, and try to sell that to the world.” So that was a fairly predictable response.

Scott: Now, I thought I did read something saying that Microsoft was going to allow something like a “Save As ODF.” I thought recently there’d been a change in their thinking on that. I mean that’s outside of the scope of this conversation. But it seems like I bumped into that, but maybe I, maybe not, I don’t know.

John: What they have done is they’ve offered some support to an open source project to set up converters – ODF plug-ins for Office. Part of their recent agreement with Novell—and I think there’s something with Linspire as well—had some clause in it about working to get more file compatibility.
So, they’re not stupid. They’re keeping in touch with the technology, finding out how it works, so if they do find the market is forcing them down that way, you know it’ll be a comparatively easy thing for them to quietly drop into the next release of their product.

Scott: OK, I get it.

Sean: Well, one question on that too. So would you say that one of the strengths of open source is that you’re not going to push for a change as significant as the ribbon unless the user base asks for it? In other words, you won’t push a change like that top-down and if the users aren’t asking for it then a wait-and-see approach makes the most sense because nobody’s asking.

John: That’s right. It’s hard to think of anything where we’ve gone to change for change’s sake. But, equally, if one of our developers came up with a really cool new feature that no one had ever seen in an office suite before and, and we looked at it and thought, “Hey, that’s, that’s wonderful,” we’d do everything in our power to get it out into the product.

Scott: Well and I guess too you guys have the option of, like you said, there’s the hacker’s build, there’s the experimental build, and it seems to me like a lot of things could be tried out there, and if they caught on and were popular, it might make sense to move forward into the stable tested one.
Is that how it works? Is there a Darwinian effect with features where, somebody codes it up and it makes it into the hacker’s build, and then it either lives or dies there? It either catches on and it makes it into the, the community one or it doesn’t and it doesn’t.

John: Yep, that’s been a route in the past and we think the extensions route will be a much faster way in the future. So if someone brings out an extension, and we see that everybody and his dog is downloading it and blogging about it saying how wonderful it is, and if it makes sense to put that into the core product, then that would be a very good way of moving the product forward.
But, equally well, if it’s working well as an extension then why would you want the overhead of putting it in the core product, unless from a maintainability or efficiency or some other reason?

Sean: Well, what, what, one question I want to ask goes back to the original genesis of what we’re trying to accomplish in our investigation, “if the question was posed to you, “OpenOffice.org is predominantly an open source project. Microsoft Office is obviously a closed source project. From a development methodology standpoint, what would you say are the important characteristics that are advantageous on the OpenOffice.org side compared to Microsoft Office?”

Scott: What Sean is going for is what do you see as some of the biggest advantages of having OpenOffice.org developed as an open source product? What comes out of the open source process that is very advantageous?

John: OK, from a developer’s point of view clearly it means you know anyone can contribute to the project without being a Microsoft employee. From a general marketplace perspective, the appeal of open-source is it’s a transparent process. Anyone can request features, record bugs, whatever. If you’ve ever tried doing that with Microsoft you’ll know it’s not a transparent or efficient process. Anyone can come along to the OpenOffice.org conference and talk to developers and buy them a few beers and say, “Hey! Why don’t you come work on what I’m looking for?”

Then there’s the whole issue around openness of what’s in the code and what isn’t in the code. There’s been umpteen conspiracy theories over the years about Microsoft back doors etc. OK, most of those are just Internet conspiracy theories, but for a lot of governments in the world who are suspicious of big corporations, the fact that they’ve looked inside the code, seen what was there, get their own people looking at it, is very important.

And finally, software companies come and go. Even Microsoft will go someday. If you own the code or if you can get a copy of the code you’re guaranteed that you can run it just as long as you can compile it.

Scott: John, thanks for taking the time to chat.

John: Thank you.

Bookmark this: