Introduction

Louis Surez-Potts is the Chair and Secretary of the OpenOffice.org Community Council. He plays a community manager role for the OpenOffice.org project, communicating important issues between Sun Microsystems, CollabNet, and the OpenOffice.org community. Louis's insight on keeping the different entities collaborating well, within a large-scale open source project, extend from the political and social architecture to the technical, and beyond to the intricacies of marketing.

OpenOffice.org is perhaps the most popular open source, office productivity suite. It runs on a number of different operating systems, and supports a high number of local language translation requirements. It includes a word processor, spreadsheet, presentation application, [database,] etc. and is compatible with similar applications such as Microsoft's office suite. The project is sponsored by Sun Microsystems and hosted by CollabNet.

Part IV of the Concerted Disruption, Climb Aboard series.

I'd like to know about your experience in what's been successful toward encouraging a community around an open-source application. What are some of the things you do to participate with the other developers?

My role at OpenOffice.org has been fairly in flux since the beginning and I joined it at the very start of the OpenOffice.org project, which was in October 2000. I started off being a content manager my role changed from doing so-called content to basically managing, doing a lot of project management as well as strategy, as well as trying to rearchitect the site so it could actually accommodate all the new users.

One of the things that Sun [seemingly] never envisioned when it was creating OpenOffice.org, was that it was going to be quite so successful. [I think they must have] envisioned that everyone who wanted OpenOffice.org would flock to StarOffice and buy it, thereby making Sun rich because StarOffice, they thought, was so much better than OpenOffice.org. In fact, people were perfectly happy with the free application. More interestingly, perhaps, OpenOffice.org was immensely popular outside the US. We saw this and sought to develop that interest by focusing more on non-US markets and encouraging the development of projects catering to users speaking different languages than English. Guy Capra, of France, helped to initiate the category, and then I worked with him to develop the category—focusing on other languages of the world or as many as were actually localized and were able to be supported. We now have a total of forty-five or so and these are enormously popular and actually what most of our new users and contributors are coming to.

As a community manager, it sounds like you have a huge range of roles.

It is and the closest—I mean there's no one role that I do. One way of looking at it is you need somebody who can make unpleasant decisions, and I'm usually that person. The decision might be like, let's say "no" to this project because we already have someone working on that. Or, equally, there needs to be someone to represent community interests, to the sponsoring company, and vice versa. Or, most generally to coordinate the multiple interests that comprise the overall community. But this role is not like that of a so-called "benevolent dictator," as we see with Linus [Torvalds] or others. I do not decide on purely technical issues. My focus is the community as a whole and the project in toto. And that is an interesting focus because OpenOffice.org has changed the way in which open source software is developed, and CollabNet is providing the leadership for that change.

The change may be temporary, a phase, or permanent. But it has to do with the fact that OpenOffice.org is sponsored by an enterprise and is working on code that enterprise uses for commercial purposes. A brief history: Whereas early open source was organically developed via organizations like Perl, where you had several people get together and say "this seems really cool let's work on it and let's form a project around it": A community was formed by the developers most involved and was or remains coeval with the code itself. With OpenOffice.org and some other Sun-CollabNet collaborations, however, we have a new kind of open-source community, one in which the sponsoring company forms the participating community after the fact. Of course, in the case of OpenOffice.org, there are still many of the Star Division engineers, and they form a part of the OpenOffice.org community [Sun bought Star Division, which made StarOffice, in 1999—Ed.]. But the non-Sun community began to be formed only after the creation of the OpenOffice.org project and only really got moving after the release of code, in October 2000. And this raises the question: How does one go about forming such a community? How does one ensure it actually works? That things get done? That it doesn't grow chaotically? This is where I come in, and more generally CollabNet—and why I think that we, OpenOffice.org and CollabNet, have changed the logic of open source development, by, in effect, professionalizing the process, all without, I believe, sacrificing the productive energy of organic open-source projects.

Now you and I were discussing, before the interview began, the idea that open source actually has historical antecedents, philosophical as well as social. With this evolution, the history of open source becomes a little bit more interesting, because there isn't a clear antecedent where companies have said, "let's make it publicly available, let's make a commons," and have it work out for all. So, history, as it were, is being written here.

