|
|
Subscribe / Log in / New account

LinuxCon: funding development

By Nathan Willis
September 6, 2012

At LinuxCon 2012, Bradley Kuhn, executive director of the Software Freedom Conservancy (SFC), presented a session on funding free software development. SFC's primary mission is to provide organizational and legal support to free software projects, but it has also been successful at raising funds to support development time — a task that many projects find difficult.

Ancient history

Kuhn started the discussion with an account of his introduction to free software, which began when he accidentally hit a key sequence in Emacs that brought up the text of Richard Stallman's GNU Manifesto. Reading the Manifesto was inspirational, said Kuhn, who has subsequently pursued a career in free software — even serving as director of the Free Software Foundation (FSF).

But on this occasion, he told the story not just as an introduction, but also to point out an oft-overlooked section of the document. Toward the end of the Manifesto, Stallman discusses several possible alternatives to the proprietary software funding model. Stallman argues that (contrary to the common objection that "no one will code for free") free software will always have developers, they will just earn smaller salaries than they would writing proprietary software. He cites examples of people who take jobs writing software in not-for-profit situations like MIT's Artificial Intelligence Lab, and says that free software is no different. Developers do tend to move to higher-paying jobs when they can work on the same projects, he said, but there are many who write free software out of commitment to the ideals.

Stallman suggests several alternative funding models under which developers could make money working on free software. One is a "Software Tax" in which software users each pay a small amount into a general National Science Foundation (NSF)-like fund that makes grants to developers. Another is that hardware manufacturers will underwrite porting efforts; a third is that user groups will form and collect money through dues, then pay developers with it.

Few people remember it, Kuhn said, but in the early days FSF itself functioned much like one of the user groups Stallman describes in the Manifesto. It accepted donations and directly paid developers to work on GNU software. A long list of core projects, including GNU Make, glibc, and GDB, were originally written by paid FSF employees. It was only later, as these original developers took jobs working on free software at companies like Red Hat and Google, that FSF turned its primary attention to advocacy issues.

The non-profits

Today, Kuhn said, the majority of free software is written by for-profit companies. Although that situation is a boon for free software, the resulting code bases tend to drift in the direction of the company's needs. He then quoted Samba's Jeremy Allison (a Google employee) as saying "It's the duty of all Free Software developers to steal as much time as they can from their employers for software freedom." Since not everyone is in a position to "be a Jeremy", Kuhn said, some developers need to be funded by non-profit organizations in order to mitigate the risks of for-profit control.

But proliferation of free software non-profits can be detrimental: it confuses users, and each organization has administrative overhead (boards, officers, and legal filings) that can steal time from development. There are several "umbrella" non-profits that attempt to offload the administrative overhead from the developers, including the Apache Software Foundation (ASF), Software in the Public Interest (SPI), and the SFC.

In addition to the administrative and legal functions of these organizations, each has some mechanism for funding or underwriting software development for its members. Donations to the ASF go into a general fund, from which individual member projects can apply for disbursement for specific work. SFC and SPI use a different model, in which each member project has separate earmarked funds.

Most of SFC's disbursement goes toward funding developer travel to conferences and workshops, Kuhn said. It also handles financial arrangements for conference organizing, Google Summer of Code, and other contracts, but the most interesting thing it does is manage paid contracts for software developers. Typically these contracts are fixed-length affairs that raised targeted funds for the contract through donation drives — as opposed to, for example, earmarking funds that accumulate through an ongoing donation button on the project's web site.

Fundraising successes

Kuhn recounted several recent success stories from different SFC member projects. The first was the Twisted engine for Python. Back in 2008, the project was confronted with a familiar scenario: it was successful enough that many core developers got high-paying jobs working on Twisted consulting, which in turn led to bit-rot of core functionality. The project decided to hold a fundraising drive, and collected enough donations to pay founder Jean-Paul Calderone to work for two years on bug-squashing, integration, and maintenance of the core — work that was vital to the project, but not exciting enough to attract a full-time position from the typical corporate Twisted user.

