How to pay for open source

We often think of open source as "free software." That's a good association. Many people follow the tradition, dating from the '80s, of referring to software that offers users the liberty to deploy, study, modify, and distribute its source code as "free software."

But that's "free" as in liberty, not "free" as in beer. Like it or not, the idea of getting something for nothing still drives many customers to open source solutions -- and can deceive them into into thinking it's wrong to pay people for open source software.

[ The Bossies are back, bigger and badder than ever! Check out the top open source products of 2012, as selected by InfoWorld. | Track the latest trends in open source with InfoWorld's Technology: Open Source newsletter. ]

On the other hand, many who understand the beneficial effect of the open source movement wonder how they can, in fact, directly contribute money to an open source project. It sounds like an easy question, but the issue is more complex than you might think.

The disruption of dollars

While open source projects are created by members of their community, that does not mean the development is funded through that community. Open source projects are collaborations among motivated individuals. Communities actually fund development in only a tiny percentage of projects. When a not-for-profit supports a community, it typically does so by employing administrative, legal, and financial staff, with a view to supporting the technical and market operations of the community and freeing community members to focus on the project itself.

An open source community involves many parties coming together around a source code commons and synchronizing the overlapping parts of their interests. As they do so, they each pay their own way from their own resources. Centralized funding upsets the balance, disrupts the community, and alienates participants who don't get a piece if it.

Some communities have suffered heated disputes caused by even a perception that development would be centrally funded. That's because it's a proven disincentive to community vitality. This is not to say that work done by open source community members is unpaid. Research shows that many projects are deeply dependent on community members who are paid to work on the code. But they aren't paid by the community; they're paid by activities that benefit from the code. Open source is not a charity even if it’s administered by one, and it doesn’t need "monetizing."

Seed money

But what do you do if you're trying to bootstrap a community in a new market with no established development businesses? The Shared Learning Collaborative -- an initiative funded by the Gates Foundation, Carnegie, and the State Superintendents trade association to build software to enable schools to satisfy new federal reporting requirements on academic achievement -- is trying to do just that.

Having defined a set of APIs and data formats for gathering performance metrics from schools, SLC has built a dashboard application and has signed up nine states to pilot its system in two phases. Getting the data into the system is the next challenge.

Rather than write software for that too, SLC has opted to hold "code camps" to explain its system to developers, then to offer a bounty for developers who will create the two applications it needs. Two awards of $75,000 will be made to teams of developers whose plans for the two applications are judged best by SLC. Payments will be staged so that the winning teams receive both up-front cash and payment at milestones.

I spoke with Danese Cooper, an experienced open source strategist retained by SLC. Cooper has a long track record in open source management, not least as my predecessor at Sun Microsystems, and is currently on the board of the Drupal Association. She explained that the goal of the bounty program is to create both a software commons for SLC and a community of developers who can maintain it. SLC's seed money will create open source software -- licensed under the liberal open source terms of the Apache License -- which states can then deploy to meet their new federal responsibilities.

The developers involved in creating it can expect to be in high demand by those states to customize the software for local requirements and to maintain that code in deployment. By adopting a collaborative approach around an open source code commons, states will be able to meet their statutory responsibilities at the lowest cost possible, yet software developers will still get paid. Indeed, as SLC's software matures, it's very likely that the market and demand for skills around the software will grow rapidly -- 45 states have now signed up to the Common Core Standards Initiative that SLC implements.

While it's easy to view the participants in the SLC's Code Camps as volunteers, there is every chance they comprise the early population of a new market for development skills, contractors, and deployment management that's being seeded. I asked Cooper how InfoWorld readers could get involved in this fast-moving new software market. She told me the best route is to read SLC's developer site and attend the free Boston Code Camp on Sept. 29 and 30. Then get your team -- or company -- to enter an application proposal for the Bounty Program by Oct. 2, 2012.

It's not often you get an invitation to bootstrap a new market, especially one without a corporate master to whom to pay your dues.

This article, "How to pay for open source," was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.