Are you responsible for bringing that to light with the companies that, say, CollabNet works with?

You mean this evolution in open source development? I'll answer with what I do vis--vis Sun and the community. With OpenOffice.org, Sun is the sponsor, and I'm responsible, at least in that I'm a conduit between the community and Sun, although not the only conduit. We also have a community council that effectively represents the community to itself and others and also articulates a set of policies that are meant to ensure that community needs are accommodated. In part, this structure is necessary because OpenOffice.org includes so many non-developers—contributors, to be sure, but not necessarily coders: they could be support, or illustrators, or documentation writers.

My role here, as mentioned, is thus to try to synthesize the totality of the project's interests and present them to the stakeholders—Sun, for sure, but others, too.

So you're also a go-between, you're not just managing the project for the community but also back and forth with Sun.

Yes, but not only with Sun; there are other stakeholders involved in making OpenOffice.org. But let's take Sun as the prevailing instance. If Sun wants a new process, say a license change or a major architectural change, or relationship change I can try representing that to the community, though of course, I will only represent those things I agree with: I'm not Sun's lackey nor shill. As well, if the community has expressed a strong desire for something, or is having problems with a process, and the Community Council is not the best venue, I'll represent those points to Sun, provided that Sun is the relevant party, of course.

Can you tell me some of the things that you think work well to generate developer interest and to get them to participate in the community?

've been thinking a lot about that, we always do. Go to any open source project and that's the first thing that people in my role start discussing: how to bring in more developers. Anyway, I was trying to think how one would clarify the process. The usual representation of open source is that it has these four primary freedoms and those are certainly true, but I think there's one crucial one left out that was assumed by Raymond and Perens, when they were creating these definitions, and that is that key decisions have to be made, must be made publicly and transparently, in order for there to be a really effective open source environment.

If you look at OpenOffice.org, the places where we have the most activity, the most work being done by people outside of the corporate community are in areas that are a little bit marginal, where the more or less independent groups have the most say in how the product is going to be shaped. These are localization, porting, and other areas like that. At the same time I should emphasize that those are the areas that are the easiest for the independent groups and individuals to handle. The fact that OpenOffice.org code is difficult to build and fairly monolithic is a known impediment that I believe we ought to work on fixing.

So there are two points, but I'll deal with the second one in a moment. The problem with the core areas is that the community has relatively less say in how the code is going to turn out, mainly because Sun more or less by default if not by intention does the majority of the coding there and thus implicitly determines the direction of the code. Naturally, it has its own interests in mind—it wants StarOffice to go in one direction, and as StarOffice is based on OpenOffice.org code, that affects OpenOffice.org. Now, the community is certainly welcome to come along and Sun tries to include the community in those discussions, and in the end, most people are pretty much in agreement with the proposed roadmaps. (Right now, we are trying to improve the planning process, so as to bring in more community input.) Our other major corporate contributors like Novell, Red Hat, Debian, they generally agree with this process and seek only to polish whatever derivative they are seeking to distribute.

But this current process actually makes it more difficult for developers who are coming from outside a corporate environment to participate because it isn't simply a question of having an "itch" that needs scratching—patching, that is, code, or extending it, or whatever—as wanting to be effective and have your code accepted. In the past, the situation was a little worse, and developer contributions to areas outside of those covered by the roadmap seemed to disappear into a black hole. And nobody wants to contribute if their contributions are not paid attention to, or not relevant, or if they feel they have no real access to the core process, if they don't even have an insight into how decisions regarding not just their code but the overall project's (writ large and small) are made.

You mentioned this problem of a "black hole" regarding developers' work. There is also this notion that when the relevance of what developers want to contribute doesn't get the proper appreciation they won't feel encouraged to further contribute. What can you do to prevent that?

