Gated Communities

by Tim O'Reilly
June 2000

In a recent slashdot posting, interstar asks: "This report in Upside Today suggests that big software companies are attracted by the "gated community" model - unsurprisingly as it seems to be classic "help us debug our software and we'll keep the copyright, thanks". Upside (in my opinion, naively) presumes that because this idea is attractive to software companies, who will invest in it, it's obviously going to take off. But is this likely? Who works for gated community projects, and why? If it's just for the "bounty" isn't this just programmers working as contractors? Surely for there to be any special open source goodness, these projects must attract collaboration over and above that which is payed for. But are they? And why should I contribute to a gated community rather than a true open source one?" Such a model seems awfully one-sided to me. Sure the software companies like it, but what do the developers get out of it?

The majority of the slashdot response was surprisingly supportive of the concept, especially considering the slant of the question that opened the thread. However, it was clear from the responses that neither those in support nor those being critical really understood the concept of a "gated open source community." The term was mentioned by Collab.net CEO Bill Portelli in a discussion with Upside columnist Sam Williams, but neither really elaborated on where the idea came from or how it might be applied.

Since I was the one who started spreading the "gated community" meme (though I didn't originate it), I thought I should take a little time to explain it more fully.

The best way to do so is with a concrete example. O'Reilly uses a fairly obscure software package for publishers, called CISpub, to control our order entry, shipping, warehousing, and accounting. There are at most a few hundred other users of this package, which is written in Pick Basic. Each customer has access to source code, and many of us have made extensive modifications to the underlying package to make it better fit our business. For example, we added support for EDI (Electronic Data Interchange) with our third-party warehouse, with book wholesaler Ingram, and with retailers like Amazon, Barnes & Noble, and Amazon. What we don't have is the right to redistribute those enhancements, or any mechanism for doing so.

This is a perfect situation for a "gated open source community." Sure, it might be nice if the vendor were to give away the source code to anyone who wanted it. It could even be the case that by doing so, the vendor could acquire some additional customers from people who downloaded the software for free. But frankly, I think it's fairly unlikely. It's also unlikely that there would be contributions from anyone other than the current user base. This is a specialized package written in a specialized language for a specialized industry segment.

What we would love is to be able to share our modifications with the community of other CISpub users. We'd probably be willing to grant rights back to the vendor as well, but what we primarily would love to be able to do is to leverage the work of other people doing similar mods, or even to collaboratively agree on a modification that several customers might subsidize jointly. Why should each of us write our own EDI extensions?

What's missing is a framework for sharing. And that's why the work that Collab.net is doing is so important. Yes, they support pure open source projects--and many of their biggest projects, like HP's e-speak or Sun's NetBeans, are in fact open source. But more importantly, they provide a way for open source ethics and methodologies to penetrate the world of specialized business software.

Because the CISpub vendor doesn't think of its customers as a community, or provide ways for us to connect, each of us labors in isolation. interstar said: "Surely for there to be any special open source goodness, these projects must attract collaboration over and above that which is payed [paid] for." My response: not at all. What's important is that those who pay for the software development don't need to reinvent the wheel in private.

In short, if a "gated open source community" means that I can share my changes only with other existing licensees of the base package, but not with any outsiders, I'm all for it.

Incidentally, you could argue that the GPL (though not BSD-style licenses) creates a kind of gated community, in that only those agreeing to the license can (in theory) redistribute the source code. Because of the terms of the license, this is an evangelical gated community, always trying to bring in new members, but it's still closed to those who don't want to abide by the license agreement.

Obviously, though, if your objectives are to spread a software package as widely as possible, to users whom you don't know and who will use and develop it in ways you don't expect, the idea of a gated community doesn't make any sense. For viral spread of software to new markets and the greatest spur to unexpected innovation, use a BSD-style license or the GPL. "You pick the hat to fit the head."

On the other hand, there are many thousands of vendors who could make use of the gated community concept who aren't ready to go the full open source route. The idea of making their source code available to the world doesn't make any sense to them. All they can see is the possibility of lost revenue as people who might have been customers download it for free. (And if the marketplace is small, this loss of customers is in fact likely to offset the chance of acquiring new customers by freeing the code.) But give them the idea that they can enhance customer satisfaction by setting up mechanisms for sharing among their user community, and they're all for it.

To make this work, you need to use licensing terms allowing redistribution of modifications to other licensees, public repositories for contributed code, discussion forums so users can find each other, and other mechanisms familiar to open source developers. It also helps if you have a modular architecture that makes it easier for people to add-on without changing more than they need to.

A brief historical aside: The term "gated open source community" was first brought up by an IBM employee (perhaps Dan Frye?) during the briefing session I did with IBM on open source in January 1999. I had been talking about the idea that open source was a development methodology, not a political philosophy. Someone asked, speculatively, "might this mean that you could create an open-source-like gated community among a group of paid software licensees?"

I agreed that this might indeed be possible. After all, this is a good description of what happened in the early UNIX development phase. You had to have a source license from Bell Labs in order to have access to UNIX source. While the license was loosely enforced, especially to programmers in university settings, a license was still in fact required.

Jay Casler of IBM chimed in that this was also true of much of the early IBM mainframe software development. In fact, he pointed out that one of IBM's major software families (perhaps CICS?) had originally been developed by a customer, and then contributed to IBM so it could be used by other customers.

This is a very appealing scenario for vendors and customers alike.