In 2010, SFC did a similar fundraising drive to pay Matt Mackall to maintain the Mercurial source code management system. Mackall said he was able to support himself full-time on Linux kernel-space development, but that it was hard to repeatedly "context switch" to Python userspace and work on Mercurial. The SFC fundraising drive funded Mackall full time from April 2010 through June 2012.

The PyPy Python interpreter project launched three successful fundraising initiatives in one year to support specific development projects. The initiatives for PyPy's Py3k implementation of Python 3 and its port of the Numpy scientific computing package each raised $42,000 in drives held a month apart in late 2011. The project has also raised more than $21,000 and counting this year to fund development of software transactional memory support. Kuhn related that he had been concerned at one point that the frequency of the fundraising drives would wear out the potential donor pool, but the project forged ahead, and SFC is now funding four PyPy developers.

Fundraising challenges

A member of the audience asked what SFC thought about using Kickstarter for fundraising, to which Kuhn replied "who is going to Kickstarter for Python stuff who isn't also reading your blog?" PyPy's recent success, he explained, probably owes more to the fact that PyPy is a hot commodity in Python circles right now. It has little trouble finding donors as a result, but by raising the funds through drives hosted at its own site, it avoids having to pay Kickstarter or another broker a potentially hefty cut of the donations.

The tough part, he continued, is what to do when you are no longer on top of the popularity bubble. Free software has a big "I gave at the office" problem, he said. Many of free software's most passionate users (and thus potential donors) already spend their own time working on free software. Consequently, they react to fundraising efforts with questions like "I code all day long, now you want me to give money, too?"

Kuhn did not offer any simple solutions to the ongoing fundraising issue, but clearly there are none. Like Yorba, SFC is interested in exploring the possibility of funding free software projects, which makes Kuhn's report on SFC's successes an interesting counterpart to Yorba director Adam Dingle's examination of other funding methods.

It is clear that SFC's success stories differ from generic Kickstarter or bounty-style drives in a few key respects. First, they are tied to funding work by well-known contributors with good standing in the projects — often key maintainers. Second, they are tied to a development contract of specific length. But they still differ in other important details: although the PyPy initiatives were also tied to a specific feature set, the Twisted and Mercurial drives were done to fund the harder-to-price tasks of bug fixing and routine maintenance. Free software development is not a homogeneous process, so there is certainly no one-size-fits-all answer to the fundraising question. But it is reassuring to know that organizations like SFC (with its commitment to software freedom) can still find success where money is involved.


Index entries for this article
ConferenceLinuxCon North America/2012


to post comments

LinuxCon: funding development

Posted Sep 6, 2012 19:22 UTC (Thu) by noxxi (subscriber, #4994) [Link] (1 responses)

you should probably not post the full content of a $ article into the RSS feed :)

LinuxCon: funding development