I think there has been a misunderstanding. We appreciate developer contributions and want more of them, and we also want to improve the process to encourage that. And the black hole problem was really something that affected development in the years preceding. We've improved the process. Still, however, the basic structural problems remain—OpenOffice.org is difficult to build, difficult to learn, and is not particularly modular; and contributions, especially substantial ones, need careful scrutiny—our QA standards are very high. But more importantly, the roadmap, the elements of the code we privilege, are still largely determined by the sponsoring company for its own purposes, and this means that code that diverges from that roadmap is not as privileged. That's not to deprecate the "outside" code, a lot of it is very good and is accepted, it's just to underscore the fact that most core development is done to satisfy StarOffice needs.

What we've done to ameliorate this—what we're doing—is to strive to give developers coming from outside the project more of the tools, information, and support they need to get going. Thus, when developers come to OpenOffice.org, they are immediately welcomed and their contributions are immediately dealt with/handled and recognized I'm focusing here exclusively on coding developers, not on general contributors for documentation or support or something like that, for whom a similar but slightly different process exists. But to rephrase: all contributor contributions to OpenOffice.org are recognized. It just depends on if we have people available to recognize it. And, recognition does not necessarily mean that the code or contribution will be accepted. No open-source project works on that principle! Nor should it.

But to return to the problem I sketched above, where you have a sponsoring company that determines, if only by being the one to do much of the work, the roadmap or architecture and features of the code, then it becomes difficult to get developers engaged if they don't have any say in the planning. It's not quite a Catch-22, because we can change the process so as to better listen to other voices. So what we're always trying to find out is a balance so that developers do have say, so that they are engaged, and so the project is able to go forward with its roadmap. Of course, no one's ever particularly happy with any compromise achieved, which only means we have to improve things further. But you asked a larger question: What processes do we go through or how do we envision developers getting engaged in the project and as a general statement, I would say that the most effective way is to actually make the process the coding, the process of decision making, more transparent, and that is what I hope to help accomplish in the coming year.

Not only focusing on OpenOffice.org or any other project per se, but in general if you want a really successful project what you need to do is make key decisions transparent so developers are able to participate in them publicly. That's probably number one, then one would add, for general open source projects, all the other definitions of open source, making the source available, so on and so forth. As well, having technology that people are familiar with and having an environment that sustains their efforts, one that doesn't crash and is reliable, one that is providing tools that allow lots of easy collaboration, those are fairly essential requirements. But having the political apparatus, by which I mean the transparency, this is extremely important, otherwise a developer will just get dissatisfied or frustrated.

Now most people are not really aware of this and think they have to have sexy or exciting code out there to get a developer. But I think that is actually less important. For example when we first started OpenOffice.org people thought it was incredibly boring, an office suite is simply not as exciting as a Web browser, like Mozilla—that's always been our model. But, as it turns out, our early thinking was wrong, and we've had enormous popularity among contributors and end users throughout the world, especially those in areas such as localization and porting, documentation, and support. We're getting more and more all the time. End users love the product.

The point is that you could have an accounting package, which, no offence to the accounting packages of today, are supposedly "boring," and it could probably be made exciting to most developers by representing it strongly and making of it a project that inspires development. And this raises the other point. The code itself is not the only thing that might draw people in, but rather how it is represented to the world, and how the project is structured. Marketing a project and product, especially to end users, is one thing—that's what we did with OpenOffice.org—but it is also equally important to structure it so that development is not just free but transparent. A project becomes exciting as others—the community—engage in it, and a community forms as the members lay claim to a commons whose breadth is clear. Shroud the processes in mystery, and one risks losing everything.

Now, in the case of OpenOffice.org, we positioned it as essentially the fulcrum upon which much of the software world will turn in going from a proprietary system to an open source system. OpenOffice.org is a requisite application for the open source desktop. But we could only do this because the code was so good and satisfied so many end users' needs.

When you say you positioned it that way, do you still mean in terms of positioning to developers?

To users and ultimately to developers. The thing to recognize is that the product is as successful, to a degree, as its users make it. The developers now working on OpenOffice.org still find it pretty hard to work on, because even though we are venturing projects, and even though we have lots of documentation, and even though we have lots of people who help someone new coming to the project, it's still a huge task. But it's also now an important task politically, culturally, and intellectually, because OpenOffice.org has been positioned to be that fulcrum.

The political apparatus that you mentioned as well the positioning, what is it that the software, namely the CollabNet system itself, can do to facilitate that?

OpenOffice.org was born using the early version of CollabNet Enterprise Edition. The infrastructure application has substantially evolved, and we've taken advantage of the changes, but the basic architecture of OpenOffice.org has not really changed in the last nearly five years. We tried to distinguish between the political and functional architecture of OpenOffice.org versus the CollabNet application architecture but there has usually been some combination or some intermixing.

But to answer more generally your question, yes, it's important to have an infrastructure that is integrated and that allows users and developers and other contributors to exist in the same universe and have access to the same commons. We have that with OpenOffice.org. With the way we've organized OpenOffice.org, whoever bothers to register—and it's trivial to register—can file an issue or bug report and do something. We give instructions on how to do this and our lists are pretty helpful. Second, the CollabNet application allows people who are more developed contributors, say working on documentation, to be using exactly the same tools as more advanced developers mainly interested in, say, coding; and those advanced developers who are interested in doing coding are using familiar tools, such as CVS, and a version of BugZilla.

What about your competitors? I'm switching topics a little bit here, but I don't know in the sense of OpenOffice.org that I've seen, and maybe I'm just not aware of these, but that I've seen different distributions in the same degree that you do with say, Linux. How would you deal with that as a community?

You mean have a variety of OpenOffice.org brands? Or flavors? I'd be delighted, provided that the core source retained identity. An interesting philosophical question actually, would be, is OpenOffice.org a product or a source project? Yes, we distribute binaries and we try to make a good job of distributing those binaries, but does that qualify as commodity? Meaning something that, in the classic sense of commodity, as something that has exchange and market value alone, or does it (and also other open source products) transcend the consumer conception of commodity? I prefer to think that we are more a source project distributing binaries rather than a company distributing a commodity which also distributes source. Mind, the binaries may be awfully good, and packaged in a way that makes them very consumer friendly—shrink-wrapped, say—but I would rather think of us as a source project first

The difference is that if there were, say a dozen upon a dozen people distributing derived versions of OpenOffice.org, I'd be totally happy about it because at some point if the architecture of OpenOffice.org is right and the licensing is good, then you would have those people contributing their innovations back to the source project. And that's the whole point of having an open source project. It not only provides value, it generates value. Now, how does Sun feel about this?

That's where I was going with that.

Well, I don't know. I am not an employee of Sun. However, Sun sells its derivative, StarOffice, and that is a derivative, it's shrink-wrapped. Sun, I would guess, looks upon all the other people selling derived versions, and I don't mean Novell with its NLD, or Red Hat's Fedora, or Linspire, or any of those others, but rather a lot of smaller companies selling proprietary (because we use SISSL, which is like BSD [Note: these are licenses—Sun Industry Standards Source License]) selling some derivative version of OpenOffice.org for a fair amount of money—there may be about ten of them off-hand, ranging from SOT Office, to Magyar Office, to things you've never heard of. Now it doesn't particularly like those, it doesn't particularly like the fact that IBM is using OpenOffice.org in its WorkPlace in some unclear fashion, and it would probably like to limit all that and certainly I would, too, for similar reasons. I would like for those profiting from OpenOffice.org to contribute back. To enjoin contributions, or even merely publications of patches, I think we have to change the licenses. I have found that using SISSL, although it does expand the market, doesn't encourage anyone to contribute back to the project; that's not its point.

The SISSL license should go. I think we should probably change the OpenOffice.org to the GPL, coupled with a commercial license, or even just the LGPL alone. The point, to restate it, is to encourage development of the source by enjoining contributions via the right license; and to also allow for the possibility of commercialization. But if you want to commercialize or make a profit on the work done by the community, then you should pay for that, not exploit the community.

From your perspective, obviously it's good to have these other communities, but you continue to have this support from ... well Sun is definitely the big company, but what happens if Sun decides it's not worthwhile? Certainly the project can continue as we've seen with other open source projects, but can things like positioning or the accessibility that you have to developers be maintained at the same level?

