Sunday, August 9, 2009

Building the Open Source Hackers Cooperative

It is striking how much harder it is to make money from open source than to write it in the first place. Open source development is a sophisticated and well-understood social activity. However, the economic model is often laughably primitive: "if you build it, they will come." That applies to the question of turning your open source project into a real job. More interestingly, it applies to the question of how to make open source projects as valuable as possible to the largest number of people. In this post I would like to propose an answer to both questions.

To illustrate open source sophistication, just look how easy it has become to start and manage projects. It is almost a cookie-cutter procedure. You pick one of a number of well known licenses, manage the code on SourceForge.net or Launchpad, communicate with the project through skype and mailing lists, and tell the world about it using your blog plus Twitter. Within an afternoon you have set up infrastructure to support efficient collaborative development with team members from Seattle to Singapore. The number of projects itself makes the point: SourceForge.net alone has over 230,000 projects.

Things get much harder if you want to make a decent living from a successful project. It’s not that there is a lack of models to choose. You could form a commercial venture that offers closed source/licensed versions of your open source project. However, as many of us have seen with MySQL AB and other companies, commercial efforts have a tendency to conflict badly with broader community interests or those of other companies that might be useful partners. For this reason, they don’t even necessarily maximize the value of the original commercial effort.

You could of course try to create a foundation like Apache or Eclipse. However, these generally require established software and large commercial backers. The current experience of the fledging Open Database Alliance and other efforts shows that it can be quite complex to create such organizations from scratch even with well-established code and well-known players. This is not a model that can be repeated across a wide number of different projects large and small.

Finally, you could sell consulting and support for your project. The problem with the consulting model is that it is not scalable—in order to make a decent living you have to work on customer problems. The pro-bono work like extending the project or tending to a community tends to fall by the wayside unless you can get a customer to pay for it.

The fact that it is hard to make money off open source is a symptom of a larger problem: we are losing the wider social benefits that for many people are the real point of open source software. This is an economic problem: how do we allow hackers to make a reasonable living on open source projects while maximizing the long-term value of the software to the widest possible number of users? It turns out there’s a reasonable economic model that can do this: cooperatives, which are defined as follows in Wikipedia.

a legal entity owned and democratically controlled [equally] by its members

Cooperatives have existed for centuries in many different forms and have successfully solved problems ranging from providing student housing to delivering consumer goods like sporting equipment on a grand scale. We need a new form of cooperative that I propose to call the Open Source Hackers Cooperative, or Hackers Co-op for short. The Hackers Co-op has three different but co-equal types of members:
  • Hackers, who are the core committers to the project and stewards of the code
  • Sponsors, who supply funding and labor
  • Community members, who use the software, test it, and contribute patches
As we will see, some members are more equal than others, which is why I added brackets in the cooperative definition.

Here are the organizational principles for an Open Source Hackers Cooperative:
  1. The Co-op is a non-profit. It’s not for sale and there is no exit strategy. Like all co-ops, it exists to maximize benefits for its members.
  2. Hackers work directly for the Co-op. Their time is divided between implementing features that interest them, integrating patches as well as fixing bugs reported from the community, and implementing features for sponsors.
  3. Sponsors provide long-term funds and/or labor to the Co-op. Sponsors build businesses on the open source software and kick back a percentage of the business value in return for support and new features. They can also contribute labor for specific co-op tasks. Sponsors need not be for-profit businesses. They could in some cases even be governments or NGOs. The point is that they fund the software based on its value, for example through grants.
  4. Community members provide leverage to the development model. They use the software, provide basic support through forums, and contribute patches for bugs and small features. These activities leverage the hackers who can use community patches and feedback to evolve the software. This is a very efficient development model.
  5. The Co-op is a democracy. Co-op members vote on allocation of hacker resources. The vote is structured to keep a single group of members from hijacking the entire Co-op by dividing hacker time into a pie with allocations for the interests of each member type. Sponsors vote for their section of the pie using a vote weighted by their relative funding contributions--sponsors are not equal to encourage competition to commit more funds. Hackers effectively vote their portion by doing whatever they want with the time they get for personal projects. Community members vote through surveys or some other reasonable mechanism.
  6. The Co-op has elected officers. There is a chief economist who is in charge of the business model and plans finances, contracts with sponsors, arranges employment contracts, etc. There is also a chief technologist who ensures project infrastructure and moderates technical discussions. Co-op officers are elected or at least approved by the members at large.
  7. The Co-op pays dividends. Some open source projects are quite valuable, so a well-run co-op could easily become very profitable. The excess profits are distributed to hackers in the form of retirement and other benefits, to sponsors in the form of cash rebates, and to community members in the form of conferences, hiring of new hackers to work on features, improved infrastructure, etc.
You can try to run through a number of scenarios for the hacker co-operative to see how well the model holds together. All you really need is software with enough intrinsic value that it can sustain an active, technically aware community and where sponsors are motivated to build businesses on it but do not need to own the engineering. It is helpful to have community members be programmers, but you can also design the software to allow even non-technical users to contribute effectively.

Such conditions hold for a variety of system software like database management systems, app servers, and communications packages. With a little thought they could apply broadly to user applications like accounting systems or voting software, which so far are relatively rare in open source. The Co-op is model is quite stable, because it aligns interests in such a way that everyone does better if they stick together.
  1. Hackers earn a stable, comfortable living and public recognition for working on software that they enjoy. “Comfortable” in this context means salary and benefits equivalent to a typical EU country like Germany or Finland, which are the gold standard for employee compensation. This works economically because hackers are (a) very productive to begin with and (b) become more so by leveraging an active user community. Hackers are motivated to produce because the more viable the software is, the better the co-op does, and the more benefits they receive.
  2. Sponsors get features that they need using a productive open source hacking development model. This is a replacement for models like trying to take the software private and farming it out to low-cost offshore locations, which experience has shown to be badly broken on a number of levels. More important, sponsors get stability in the sense that the software cannot be taken over by hostile corporate interests and is supported over the long term, which lowers the risk of building businesses on it. They are motivated to contribute more in order to vote more resources for tasks that help their businesses.
  3. Community members get software that is continuously supported and evolving rapidly to add features they need. They get assurance that valuable patches will be integrated. They are motivated to use, test, and develop patches for the software as that further increases its value to them and leads to recognition as authorities on the project.
The Open Source Hackers Cooperative can be structured to create a number of virtuous feedback loops that will support and extend the software over a long period of time. The Hackers Co-op model could be standardized and even backed up with software as well as cookie-cutter legal documents so that it becomes very simple to set up and manage.

I don't know if there are projects already following this model. Selena Deckelman already used the term "Hacker's Cooperative" though from a somewhat different perspective. If you know of anyone who has worked through the cooperative economics fully I would appreciate hearing from you. Meanwhile, this is not a theoretical question for at least a couple of reasons.

First, I work for a for-profit company that is willing to sponsor projects in exactly the way described in this article. We are looking for (a) control, (b) stability, and (c) a development model that is cheaper than doing it ourselves. If such cooperatives existed we would be interested in them. I'm sure we are not alone, because this is how all for-profit businesses tend to think. The cooperative is a viable model because of the way it reinforces and maximizes member interests.

Second, the Hacker Co-op leads to some interesting questions about how to design software that promotes the leveraging effect of an open source community. It is possible to design even application software so the your users don't all have to be coders in order to contribute. If you want to create something really big out of your open source project (or just have a nice job) it helps to think these issues through before you write much code. Maybe it's the first thing on the list after you set up your new project.

20 comments:

Randal L. Schwartz said...

