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.
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.
IV of the Concerted Disruption, Climb Aboard series.
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?
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.
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.
a community manager, it sounds like you have a huge range of roles.
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.
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
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.
you responsible for bringing that to light with the companies that, say, CollabNet
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.
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.
you're also a go-between, you're not just managing the project for the community
but also back and forth with Sun.
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?
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.
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.
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
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.
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?
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.
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.
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.
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
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.
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.
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?
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.
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?
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.
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.
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?
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
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
where I was going with that.
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.
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?
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.
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
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?
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?
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.
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?
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?
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
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.
created a marketing project for OpenOffice.org. We were the first project with
a marketing group in all of open source I think.
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.
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.
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.
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.
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.