Organizational, Institutional and Financial Aspects of the OpenSimulator Project
A recent thread about financial contributions to the OpenSimulator project touched on issues that we don’t talk about that often in the opensim-dev mailing list: organizational, institutional and financial aspects of the project. These aspects are all different, but they usually go hand-in-hand. I thought I’d share my thoughts on this, and get some input from the community. As usual, goes without saying, these are my personal thoughts, and not any official statement from the core devs (hopefully this will become clear if you understand this post, and we can stop adding this disclaimer in every email/post).
The OpenSimulator project is fueled by a small group of developers who produce the the vast majority of the code and who have commit access to the socially-accepted-as-main GIT repository. I say “fueled” rather than “led” for obvious reasons: there has been only a vague sense of leadership, but nothing that deserves that name, at least not the traditional form of leadership that we’re used to; a visit to the main portal for this project, the Wiki, illustrates this point: that’s the closest to a Bazaar of information that one can get, complete with perls of dubious origin and products well beyond their validity date. I say “socially-accepted-as-main” rather than “main” or “official”, because that’s what it is: a social convention. Anyone can take the code and fork it, and this has been made even more appealing when we switched to GIT, which has much more powerful merging facilities, so it becomes technically a lot simpler to maintain extensions or alternatives to what’s in the socially-accepted-as-main repository. Yet most people in the community look at the code produced by the core developers as the official code.
Like so many other open source projects, the OpenSimulator project does not have any formal setup. This doesn’t mean that the project is an anarchy, though. Internally, the group of developers follows a few simple rules of engagement for deciding on all important aspects of the project, such as new developers, significant patches, etc. The issues are first discussed, then voted upon. Technical discussions happen publicly in the -dev mailing list, so that everyone can participate; discussions about new developers happen in the -core mailing list. The outcome of all voting is positive as long as there are no objections — much more stringent than a majority scheme, it requires a fair amount of consensus. The core developers listen to the community, but the only votes that count are those of the core developers. These rules of engagement are similar to those followed in many other open source projects. These are localized, case-by-case decisions that, overall, define the direction of the project.
Periodically, the group of core devs has internal existential moments of the kind “should we create a formal organization?” a-la Apache Foundation, for example. Invariably, the answer always converged to “no”, at least so far. The reasons behind this “no” boil down to no one seeing enough benefit to compensate for the hassle. The last time we talked about this, the idea almost took off; but it quietly landed again for lack of interest/time for actually executing it. The idea of a foundation is still up in the air; maybe next time we have an existential moment it will happen.
If a foundation were to happen, it would NOT be for taking in and managing donations for code development — for reasons that will be evident below. Otherwise, the foundation would effectively be a small company, which would completely defeat the mission of the project. For anyone interested in this, take a look at the finances of the Apache Foundation. The money raised there is to pay for servers, organize meetings and cover legal expenses… which come as a consequence of a having created a formal organization in the first place…
About the finances, and to put this in perspective: according to Ohloh, the OpenSimulator project has cost $5.5M to get to where it is now; that’s with an avg. salary of $55K/year… (ah!), and this estimate doesn’t count anything other than code in the socially-accepted-as-main repository. It doesn’t count testing time or all the projects in forge and elsewhere. Even with those hugely simplifying approximations, that’s a burn rate of $1.6M/year.
Where does this money come from? Like in all independent open source projects I know, it comes from the following sources:
a) Voluntary time contributions from passionate people who have stable day jobs and enjoy developing OpenSimulator in their free time, for free. The reasons why people do that are well known and fall out of the scope of this post.
b) Generous contributions from companies and organizations who have some of their employees contribute to OpenSimulator as part of their day jobs. Current and past examples are: IBM, Intel, the University of California, Reaction Grid, 3Di, and others.
c) Contributions from individuals and organizations who contract with individual developers, usually to produce something very specific.
Note, again, that this is a burn rate of $1.6M/year (with Ohloh’s ridiculously low estimates)… Does anyone here believe that this kind of money can be raised from voluntary donations every year, so that the project could afford ‘hiring’ N permanent developers (if that were a goal, which it isn’t)? Obviously, not.
Basing developers’ compensation on direct donations is an unsustainable strategy for a large open source project of this kind. It’s great to hear from people who are willing to donate $1,000 to the project, we appreciate the gesture, but, really… the numbers just don’t add up, and such practice would create a lot of unwanted tension that would force the project into becoming more like a small company, which is something none of us wants. So we have to say no. That money is better spent on other things, like paying artists to create freely distributable content that enriches everyone’s virtual worlds — a really important detail for that first-time experience.
An hypothetical Foundation would not engage in that kind of activity; it would also not interfere with the existing rules of engagement, which work well. So the pertinent question is this: if not for raising money for development, what would this possible foundation be for? I don’t have a good answer to that question. In some perspective, a foundation looks like a self-generating hassle — having to deal with taxes and lawyers is not something any of us enjoys, and the money raised would mainly be to deal with those. Maybe that possible foundation could hold copyrights for those developers who don’t want to hold them, and take on the consequent legal liability. Again, more lawyers.
One benefit I see in it is that, psychologically, this possible foundation would give a warm fuzzy feeling to the community at large, more or less like a legal marriage.The fact that a small group of us would come together to confront a premeditated hassle would be a bonding experience for this small group of people, and it would send the message that we are serious about our relationship with each other and the community at large. Personally, I don’t believe in the benefits of legal marriage [for me], so I have a hard time convincing myself that such formality is really needed in this project too. We have bonded by having serious disagreements from time to time, and being able to overcome them and still be producing awesomeness.
Another, more convincing benefit, would be the possibility of involving non-coders in this foundation in ways that the project, as is, isn’t prepared to take. For example, we could take in contributors of good documentation as members of this foundation. Having a formal relation with a formal organization might be a good incentive for some people to do that task really well — as opposed to being yet another voice on the cacophony of Wiki. Similarly to documenters, we might take in people for additional roles such as testers and community leaders in specific topics. The foundation would be a means to get ourselves more organized, just like legal marriage sometimes is a means to take on more responsibility.
So, the jury’s out on this. It’s not obvious that a foundation-anchored OpenSimulator project would be any better than what we have now. I’d be interested in hearing your thoughts on this.
But independent on that possible foundation, I hope this sheds some light on some of these important issues that are rarely discussed in the dev ML, but that show up implicitly in many posts. The fact that the OpenSimulator project isn’t a formal organization but a collection of individual developers (even if they are in the payroll of others) with their own motivations that must be relentlessly protected and respected; that it doesn’t accept monetary donations; where the roadmap is the collection of interests of the individual developers; that constantly reminds the community to take on their own initiatives; that sucks at doing PR; … in other words, the refusal to take on a traditional community leadership position … none of this happens by accident; it’s something that has been carefully considered from time to time among the core devs, and which we have agreed upon. It’s what works for us. So far. Like many marriages, we may end up needing to create a formal unit because of external pressures.