Posted Sep 7, 2012 7:57 UTC (Fri) by ersi (guest, #64521) [Link]

Might be a mistake - might not be.

Sometimes, happenings like this might get people to consider subscribing up - finding out how nice it is to get full, well-written articles timely.

(Which indeed is, very freckin' nice!)

LinuxCon: funding development

Posted Sep 7, 2012 0:24 UTC (Fri) by bkuhn (subscriber, #58642) [Link] (7 responses)

Thanks for the article about my talk. I'd like to note that all these fundraising campaigns are ongoing and work is ongoing, and we'd love for people to donate to support them!

Mercurial donations are welcome to support Matt Mackall's work; PyPy's Py3K, Numpy and Transactional Memory campaigns are still going, and a Twisted donation form is on their left sidebar.

Of course, each of Conservancy's member projects accepts earmarked donations, and you can also donate to Conservancy's general fund, which goes directly to support salaries of our staff to keep Conservancy running.

More information about Conservancy is available on our website, including a full list of member projects and a list of what benefits they get and how new projects can apply.

LinuxCon: funding development

Posted Sep 7, 2012 4:02 UTC (Fri) by akumria (guest, #7773) [Link] (6 responses)

Is the conservancy able to run itself entirely on Free Software?

If not, e.g. accounting systems, is any money ear-marked that might progress things so that it can?

LinuxCon: funding development

Posted Sep 7, 2012 15:21 UTC (Fri) by njwhite (guest, #51848) [Link] (5 responses)

Unsuprisingly, given it's Bradley, it's marvellously free software-y. Information about the code running the website, including links to the source, is at http://sfconservancy.org/about/license/

I'm pretty sure they also use ledger (or possibly some variant of it) for all accounting. I remember Bradley chatting a while ago about features he wanted or needed. He will probably fill you in more on how they do stuff.

Conservancy runs only Free Software for its own operations

Posted Sep 7, 2012 17:44 UTC (Fri) by bkuhn (subscriber, #58642) [Link] (4 responses)

akumria, Yes, for internal operations, Conservancy uses only Free Software. We don't impose this rule on our projects per se (although we urge them to). We wont' accept a project that develops proprietary software, but if they use proprietary software in said development, we bug them about it and try to get them to change, but we don't mandate that. After all, Samba developers have to test against Microsoft's stuff to make sure their code works.

But, that's admittedly a special case. A better example is that many of our projects use Eventbrite for registration to their conferences hosted by Conservancy, and many use Github to host their projects. Both platforms are proprietary network services (including installing proprietary Javascript onto your machine when you use them). I make our projects aware of this issue, but if they want to use these services, Conservancy doesn't forbid it. We recently had a project (the discussion is public) that's considering using a proprietary CI system as well, which we urged them not to but ultimately won't stop them if they do.

Meanwhile, for internal operations, Conservancy is 100% Free Software shop. njwhite is correct that Ledger has been a big part of that since around 2007 (when we switch to it from GNUCash). Conservancy is actually doing some upstream work with Ledger now (as of this week) to initially add some reporting scripts to contrib/. Long-term, we want to have a web interface that will allow a bookkeeper without Unix CLI and Emacs experience to keep the books. (I currently keep the books of Conservancy myself; in part because of that issue and in part because we don't have funding to hire a bookkeeper anyway. I'm working to solve the latter (please donate :), but the former will still be a problem even if we get the funding.

Conservancy runs only Free Software for its own operations

Posted Sep 10, 2012 21:33 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (3 responses)

> Long-term, we want to have a web interface that will allow a bookkeeper without Unix CLI and Emacs experience to keep the books.

Have you tried hledger-web? A demo is available[1]. I uses ledger's data format (but doesn't support everything), but it might[2] be easier than starting from scratch.

[1]http://demo.hledger.org/register
[2]Depends on Haskell/Yesod familiarity.

Conservancy runs only Free Software for its own operations

Posted Sep 11, 2012 13:55 UTC (Tue) by bkuhn (subscriber, #58642) [Link] (2 responses)

hledgerweb really supports only a small fraction of what ledger can do, and the most important thing is an extra-ledger issue: it needs to use a repository system on the backend for it to be useful at all to Conservancy.

Conservancy runs only Free Software for its own operations

Posted Sep 11, 2012 18:40 UTC (Tue) by clint (subscriber, #7076) [Link] (1 responses)

There is a somewhat-low-priority project to add an optional filestore backend to hledger-lib (which would introduce support for Git, Darcs, and Mercurial). Presumably when ledger 4 is rewritten in Haskell, it could do the same thing.

Conservancy runs only Free Software for its own operations

Posted Sep 16, 2012 15:53 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

I'd certainly be interested in a git-backed hledger. I store my files as:

main.journal # Include $year.journal
$year.journal # Set the year, include $year/$month.journal
$year/$month.journal # Sorted by effective date then by account

in git. Having hledger do auto-commit when things balance would be great since the commits tend to just have messages like "Receipts up to $date" and "Reconcile with $account up to $date" anyway.


Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds