If you are looking for subjective opinion, I recommend looking through the interviews we’ve done here. At the risk of sounding like a Microsoft fan-boy, the Microsoft interviews (in my opinion) demonstrate a company where secure coding is “in the water”. Code goes through threat modeling, risky function calls have simply been banned, code goes through automated and human inspection, and vulnerabilities that do slip through feedback into the process to determine how to prevent them in the future.

I simply don’t get the same feeling from the open-source people we’ve talked to. When we’ve brought the subject up, the response is almost universally “many eyeballs,” and faith (without data) that “many eyeballs” is effective.

Am I completely off base? Do things like the Linux kernel and Apache go through rigorous security reviews? Is there proof that “many eyeballs” in open source is at least as good as something like the Security Development Lifecycle in Microsoft? If you’re in a position to know, let’s chat!

Bookmark this:

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:

• What the process is for delegating work out to members of the OpenOffice team
• How OpenOffice handles end user requests for features
• The engineering steering committee for OpenOffice
• Large Company contributions to OpenOffice
• How the Q/A process is handled for OpenOffice
• How OpenOffice generates appropriate documentation for end users
• How much goes into keeping OpenOffice cross platform (Mac, Linux, Windows) vs. emphasis on creating new features.
• The Office 2007 Ribbon, innovation, and standards as it relates to OpenOffice

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:

Interviewee: Marc Miller

In this interview, we spoke with Marc Miller about his views on the current state of open source software.  Marc works for Advanced Micro Devices (AMD), and in January, Marc took on a role as the open source software evangelist in the AMD Developer Outreach organization enabling Linux kernel and application developers to develop optimized code using both AMD and 3rd party tools and resources. In his role as a software Alliance Manager for AMD 2001-2006, Mr. Miller played a significant role in developing a Linux marketing strategy with a focus on integration of AMD technology with software tools developed by the open source community and industry partners. Throughout his career at AMD, Marc has been a key contact for open source developers wishing to work with AMD, and has been an open source ambassador for AMD, helping to coordinate outbound and inbound communication between AMD and Linux developers.

In this interview Marc talks about:

• Challenges that open source companies have when competing with proprietary software
• Advantages of open source
• Choice also has disadvantages
• Is open-source anti-capitalism?
• The PR value of being open-source
• Open-source is less idealistic and more pragmatic today
• The future is blending open-source and proprietary software

Richard: First off, I have to ask what you think about the idea of Microsoft funding a blog that looks into the differences in delivery model between open source and closed source. Do you think it’s possible that that blog would be unbiased? I mean, we’re doing our best to make it that way, but I’m wondering if you think we can do it.

Marc: There’s a lot of suspicion right now in the open source community. In the aftermath of the Novell-Microsoft pact, it appears that nobody quite understands what Microsoft is up to and what their game plan is. Certainly the community is extremely skeptical about anything that Novell or Microsoft does at this point based on past experiences, for example with the Samba and Mono communities.

That said, while a blog, focused on open source and sponsored by Microsoft would be treated with skepticism by certain segments of the open source community, there would also be people interested in reading it. Everybody wants to understand Microsoft’s angle on Linux.

Richard: I figured that. I figured there’s going to be healthy skepticism.

Sean: When you speak, Marc, about what the angle is, are you asking what Microsoft’s angle is with Novell?

Marc: Yeah, and the way you look at it will depend on who you are. If you’re a large company like AMD that values both their Microsoft and Novell relationships, we’d be looking at that blog for opportunities where our customers can benefit from the marriage of the two.

One of the key things about the Novell and Microsoft pact was Steve Ballmer getting up on a box and saying that this is to protect Novell’s customers from being sued for use of Microsoft patented IP. That has a lot of people very frightened.

For example, people will be looking in those blogs for what the caution areas are. What products might I get burned on if a court decides Microsoft’s claims on software IP are legally defendable?

Richard: That’s interesting. So, with that in mind, I have a few basic open source questions that I hope you’re willing to address and give us your opinion. One is, what are the challenges an open source company faces when competing with closed source companies?

Marc: Very often the open source companies are trying to profit from something that’s not the source code itself.

Take a look at someone like Canonical. All of their software development efforts have been to get Ubuntu into the hands of as many users as possible. They make Ubuntu Linux available at no charge, under open source licensing mechanisms. Their profit model is currently based on support services. For someone like Canonical it’s a question of does the open source community develop products where the user might be willing to pay something for a service like support?

Richard: So, it seems to me that the biggest asset a software company has is the source code. What traditionally has been called trade secrets, intellectual property, or secret sauce.

