How Funding Free Software Can Fail
Jim Gettys made a great post today on the SugarLabs mailing list about the problems with funding community projects:
I’ve seen projects *die* from having centrally funded development staff conflated with project management and governance. This was the X consortium model (though it made other mistakes too). The scars are on my back, and I’m personally partially responsible for that mistake. And also as a result of that mistake, I’ve had a hobby of observing (and participating in) governance of large free software projects over the last 8-10 years (e.g. Gnome, X.org).
Several things can happen when governance and development are conflated: companies/organizations think to themselves: “I paid good money to the consortium”, and tell them to do it rather than staffing up to get things done themselves. Net result: no community, and endless arguments over what work the central staff should do; often over pet projects the funding organization can’t afford anyway, looking at that pot of money as a way to get what they think they want.
- companies/organizations think to themselves: “Other people are paid to do it, I won’t help”, (either by people or money).
- it becomes against the economic interest of the funding companies/organizations for the software to continue to evolve. So they oppose change.
- the funding organizations, having put good money in to fund people, now believe they have good reason to “vote” and control what happens. This fundamentally dis-empowers the community. And then, you get to start over building community and an organization from scratch. While successful forks are possible, boy, are they hard (again, first hand experience).
- “us” v.s. “them”. We see lots of that right now with OLPC; as our efforts have had to shift toward issues arising out of deployment, it has had the effect of dividing the community who develop the code and those who have to deal with the day-in-day out support issues. Lots of frustration on both sides. But more pernicious is control vested in a single organization of funded people; their ideas become much more likely to “ship” than other contributors, dis empowering both individual volunteers and organizations. Great people drift off into other projects, and you die slowly. Did you know Guido Van Rossem was once an X hacker?
In general, I’m much more comfortable with resources in the organization responsible for Sugar going toward community building. If you look at Gnome, or new X.org, most of the (relatively nominal) money they get from sponsors toward meetings and conferences, toward enabling travel of volunteers to those meetings, hardware for central facilities such as servers. They also act as dispute resolution forums, (though in well run projects, those are pretty rare events). The bulk of the work is done on by people with direct stakes in their outcomes, whether commercial or volunteer, and all are peers.
Having said this: sometimes it has made sense for open source organizations to fund work no one wants to do (e.g. test suites, or hiring copy editors to improve documentation, or…), though Cairo has shown even (some or all) those can be done by well disciplined projects.
So I’m very happy if Walter can get money to help push Sugar forward: but I think it is a grave mistake if we have governance of Sugar in *either* Sugarlabs (*if* it becomes a development organization by hiring developers) or OLPC’s hands. Sugar as a free software project has to become its own thing as an independently governed entity. And this will solve many conflict of interest and trust issues inhibiting growth of the community, and allow us all to work together even if funding sources are from highly competitive sources. You put the two together (governance and major funding), and it spells t-r-o-u-b-l-e.
…
Thanks for the pointer to Mako’s article. I wasn’t aware of it. I just have scars to prove it :-(….
Here’s another failure mode:
- organization has a revenue stream to work on a particular project; said organization then decides to go in a different direction (from where the money was intended to be spent). Problem… Example: Motif; TOG was supposed to take the Motif royalty stream and spend it on maintenance and enhancement of that project; instead, the money went, (as far we can tell) to fund other projects the organization thought more important..
Software projects should have a life of their own, independent of funding source.
The How Funding Free Software Can Fail by David Crossland, except the quotations and unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.
Comments
Leave a Reply