The role of a .org

15 March 2007

codehaus community jbossorg opensource

We've got a bundle of opensource communities all over the place now. Some of them are the opensource arm of an otherwise capitalistic commercial entity:

Others are non-profit, or not tightly tied to a corporation:

    None of these should be confused with .nets, such as SourceForge.net or java.net. The .nets of the world are more like warehouses than communities. Both types of .orgs do share a lot in common, but they also have some functional differences. Working with both the Codehaus (just a community) and JBoss.ORG (a .org sibling of a related .com) is interesting.

    Non-commercial .orgs

    The non-commercial communities serve both the community members and the actual project developers. The role towards the community is fairly passive, mostly providing the capabilities for participation, contribution and interaction. For the developers, primarily normal "forge" tooling is needed. Here, different communities might select different tools, but ultimately the feature-set is roughly the same. Ultimately, taken all together, we're only talking about Subversion, mailing lists or forums, IRC/Jabber, bug tracking, continuous integration, wiki, webspace, and maybe blogs. That sort of thing. Of course managing a bag of disparate tools in a useful manner is no trivial task. org_principles_noncommercial.png While non-commercial .orgs also may encourage interaction and cross-pollination between projects, it is not necessarily their primary mandate. At the Codehaus, I do attempt to introduce various project leads I think might have a chance at some cooperation, but beyond that, nothing is explicit. The Codehaus is the land of containers, for instance, which might never have any reason to cooperate or share community members. Apache, on the other hand, does try harder for inter-project cooperation. Projects are encouraged to use other Apache projects where possible and contribute to things such as the various "commons" projects. OpenQA, through its focus on a particular type of project, also promotes natural cross-pollination amongst the members of each project. QA folks can be... intense.

    Commercial .orgs

    Commercial .orgs likewise have to address both the community members and the project developers. The project developers still demand good forge tooling, of course. But the .org starts to play a larger role in regards to the membership of the community. Instead of simply facilitating interactions, the .org must also act as an advocate for all users, including those from which the corporation derives no revenue. org_principles_commercial.png With a commercial .org, there are natural inclinations to attempt to directly monetize as much of the community as possible. It's not at all a malicious goal, since ultimately, the company should try to monetize the community. That's the whole point. We need to learn that direct monetization is counter-productive, though. Attempts at direct monetization may include putting some content behind locked doors, running banner advertising everywhere for the corporate offerings, or being closed to complementary or competing ideas and individuals. If everywhere a member looks, they see marketing and sales of the host company trying to grab their attention, it stifles the sense of openness. The revolution will not be sponsored by a single company. In a real community, a truly thriving community, there will be other actors out there in the field. Your projects are hopefully so successful that other people see ways to build their own businesses around them. These folks can be seen as either threats or opportunities. Using the .org only as an extension of your own marketing department would ignore these folks, turning them into threats. Projects within a commercially-backed .org tend to have more product management behind them, explicitly providing a multiple-point solution across the entire platform of projects. The .org's role likewise must ensure that the shared communities between projects are helped to find their own commonalities. Additionally, in the wild world of opensource, a lot of projects just simply fail to develop a community. A commercially-backed project has already shown to have a community, and the company has a vested interest in ensuring that it continues to grow. The .org plays the role of the park ranger, tending to and actively promoting the healthy land wildlife of the project. In the "real world", lightening strikes a dry pine, and 3 million acres of project go up in smoke. A company can't afford to have that happen. Pardon the bad analogy.