Marc: In the closed source case, yes.

Richard: It’s an interesting idea to make money by giving your main product away.

Marc: The GPL completely allows for an open source program to be sold for profit. But it also allows multiple copies of that to be made and redistributed without royalties. So, it’s a real interesting area. Since it has been difficult to turn a profit from just selling a GPL application, traditionally most companies that back open source projects use the software itself as an enabler for whatever service or subscription that they plan to sell. In some cases these companies also sell a closed source product that compliments the open source projects.

Richard: So, what do you think are the most compelling advantages to open source over closed source? What is open source able to do much better than closed source can do, in your opinion?

Marc: Open source allows for freedom of innovation in the absence of a driving business case in a lot of cases. Take the Debian community, which has emphatically refused to adopt the same way of doing AMD64 architecture support the way that other Linux distributions have. To give you the ten-second synopsis, other Linux distributions support running 32-bit and 64-bit code in the same environment. Debian felt the way the directory structure was handled in other AMD64-supporting distributions was the wrong approach, and they felt they needed to adopt a structure that would prepare Debian Linux for future innovations. So they elected to support an approach that was different from what other Linux distributions were taking and refused the quick fix implemented for business reasons. I use this example to illustrate that, in the open source community, everybody has the freedom to innovate according to their own interest and ethics, business justification or not.  I respect the Debian community for holding to their values. In the closed source space it’s a much more restricted audience; the freedom to do what a particular developer feels is the right thing just isn’t there. People are still confined by ethics, but those can be overridden by corporate objectives and customer requirements.

For example, products sometimes are shipped before they’re truly ready just to stay on schedule. Debian is famous, if not notorious, for delaying a release until the software is really ready and no known critical bugs exist. If a bug is missed prior to release, open source methods allow opportunities for the community to fix the bug after the fact.

In open source software, anyone can disagree with a corporate direction and then redistribute their own version which has things written the way that they think it ought to be. This promotes a freedom to innovate that goes beyond what you can often find in the closed source model.

Richard: How does open source keep from having endless slightly different distros?  Is it Darwinian? The things that really work and get picked up live on, and those that don’t just sort of peter out?

Marc: The biggest strength and the biggest weakness of open source is the freedom of choice. Michael Dell has been quoted in the press prior to the May 1st announcement that they were going to start shipping Ubuntu. Each time he’s quoted about responding to when are you going to start shipping Linux, when are you going start supporting the community, he says, "I’m fine with supporting the community. Which one? Which one do I pick?"

Every Linux distribution has a different philosophy. Look at Red Hat; they have had a very long history of preserving backward compatibility and ensuring stability of the products such that when their enterprise customer upgrades, they’re not going to have to recompile their kernel and reinstall a bunch of apps.

Look at the SUSE case; they try to take a much more balanced approach to include innovation in cases where it might be a minor inconvenience, but they believe that the customer will appreciate the value that they get out of the product for that minor inconvenience.

Now look at Debian; I once suggested that Debian try to encourage enterprise ISVs like Oracle to integrate their software with Debian Linux as a way to expand their visibility and market share. A Debian developer responded, "Who cares about market share? What we care about is open source." Everyone on that discussion list thread agreed there’s no reason to make Debian more compatible with Oracle databases because Oracle isn’t open source. Debian’s mission is an open source revolution across all software segments.

So each Linux distribution, besides having a different code base, has a different philosophy behind it. And that creates a lot of choices for the user and that’s a big strength, but that choice complicates the decision too. There are two main product lines in the Windows release – a desktop/workstation line, and a server line of products, and one can even argue that those two product lines are more similar than dissimilar as they leverage many of the same operating system components. There are 359 open source operating system distributions according to Distrowatch, most of which are Linux.

Richard: It seems to me in doing research on this subject, I run into an awful lot of open source advocates who seem to be open source advocates more because of the anti-capitalism sort of flavor to it, at least in some corners of open source.

That seems to be a common voice, although it doesn’t seem to be a common motivation of all of the open source projects I’ve looked at. It looks like there’s an awful lot of people writing open source trying to figure out a way to make money on it. They believe in open source for maybe collaborative reasons, maybe for development cost reasons or whatever, but they want to make a profit.

But this anti-capitalist message seems to be sort of pervasive in one from or another through almost everything I’ve read. Do you think that that hurts the open source community in the eyes of people who are agnostic in terms of development paradigm? Do you think some people are turned off to open source because they see it as sort of anti-business, and they aren’t?