About once a month somebody comes up and says, "What happens if the sky falls?" Our normal reaction is it's manifestly in Sun's best interest to continue with OpenOffice.org as a vigorous open source project and it's deeply in their interest to think about ways to monetize, not so much contributions by the open source community, but rather derivations, add-ons, services: the ways in which it can add value to OpenOffice.org and sell that added value to customers.

For example, StarOffice right now adds a fair amount of polish to the OpenOffice.org code; I am sure they could do a fancier version of this, one even more suited to enterprises and governments. I should think the only real limiting factor is imagination and the will to think of OpenOffice.org as a beginning, not end product. They can certainly find ways to add value. So to take your points, if Sun were to go away or cease supporting the project, which would be deeply hypothetical, what then? Well, firstly, the risk would be to the project: Does the OpenOffice.org project fragment? Very likely it would suffer some serious attrition, as much of our core development is done by Sun, but would it find another home? Probably. But I think a more likely scenario is that it would prevail as an independent foundation, supported by a consortium of enterprises and governments. The foundation has an appeal simply because OpenOffice.org would not be dependent upon a single sponsoring company, it would be rather dependent upon a consortium and on anonymous contributions, and so on. I'm sure it has some appeal to Sun, too, which would not have to disproportionately bear the cost of development: others would also participate. The problem is intellectual property, that is, OpenOffice.org's. At present, Sun holds copyright and contributors sign a joint copyright assignment form that jointly assigns copyright to Sun, but for a foundation to work, it would have to hold it. For what it's worth, I'm actively raising the idea of a foundation at this year's OpenOffice.org Conference, OOoCon.

But getting back to your question, should Sun withdraw support, I doubt very much that the actual project as such would ever disappear or go away or lose its integrity. And that's partly because of size right now. We have over 200,000 registered members, but let's assume that 100,000 are bogus —duplications, mistakes, etc. That still leaves over 100,000 people. We have thousands of contributors in all sorts of different languages from all over the world. We have a lot of government interest, we have small and large corporate interest; corporations, people, and governments are interested for the reasons I've mentioned before, because OpenOffice.org is good software and is also open source. Free, as in gratis, too. What would you say to a person that decides to start a new project, say CRM, and wants to take the open source route in developing it?

What kind of advice do you give them to get it off the ground, to get it going, because it sounds to me like what you're saying is one of the saving graces for OpenOffice.org is its immense reach. That even if Sun is gone, there are so many people involved in it now that that massive community, is kind of the crux of it—how do you start from scratch?

I just actually gave a couple presentations on exactly this topic. Of course people are seriously curious about it. Keep in mind that Sun's OpenOffice.org is a sponsored project, so we started off far larger than an open source project is likely to become right off the bat. For someone who just started with a small thing, say CRM, as you're suggesting, the likely scenario is that they're starting with two or three others, at most, all have contributed to a clever application that they have licensed under an open source license, and they decide to start a project on SourceForge and hope that people will come to it and contribute. They may be perfectly happy probably if no one at all comes, and just delighted if somebody comes by, signs up on the lists, and contributes patches. The reason they may be perfectly happy if no one comes is that having a project with only two or three is actually a standard size for many open source projects. If you look at say NeoOffice/J, which is the Mac OS X derivative of OpenOffice.org that works perfectly well with the Apple system, that started as one independent developer who then started collaborating with several other OpenOffice.org for Mac OS X developers, and so the core team has grown, but it's now maybe three people, four people and doing great. As well, even the Mac OS X (X11) port of OpenOffice.org started with just two people working basically side-by-side in their spare time and communicating intensely via IM.

For many open source projects you don't need very many people but how do you get people if you do want them, and second, how do you advertise your product so that people can be aware of it?

Well hanging your shingle out on SourceForge has some problems. One, there are about tens of thousands of them so your own particular project can easily get bypassed. There's no distinction. Yes, it's free to do, and yes, that's great, and they do a whole bunch of apparatus for you, and that's great for small projects, but the sheer welter of numbers makes it difficult to distinguish your project from anyone else's. Second, and this is as much a marketing as managerial problem, what happens if you're doing something that somebody else is doing, only slightly different? You have a problem from the very beginning of people splitting their interests and having this inability to evaluate one technology over another technology. Third, how do you actually attract developers if you're somewhat different, and your technology is interesting but you don't have a clear message or something like that?