We have a number of examples of people making a decent living from Open Source software in our interviews at FLOSS Weekly (http://twit.tv/floss). Check them out.

Baron said...

You forgot to mention Google Code.

Robert Hodges said...

@Baron,
You mean as a hosting platform? I'm not sure how it solves the bigger problem of maximizing utility either for individuals or users as a whole, thought it looks a lot snappier than the competition. This seems to support the point I was making that OSS project management is really well developed but the economics are not. For instance, wouldn't it be cool if Google Code actually provided some of the extra fixings to run a hacker co-op? (like billing and employment contracts, for instance).

Robert Hodges said...

@Randal
Thanks for the tip. I'm listening to the interview on www.openstreetmap.org. It's excellent. I'm curious which patterns you find most interesting... My point is to try to optimize the economics, e.g., through feedback loops. That's still pretty wide-open.

Nice example incidentally of the leveraging effect of a community, not unlike Wikipedia.

Julien Danjou said...

In France, I work for Easter-eggs since 3 years.

It's a company based on a similar model you describe. We're all hackers (actually 12 hackers + 3 commercial) and work for customers on various free software to make money. On our spare time, we hack upon free software on our spare time. We are based on a democratic system where all co-workers have one voice to elect the CEO for the coming year, and vote for various needed stuff. We have all the same salary (even commercial) and we share benefits every year.

It exists since 11 years, and it works very very well. We're kind of expert on free software so we have high valued mission etc.

I doubt your model can work, because it's not clear and sure how money is make.
OTOH, on our side we have a real and good working plan to make money: make customers pay for what we are doing. It's not always hacking that we can contribute back to the community, unfortunately, but it often is.

I'd add that we have spare times too to work on things we like, since we are, as you say, very productive in our domain. So that compensate a little bit. ;-)

hingo said...

Hi Robert

Excellent post. The Open Database Alliance should be somewhat similar to what you envision here (and you should be able to review a draft of bylaws and other documents after a week or so). The main differences I can spot are:

The ODBA will sponsor (with money) Open Source projects, but not hire hackers directly. If the ODBA one day has enough money to pay someones salary, then this could certainly be discussed.

The ODBA will include many Open Source database projects, not just MariaDB. Hence it will not be authoritative to the roadmaps, features etc of those projects - as you said, these things usually already work quite well, so we won't try to "fix" that. But it will be a point of bringing the community together and pay exactly the kind of dividends you suggest. (And it could of course influence projects by having on opinion on how its own funds are allocated.)

Monty Program otoh is a little bit what you describe, except that legally we are an Inc and not a Coop - which is an interesting problem for a COO to try to solve :-)

henrik

Henrik

mbauwens said...

We keep track of some initiatives here, http://p2pfoundation.net/Free_Software_Cooperatives, and it would be nice to be able to produce a comprehensive directory of similar iniatives worldwide.

Here's what we have to date:

1. OSSICS, Kerala, India
2. OS Alliance, Austria, "Georg Pleger"
3. WikiOcean, Pune, India
4. SOLIS - Brazil, JĂșnior Mulinari
5. Gcoop - Argentina; pablo@gcoop.com.ar
6. Pong - Switzerland
7. Ikusnet - Spain
8. Easter Eggs - France


Inactive?:

1. KunLabori Collaborative, Sweden (no longer active, according to Josef Davies-Coates, May 2008)

See also:

1. Turo Technology LLP, UK
2. The Open Co-op, UK
3. HostSharing eG - a german coop specialising on ISP Services

More Information

1. Spanish-language discussion list, maintained by Gcoop in Argentina: Cooperativismo y el Software Libre
2. Cooperativas de Software Livre

Sheeri K. Cabral said...

I think this can work, but it probably would be best to start small, using bounties. Ma'atkit has taken bounties -- it's a set amount of money for a set of development.

So, picking a number that is easy to do the math with, if USD $52,000 per year is an appropriate salary, then something that is believed to be a week of work would have a bounty of USD $1,000.

If there's a lot of interest, both on the bounty provider side (giving the $$) and the bounty hunter side (coding and receiving the $$) then it can grow and scale, without having a problem where people are hired and have to be let go because there is no money.

There's already a not-for-profit out there, Technocation, Inc, that could be used for this purpose. I'm on the Board of Directors, and it's been pretty low-key for a few years, but they have all the appropriate not-for-profit documentation (not so easy to get!).

Robert Hodges said...

@Sheeri
It seems reasonable to start with bounties, but how do you get things on a more permanent footing, for example so that you can fund salaries long-term? Maatkit is now supported principally by Percona as far as I understand.

BTW, I have looked at the technocation site--is the non-profit documentation on-line?