Marc: The attitudes of the open source community have changed over the years. If you look at the Linux community of the late ’90s, you’ll find that’s very much the case, to the point when we launched x86-64.org I asked that all of the corporate logos be removed from the website. Since then we’ve brought them back because the open source developers realized that without a corporate motivation and corporate sponsors that there’s a lot that they’re prevented from doing. Many open source applications are hosted and mirrored on either boxes in a corporation’s data center or using corporate sponsorship money. Linux Symposium wouldn’t happen without corporate sponsorship. Linux-supporting companies look after the interests of the open source communities in standards bodies and industry forums that developers don’t usually have access to.

Also, a lot of corporate sponsors pay developers to do what they would do anyway. And those developers have become grateful to those corporations in a way that has lessened the anti-capitalism trend.

Sean: Let me ask you a follow-up to that, and I know exactly why Richard called it an anti-capitalism bent, but do you see that as the most appropriate phrasing for it? I mean that’s kind of the quick draw phrase that everybody uses, but is it anti-capitalism or is it anti something else?

Marc: I’d say it started off as anti-capitalism because the feeling was that most corporations A) produced strictly closed source software and B) didn’t understand the open source model well enough to be any good to what people like Richard Stallman were trying to promote. So, it was an anti-capitalism setup.

But as I say, modern-day, most of these well known developers are sponsored by a business. So, a lot of that trend has died down.

Sean: So what do you think it’s kind of evolved into? Is there still kind of an anti- bent to the whole community? I mean is it kind of anti-control, or anti-throttling of innovation, or what would you stick there?

Marc: The Linux community is a lot more pragmatic about software IP than they were 15 years ago but long term, open source enthusiasts still are driving toward elimination of software as a proprietary product. It’s a freedom of knowledge movement, and much in the same way that you can go to Wikipedia and read about any topic that someone has contributed knowledge to. In the software case, that freedom of information is creating software instead of encyclopedia articles, and the content creates a new market. You can still make money off software creations, without making money from the software itself. Perhaps that’s services for the software, perhaps it’s a subscription to access premium content.

Open source enthusiasts feel that they are resisting controls over innovation and strive to obtain freedom to innovate in a way that’s beneficial to the customer, regardless of business case. It’s not anti-business but does challenge many existing business models.

Richard: In other soft product areas, like music, publishing, and stuff like that, you have a war between the copyright holders and those who think that stuff should be free. Do you think that closed source companies have a right to protect their source, or do you think somehow they’re subverting the greater good?

Marc: My opinion is that they have every right to do with their products whatever they need to do. If the software author also supports an open source movement, that’s a great thing but the open source model is not for everyone. In Eric Raymond’s "Cathedral and the Bazaar," there’s a whole section about reasons to open source, and that if your product does not meet all those criteria, then maybe you are better off keeping it closed. Often a solution stack is incomplete without certain pieces of software that happen to be proprietary.

For example, people buy a solution stack that includes Oracle and SAP because they derive value from the closed source applications, not because it’s built on top of an open source infrastructure. The open source operating systems (such as Linux) offer great features too, but today, most OS licensing and services revenue is driven by the application workload inherent in the solution stack the OS was bundled with, not necessarily the OS or benefits of open source.

Richard: So, you don’t think open source is in opposition to closed source, but rather just a different paradigm?

Marc: Yes.

Richard: OK. That’s cool; that’s interesting to know. I was trying to run down project-development leads on OpenOffice.org, and I think a little bit over half of them are employed by Sun. I’m curious, speaking non-altruistically, what does a company gain by sponsoring open source?

Marc: Besides the points I’ve already covered, they gain favoritism as an open-source-friendly company, that developers will even develop for their closed products because they believe they are contributing to the greater-good effort.

Richard: So, it’s sort of developer PR at some level? I’m sure not all of it, but there’s some, "We’re good guys, look, we’re sponsoring."

Marc: From a business perspective, that’s right – that’s what many of them see. The ability to leverage innovations from the community is also attractive, but the contributions aren’t guaranteed in the same way that the developer PR is.

Richard: That’s interesting.

Sean: For about seven years I’ve been involved in deep, technical efforts around evangelism, and I’ve certainly seen closed source companies realize and economic gain from sponsoring and supporting a community.

For a company that’s got a mainly closed source model, and they embrace open source model on the side, do you have any kind of anecdotes or examples of places where the company looked back and saw gain?

