My Thoughts on FOSS Crowdfunding

2013-04-07 23:04:24 by jdixon

I was recently cold-emailed about a new service, Catincan, that offers a Kickstarter-like bounty system for open source software projects or features. Someone representing the company reached out to me (and presumably, many others in the open source community) for feedback, generally about the funding of open source development, and specifically about their own service.

This was the first I've heard of their product or company. Looking at their website, it's a straightforward crowdfunding service, applied to the domain of open source software. In their own words:

Catincan breaks down the wall between developers, users and funding to help open source project developers gain the funding necessary to continue making great software for users.

And even more telling, from their email:

Our goal is to help more open source projects become self-sustaining and competitive with propriety solutions.

For the sake of privacy, I won't share this person's name or the entirety of their email. But I find that quote particularly humiliating, in that it implies that a) FOSS software is somehow uncompetitive with their commercial counterparts, and b) that money will somehow solve this [imaginary] dilemma.

I think there was a time when project hosting costs would have justified this sort of service. Those days are long gone. Thanks to services like GitHub, TravisCI, and other FOSS-friendly companies that invest in open source (rather than leeching off of it), it's almost imaginable that a project couldn't exist, let alone thrive, without any expense to the founder or maintainers.

Here is my reply to their request for feedback. I hope that my opinions correspond with those of the greater free software / open source software communities, but I don't pretend to represent them.

Honestly, I think it's disturbing. It attempts to coerce FOSS development into a system of bounties. You're not attempting to "help open source projects become... competitive with [proprietary] solutions". You're aiming to make a quick buck off the backs of FOSS developers using the popularity of the Kickstarter model.

Good open source software doesn't exist because someone offered a bounty for it. It exists because someone scratched an itch and had the foresight to make their creation or improvements available to others.

I think what you'll find over time is that the bounty system for software sounds good in concept, but most FOSS developers write code because it solves a personal need. Ask yourself: if you were "hired" to develop an open source feature for someone else, who maintains that software when the project is complete? There's a very high likelihood that the code will go unmaintained or orphaned over time.

Conversely, I like the Gittip model where FOSS developers are rewarded for their works after-the-fact. This not only conveys gratitude from the user, but it also motivates the developer to develop and give away even more code.

Jason

I am genuinely curious as to whether this jibes with others' opinions. Please leave your feedback in the comments below. I will compile the results and deploy my competing service within a few weeks.

Comments

at 2013-04-07 23:15:50, Selena Deckelmann wrote in to say...

I've always liked Stormy's research into this topic:

http://stormyscorner.com/would-you-do-it-again-for-free

"Research shows that when someone works on something for free (for internal rewards), those internal rewards are replaced if you start paying them. Then if you stop paying them, they will stop working on it."

So, if the goal is "help more open source projects become self-sustaining" -- how does the project ensure a steady stream of income? Because the research seems to indicate that when money dries up, so do the developers.

at 2013-04-07 23:46:13, Jeff Goldschrafe wrote in to say...

This is an issue that's a lot more complicated and nuanced than either party in this email exchange is making it out to be, frankly.

I think that you're perhaps stepping out of line to make a very broad generalization when you say that "good open source software ... exists because someone scratched an itch." Many of those itches are brought about by commercial needs backed by actual currency. Many of the improvements brought to the Linux kernel, as one example, exist because particular customers requested features through IBM, Red Hat, or other project sponsors. Nobody develops robust InfiniBand/RoCE stacks to scratch an itch. They do it because in the business of high-frequency trading and other similar applications, time is literally money. It makes tremendous amounts of sense to sponsor development of a project when those enhancements deliver measurable value back to your organization.

With all due respect, you're looking at this from the perspective of a very bright person in the DevOps community which, frankly, is a marketplace of young and relatively immature ideas. Most of the tooling is delightfully unsophisticated, and this by its very nature leaves lots of itches for people to scratch until the remaining problems are too big for a handful of people to solve in isolation. Sooner or later, the fun problems get solved, leaving lots of boring ones.

I'd very much like to at the type of work that Vivid Cortex and others are doing in adaptive fault detection. The technology to do this has existed in the open-source community for literally decades, with newer projects like SciPy and pandas making it easier than ever to extract meaningful information from a pile of dead metrics. Yet in spite of this, the best tools most people have available to them today in open-source form are Graphite ports of the same dead-stupid Holt-Winters forecasting that's been in rrdtool since 2000 and statistics textbooks since 1960. These seem grea

at 2013-04-08 00:04:12, Jason Dixon wrote in to say...

@Jeff - Great points, except the examples you give are for commercial projects that were eventually open sourced. They were not crowdfunded, which is what we're discussing. Just as you mention that nobody "develops robust Infiniband/RoCE stacks to scratch an itch", they also don't crowdfund it because alternate resources are unavailable.

P.S. What is the "DevOps community"? Is that anything like the NCCS community where I worked at NASA, or the TS/SCI community where I worked at [redacted]? Just trying to get a feel for these "young and relatively immature ideas" that you've mentioned.

at 2013-04-08 00:25:14, Jeff Goldschrafe wrote in to say...

Ugh, my previous post got cut off and I don't remember how I wrapped that up.

The Linux kernel is not a commercial product that was eventually open-sourced, and the contributions made in the areas I mentioned have been freely available since their initial date of release (if I'm wrong on this, I'd love to know). But that's neither here nor there, because what I was addressing was the central point of your response. You made a very specific claim that good open-source software exists because someone wanted to scratch an itch. In the context of this claim, it's not at all relevant what the particular funding model was for developing a bunch of boring code. In further reference to this point, you responded "+++" to a tweet saying that "money is a shit motivator." I think the key is that money can be a pretty bad motivator in situations where people are willing to actually do the work to scratch an itch. However, there's lots of times when they aren't, and a crowdfunded project might have resources to feed a starving artist to fix a bunch of boring crap that nobody actually wants to devote any time to. Bottom line: in many cases, something is better than nothing. At worst, a bad implementation might get a good developer to scratch their own itch.

at 2013-04-08 01:23:01, Jason Dixon wrote in to say...

@Jeff - The central point of my response is that crowdfunding FOSS is a mistake and a potential corruptor. I gave evidence of that (as did Selena in the comments). You seem to be trying to argue that money *is* a good motivator, using the example of code, written by enterprises, that wouldn't have existed without their support. This is a non-sequitur. There was indeed an "itch to scratch"; a huge market of potential hardware and support services customers for the vendors who stepped up to finance these drivers. That was not crowdfunding FOSS.

at 2013-04-08 02:45:00, Berkay wrote in to say...

In some ways, crowdfunding may not be too different than a company employing a developer to work almost exclusively on an open source project, like VMWare does with antirez (redis) or ElasticSearch, Inc does with rashidkpc (kibana). It is safe to say that these projects would not be where they are if the developers only worked on them as side projects.

Crowdfunding can be a way for multiple entities rather than a single company to do the same for more projects by combining their resources. VMWare provides funding, antirez develops open source software and makes a living, and we all reap the benefits. Can this be done for more projects, if companies that do not necessarily have as much resources as VMWare band together? From this perspective I don't think it is necessarily corrupting. There are many developers who would prefer to work on open source projects. If they can be funded this way, why not?

at 2013-04-08 08:30:53, Jeff Goldschrafe wrote in to say...

I've been sleeping on this, and the more I think about it, the more I think we're actually on the same page but using different terms to describe what exactly we're against. I think you get much closer when you say that crowd-funding (or any kind of bounty system) is a "corruptor." That is, there are developers who have financial motivations who can do a really good job at writing open-source code (Red Hat, IBM, etc.), and there are hobby developers who have more personal motivations who can do a really good job at writing code, but when you take a hobby developer and turn their empassioned side project into a sequence of tiny obligations it can have all kinds of unintended repercussions for the developer and the project. I don't think this is due to money as a motivator per se, since it can also happen if social pressures are too high; look at what happened when Karanbir Singh freaked out and disappeared from the CentOS project a couple of years ago. But needless to say, cash on the table makes this kind of burnout really easy.

I don't believe in the slippery slope phenomenon, and I think that crowdfunding can still be a good idea, provided that a) not everything that gets funded should be automatically treated as a commitment from the perspective of the project developers and b) developers need to understand their limitations. On a small project team, a simple bounty here or there is likely to be harmless to the hobby developers' underlying motivation, and it might even be a helpful incentive to eliminate some technical debt (who doesn't love that?). On a larger project team, a high number of outstanding but trivial bounties can be an effective motivator in getting smaller developers to take a first step in giving back to the project. The other case, where you have a small team being offered a ton of money for commitments that will utterly drain them and remove any desire to continue on the project, is basically digging a d

at 2013-04-08 08:51:00, Jason Dixon wrote in to say...

@Berkay and @Jeff - Yes, the problem imho begins when there are strings attached to a developer's motivation. I'm not talking about the "strings" inherent to full-time employment. An employer that pays someone to generate features, and then open sources that code, is a a good thing. You have an implied "subscription" in that the developer/owner/maintainer of said code is properly motivated to continue supporting their work. Conversely, a bounty system creates a situation where the developer is *temporarily* motivated to work on a task. Even if the project does succeed (and there is evidence to suggest these are largely inefficient, and often unsuccessful endeavors), what happens when the money motivator is removed? If the code wasn't interesting enough to create as a part-time/hobbyist effort, who will do the dirty work to maintain bug fixes and future enhancements going forward?

at 2013-04-08 10:14:14, Berkay wrote in to say...

Agreed. If that's what they are after, short term bounty approach to work on minor things is not all that useful.

I was hoping that it could be structured to support full time work. Something like, developer lays out his proposal to do whatever s/he intends to do, specifies the cost, etc. and interested parties chip in and/or commit certain one time of periodic contribution. If enough people chip in, developer can start the work, and continue as long as there is funding. There can be tiers encouraging higher level of contributions (priority, better access, etc.) similar to kickstarter, etc.

I realize that there are many issues that would need to be resolved for something like this to work, but it would likely enable more people to work on open source software.

Their current approach sounds counter productive; may be adapt to make it useful for everyone somehow.

at 2013-04-08 11:33:41, Devon H. O'Dell wrote in to say...

Large vendors paying a developer to implement a feature are essentially servicing as a crowdsourcing proxy of sorts. The "crowd" is their customer base. The projects are feature / support requests. The money comes from sustained payments from the crowd.

FOSS idealism only gets you so far. A lot of modern software engineering problems (in kernels and in high performance network systems) are extremely hard and require a very broad and deep level of technical knowledge. The people who have this knowledge are generally gainfully employed, tied up in academia, or otherwise occupied. When no one is available to work on these sorts of projects, there must be some motivating factor to get them to contribute.

Indeed, many of these projects may not be that interesting for someone implementing feature M in a slightly different way for the Nth time. So it's not even always fair to say that things are done to "scratch an itch." The people most likely interested in doing something like that have a lot to learn (i.e. are "less qualified" -- at least from the context of being able to complete a project without significant mentorship). Those who are more qualified may not have the drive or desire to implement the feature (again, in some cases).

I guarantee you that writing network drivers for Yet Another Network Card does not get more fun. This already tedious task gets more boring the more you do it. It doesn't matter if it's a fancy new 40GbE thing. Writing Yet Another Web Form Handler doesn't get more fun, either. It doesn't matter whether you're using any new fancy AJAX / COMET / long polling / WebSockets / SPDY stuff. The excitement comes from new ideas of what you are doing with these pieces, and sometimes you have to do grunt work. The best way to get that done is to have an incentive.

I will also note that as a Google Summer of Code administrator for a 5-year veteran project, the promise of money is a great way to get stuff done and get new people interested in your project. As a software engineer who has worked on many proprietary products built on top of FOSS, I would not have spent as much time with as many different projects as I have unless I was paid to do so. I simply don't have a personal use for them.

I don't see anything wrong with this model for Getting Shit Done in FOSS. FreeBSD, for instance, has funded many very useful, difficult, and tedious projects through the FreeBSD Foundation, which is effectively a crowdsourcing proxy for FreeBSD. I agree that some of the wording of the email you referenced sounds like it makes false assumptions about how and why bugfixes and features appear in these projects. But I also don't see it speaking in ultimatums, so I think that a reaction to the idea that FOSS "needs money to be successful" is inferred, not implied.

I will agree that there is an implication that FOSS projects are not as competitive as proprietary solutions. Unfortunately, I think the area of competition is in support, and I think using this model to pay people to provide support has a sort of antithetical for-profit tone to it that flies in the face of the point. As long as this doesn't happen, I am rather excited about the potential of the project, whether or not its mission statement could use rewording.

at 2013-04-09 15:55:46, Kenshi wrote in to say...

I don't necessarily think it's a bad thing (for the same reasons others have mentioned in the comments). PyPy has rolled their own version of this by allowing you to donate to certain initiatives and projects: http://pypy.org/tmdonate.html

at 2013-04-11 11:46:40, James wrote in to say...

Hi Jason,

Someone sent me this link - I'm the person who responded to your email. If you wanted to include my response that's OK (thanks for respecting privacy) but if not that's OK too. It's your blog post & you're just giving your opinion and the discussion here seems pretty balanced. Just a few points if I may:

1. Catincan is not a bounty solution. Developers maintain control and decide what features they want to put up for funding. This approach can be used in a variety of ways beyond what we think of as strictly feature for funding such as making a project compatible with another OS or building the next version of a project.

2. "Our goal is to help more open source projects become self-sustaining and competitive with propriety solutions."

The operative word in that sentence is more. It's not intended to be humiliating to open source solutions. Many people & businesses are far too conservative and may not trust that an Open Source project will be sustained. You probably know that old saying, "Nobody ever got fired for buying IBM." We're hoping in the future it's more like "Nobody ever got fired for choosing Open Source."

3. Catincan is no silver bullet for every project. Open Source projects are diverse and different projects need different approaches. We hope our approach can help a substantial amount of them but there are other ways we have in mind as well. We're trying crowdfunding at first and if that works it can be used as a trampoline to let us experiment with the other approaches.

Anyways, good discussion & take care.

Add a comment:

  name

  email

  url

max length 4000 chars