The answer would be to do some simple marketing. I do not mean to be glitzy or fake or deceptive. I mean to make the effort of broadcasting to others—and, if relevant, possible end users—what you are doing. But I also mean to utilize the existing news apparatuses. I mean: write press releases, give interviews, presentations, and so on. Try also to distinguish your presence so that you have a web space that has the tools you need but won't be lost in a morass of similar projects. You know, SourceForge is perfectly fine, it's just very difficult distinguishing your project from someone else's. But that doesn't mean that marketing can't be applied.

I'll give some concrete examples Plone is a pretty good example of good marketing and market positioning. They started off as basically a few people working in Norway and elsewhere. I mean one person is located in Arizona, I think, another person in Norway, a few people elsewhere. Their technology has slowly gained more and more developers, as it has gained more end users. eZ Publish does something similar as Plone, but at the moment—and think it will change shortly—Plone has a little bit more mindshare, probably because of a little bit more marketing. They went to the right conferences, they met the right people, they did all the things that basically you have to do if you want your project to get known. It's just classic marketing.

It's very interesting to hear you talking about marketing. I think you may be the only person I've spoken to so far that has really felt that marketing had a good place for an open source community.

We created a marketing project for OpenOffice.org. We were the first project with a marketing group in all of open source I think.

What you're saying makes sense but it's often frowned upon in the open source community. Yet it sounds like it was essential to developing your community.

It is, and you can rephrase marketing as growth or outreach. It doesn't really matter what you call it, it comes down to representing what you're doing to other people in a way that excites their interest. That's what it is.

The thing about developers is that they believe that they're only working with pure value, put it that way, not with prices but with value. Put another way, prices relate to market value, not use value. Marketing traditionally, in the popular mind, ignores value because it only wants to assign a price to something, and developers and coders only work with value, not with price; therefore, if you're working with value and not with price there's no need to have marketing because marketing would only seek to assign bogus price upon real value.

OpenOffice.org's Marketing Project, led by Jacqueline McNally and John McCreesh, has made a huge difference. And what we do in the marketing project is basically the essential things. We go to conferences, we write press releases, we do interviews, we make sure that things look good for users and developers, all so that we are able to represent ourselves to others in a way that excites their interest.

As far as some of the software issues go with CollabNet, you mentioned SourceForge a few times. The fact that SourceForge.net is so large and with such a range of developers on it, could be considered a strong point for starting a new project. You seem to feel that while that is good, projects can get lost there. I'm wondering can CollabNet be used, or the tools behind it, to come to the same sort of collaboration point that you get from SourceForge, without getting lost?

I think that any set of tools can be used in that way, I'm not sure that the tools themselves are the limiting factor, I think the basic environment is. But to clarify, my point was simply that because SourceForge is so vast, because if you start your new project there, there's no guarantee that anyone will come and work on your project. Whereas if we were to do it in CollabNet, we would make sure that from the very beginning that other developers would be aware of the point of this project, that it would be positioned correctly, and that it would have the apparatus, with the political and intellectual elements, to be successful. One of the problems with open source is that people fixate on the license and ignore management. But as OpenOffice.org has shown, the license is only part of the story, and at CollabNet, we'd try to make sure that the project benefits from developer interest, including those developers who have projects on SourceForge (why not?). We have fewer projects under our roof than say, SourceForge, but that's not our interest. Our interest is not to have the most projects per square kilometre; it's rather to have the most efficient and working projects. I think we've done that quite well.

Is there anything else you'd like to add?

I think just to reiterate that OpenOffice.org is open to all contributors and developers, as well as users. If you want to make a difference, you can.

This concludes Part Four of a four-part note. Part One provided background on what the open source community is and how to engage it. Part Two featured an interview with Jeff Bates of SourceForge.net, Slashdot, and the Open Source Technology Group. Part Three featured an interview with CollabNet's Karl Fogel, a founding developer of the Subversion project.