Marc: Probably the closest thing that I can think of is Adobe’s decision to allow projects like OpenOffice.org to include PDF generating tools, and their decision to make PDF a completely open specification that they encourage other people to put into their products. This has benefited Adobe’s PDF software products, even though Adobe’s products are closed. So, by creating an open standard, they’ve enlarged the market for themselves, and by supporting open source efforts, they’ve gotten a lot of mileage in the market that they sell into.

Richard: Last week Adobe open-sourced Flex, which was a free product. What, do you suppose, they gain by open sourcing it? Do they gain lower development costs, because they’re going to get free collaboration?

Marc: Well, I’m not very familiar with Flex, but suppose that they did the same thing with Acrobat Reader, which is another free product that they give away. They have already developed the market to the point that PDF is ubiquitous. If you want to make a document that is guaranteed to be readable on just about any platform out there, whether it’s x86, Apple, or a smart phone, you generate it in PDF.

If they decided to make an open source Acrobat Reader, that allows a lot of projects to tap into it and borrow code from it; it promotes the whole integration story of plugins and addons that go beyond the original plugin interface for the application. By giving their developer community the freedom to innovate, the development direction would be managed by the community.

You asked about lower development costs. The cost only goes down measurably when the community contributes something that the “copyleft” holder was going to pay for. Open source software lets a lot more innovators in the door to help with software development, but sometimes additional resources have to be found to do the work that no one contributes for free. The point that the open source community is trying to make is that open source innovators are shared among many open source projects. It would be expensive to recruit each of those developers under contract, and even more expensive to maintain that software over a long period of time.

Indeed, many projects have benefited from the open source model. Open source is not a guarantee of success any more than having great technology. There has to be demand for it, and from the right audience or no one will show up to do the work.

Richard: I see. A couple weeks ago, I ran into the CSI company that was started by Stuart Cohen. It’s sort of open source. The paradigm is that CSI hires developers, and managers as part of a geographically centered development teams. Companies who want a particular piece of software pay for CSI to manage that effort.

The idea is you might have half a dozen companies who want to have some software package. They pay CSI to develop it, and they also may make some of the developers on their staff available to the management of CSI to contribute to that project.

However, the thing that interested me the most is that was that once the software package is developed, it may not be re-licensed as open source. Rather, it’s going to be the decision of the contributing companies how to re-license, or even whether to re-license it. The presumption, I guess, is that they’ll go ahead and let it be available through some sort of open source model, where it can be modified and redistributed without cost, but they don’t have to.

It looks like a blending of open source and closed source. You’ve got this shared cost and collaboration of open source, but you don’t necessarily have the other main underpinning of open source, which is that the source code is available to everybody.

Do you think that that’s where we’re going, into different sorts of paradigms that blend proprietary and open source methodologies, and do you think that’s good or bad?

Marc: Though they would prefer everything to be open source, open source developers are beginning to accept that there are certain things that are difficult for a company to expose without getting them into potential legal trouble. They don’t like it, but they’re understanding. Overall, I think it’s a good thing.

Richard: So, it sounds like open source is drifting away from highly idealistic to more pragmatic; still holding onto their ideals, but being more pragmatic about attainability in certain situations.

Marc: There are some exceptions, but for the bulk of the open source community, yes, they’re becoming a lot more pragmatic about things. They still prefer to hold onto certain ideals, and continue to direct everything in that direction, but most developers are fairly pragmatic about it.

Richard: So, I had a couple of interviews with some guys at Microsoft focused on ensuring security for Microsoft products: Michael Howard and James Whittaker. Both of them, separately, said that the biggest advantage that closed source has, in almost every area—architecture, implementation, quality assurance, and documentation—is the ability to mandate a process. Microsoft has the ability to say, "This is part of the job, and you have to do it," whether it’s unit testing, adhering to coding standards, security reviews, or whatever. The implication was that would be hard to put together with open source because all you have is the code, you aren’t certain of the steps the developer went through to produce that code.

Is there good adherence to process in open source projects? Is it something that’s improving? Can you comment on that area, in general?

Marc: The open source community has code control procedures and models of their own. For example, in the LinuxBIOS/OpenBIOS project, you can submit a patch to the mailing list only once you’ve gotten one of the key maintainers to review and approve the code. So, there are still very much the rules for developing that code and processes to be followed. Some of these methods probably emerged from source code control models originally used in closed source settings, but in the spirit of open source, why change or reinvent what’s already working well?

The rules for submission seem to vary a lot for each project. You can have quite a range of different quality control mechanisms. But, usually, there is a quality control mechanism there.

Richard: Yes, there has to be. You can’t release software unless you have some kind of quality control. It seems like you have to have some sort of gatekeeper over the code base, or it’s going to deteriorate in a hurry.