Robert Hodges said...

@Henrik,
Thanks for the post. What I'm proposing here is somewhat like ODBA and Monty.org rolled into one. The difference is that the hacking business model Monty developed (http://askmonty.org/wiki/index.php/The_hacking_business_model) is an employee-owned co-op, whereas the hackers co-op in this article includes community and commercial interests as members. It's in some what analogous to co-ops like REI (recreation equipment, inc.) which is a huge co-op for sports equipment in the USA.

Robert Hodges said...

@julien
Welcome to the blog. Your site is excellent and the model delightfully clear. I take your point but would like to point out a key difference--Easter Eggs does work on any of a wide variety of projects, correct? The hackers co-op is designed for projects that solve a specific purpose, for example databases, operating systems, accounting system frameworks, etc. The corporate contributors in effect outsource development of infrastructure on which they depend but do not need or even want to own directly. The hackers co-op is another type of outsourcing model, not unlike outsourcing your human resources or check processing.

Robert Hodges said...

@mbauwens
Thanks, I started to look at some of the companies on the list, starting with Easter Eggs.

Greg Smith said...

I've always though the tough problem here is one you're not directly addressing: it's really hard to get open-source hackers to work on a boring project, and those are what many sponsors are going to want done. If you think about it, that's almost inevitable, because the fun/sexy projects are the ones people already work on for free. The stuff being ignored by development communities but that commercial interests need is much less glamorous work.

Because of that, the project management skills required to keep this sort of co-op on track so that sponsors get the value they expected from their contributions, is considerable. I think it's so hard to manage that how you structure the rest of organization has to start there.

Robert Hodges said...

@greg

Good point. There's a key feedback loop that's missing or at any rate a little tenuous. It seems you have the same problem with community patches--it's not the most exciting work to figure out how the patch should *really* have been done and get it properly integrated. However, applying needed fixes leads to outstanding software.

Jim Bethancourt said...

Hi Robert,
I have been thinking about the same idea recently, and I'm really glad I found your blog post. I think it is intriguing, especially given the unique economies of scale that can be accomplished with software development.

The three questions I have that would seem to need answers are:

1. How would someone who wants to start a cooperative find the initial Sponsors?

2. How would the Hackers decide what they would work on in the beginning to get the cooperative started?

3. What happens once the product(s) that are being worked on mature and don't really need any more development?

4. Do you help maintain existing open source products / libraries / frameworks, develop a new product that is the co-op's "baby", or both? If you're helping maintain an existing product / library / framework, I suppose you'd have to set yourself apart somehow...

5. Do you think the cooperative would be able to scale well past a local level?

Thanks so much,
Jim

Robert Hodges said...

@Jim
Thanks for posting! These are really good questions. The most important one seems to be "what kind of software does the hackers coop work best for?" If you understand that it also helps answer how to find sponsors. I'm going to do another post to follow up fully on these and other comments from the original article.

r said...

Google brought me to your post as I was searching something tangentially related.

It is interesting that you were pondering open source cooperatives at the same time I was trying to put mine together:
http://coopercate.org

I presented my ideas on this topic at the Utah Open Source Conference 2009:
http://www.youtube.com/watch?v=vNjSbvBgV70

I am now casually assisting another open source cooperative. It started about the same time but independently from my efforts. They have been more successful at getting traction than I was:
http://opencoopt.org

I highly recommend anyone interested in this initiative join the community at OpenCoopt.

I would love to continue the discussion. You can contact me at my home page:
http://richard.esplins.org

Robert Hodges said...

Hi Richard, thanks for the links. Opencoopt is really interesting--seems to get at exactly the social good issues I was wrestling with.

Anonymous said...

Communicate through skype? twitter? LOL

Jeff Krajewski said...

Any new news on this topic?

I am starting an open-source project that will be run by an online co-op. We are going to use the Liquid Feedback framework to cooperatively make decisions all online.

It seems most or all of the mentioned projects are offline co-ops (as in they meet in person for their decision making). Anyone heard of any other online co-ops?

Scaling Databases Using Commodity Hardware and Shared-Nothing Design