Marc: Without someone moderating the process, you end up with wars of someone changing a bit of code, and another person changing it back. Endless back and forth. Code control also guides the direction of development so that community goals can be met.

Richard: Yes. So, what to you see on the horizon? What do you think is in the near future, generally, in open source?

Marc: A lot more of, as you put it, the blending areas particularly as Linux becomes more widely used in different server and desktop environments. For example, in multi media areas we’re seeing a lot of companies that create set top boxes that use a combination of closed source and open source software in embedded devices. It’s an area where businesses are realizing there’s money to be made with the combination of open source software and closed source IP.

Virtualization is a big area of expansion. A lot of companies want to make money off of virtualization, sometimes for security, and sometimes it’s to increase the range of compatibility across operating system environments. There are both closed and open source options, such as KVM, VMWare, and Xen. Each innovates using different philosophies. So, this is an area that I’m watching with interest.

Device drivers are also an area of much attention. The Linux kernel community has been very emphatic that they will not accept any closed source code into the Linux kernel. And yet the way that you develop drivers for Linux is to include it in the kernel.  For example, the FCC has given 802.11 wireless networking devices a certain range of frequencies that may be used. Many of those devices are essentially programmable radios. The hardware vendors don’t want to open source that because that allows someone to then misuse the product and gain access to frequencies that the FCC wouldn’t approve of. Sometimes in order to reveal specifications, licensed IP used in the hardware design has to be revealed.

The drivers I’ve just described can never be part of the Linux kernel, and yet Linux users want to be able to use all these devices. In recent months, just really January of this year, certain key people in the Linux community are starting to realize that this prevents a lot of hardware companies from participating in the way that they would like to, and that though hardware vendors have nothing against open source models, for one reason or another they simply cannot release their code. I’ve been watching a number of efforts to make it easier for hardware developers to produce Linux drivers. I hope this topic is discussed during the next USENIX Kernel Summit and that the maintainers find a way to prevent Linux from being stifled further on the basis of compatibility problems with new technologies.

Richard: Do you see Linux making inroads into the desktop market? Do you think that they can gain a significant part of that?

Marc: Client computing models are changing from traditional desktop and laptops, and with these changes there are new opportunities for Linux. Different types of desktop applications or use models also offer an opportunity for Linux.

I think in time we will see Linux emerge in the same way – having strengths in certain types of client devices. I don’t know what that strength is going to be yet for Linux but many people in the community are exploring what it should be. Today, most ISVs only want to deal with one desktop operating system, and that’s Windows.

Today there are a number of ways, including virtualization, that you can run Windows apps in a Linux environment. As that improves, I think we’ll see a lot of ISVs soften to that idea. And, as they look at some of the things that we’re developing for Linux, they may decide that it’s better to develop a Linux app that will also run under Windows than it is the other way around.

As the Novell-Microsoft Interoperability Lab continues to grow their efforts I can definitely envision Microsoft having to run Linux apps inside their environments much the same way that we have those today in Linux.

Richard: It seems to me that products like OpenOffice.org and other open source products that are becoming strong, mature applications in the traditional desktop applications space have to work to mitigate Microsoft’s grip on that market. In the past, when Windows first started to take over the desktop, it was because that’s where all the applications were. You could put Linux or something else on there, OS2 or whatever, but all the mature applications were Microsoft applications, and they had to run on Windows. And I think that’s sort of how they got that grip on the desktop market. It seems like the first step toward making that a more competitive market is through the applications phase.

Marc: Yeah, I agree with that.

Scott: It looks like the TCO battle has been fought to a stalemate.  Microsoft has Microsoft sponsored reports saying they have lower TCO.  On the Linux side, there are reports sponsored by Linux supporters saying that Linux has lower TCO.  Do the communities find any of these reports credible?  Have you come across any truly independent TCO reports that you’ve thought were especially good?  Is it even reasonable to expect that the finding of some TCO report will be borne out in the specifics of your organization?

Marc: In the independent studies I’ve read, per machine, the costs are pretty much the same for a supported machine if you compare Windows to a truly equivalent Linux implementation, but this fails to take into account the workload processing power costs. In the open source model, I have visibility into what code is slowing down my e.g. mail server, exclude the things I don’t need to have running, and make the machine more efficient. Without that optimization, more machines would be required for the same workload regardless of the operating system in use, which adds to the cost.

Richard: Marc.  Thanks for taking the time to chat with us.

Marc: Thank you.

Bookmark this: