beeware/paying-the-piper

A project for discussing ways to fund open source development.

BeeWare

BeeWare is a collection of tools and libraries for building and distributing native applications in Python.

For an introduction to the full BeeWare suite, we recommend running the BeeWare Tutorial.

Community

You can talk to the BeeWare community through:

• @[email protected] on Mastodon
• Discord

We foster a welcoming and respectful community as described in our BeeWare Community Code of Conduct.

Contributing

If you experience problems with BeeWare, log them on GitHub. If you want to contribute code, please fork the code and submit a pull request.

paying-the-piper's Issues

Just make it super-easy to install

Ignoring completely how to pay the piper, I do have an opinion on how to make something successful. Perhaps you could sell the install process. The software is open source, but a locked-down, pre-install VM with a web admin interface costs money. I can tell you right now, if I could pay for various systems which would just boot up as a VM, let me set the machine name and hook up my own authentication, that would make things so, so much easier. I'll pay a per-VM license fee for commercially supported applications which do things like version control, continuous integration, application support, running corporate applications etc. If I could just give a VM straight to the relevant team that they could boot up and configure in 15 minutes, with decent logging and a basic support arrangement, that would be amazing.

And I could evaluate such things myself internally by installing the open source code into a Linux VM that I'm maintaining on my laptop, or go to the effort of running my own if I need to.

In my experience, if the cost of application maintenance can be made low enough, that will be preferred to paying for an internal developer to support it. Companies are often looking for ways to capitalise their expenditure to reduce their operating budgets.

Offer hosting

Of course, this model can only be used if the project is hostable in some way. Examples are sentry and the paid hosting option at wordpress.com

Charity

I've been carrying this idea with me for a bit, but it's in a very early stage.
Would love to hear thoughts and doubts on this.

What if someone started a charity for OSS developers?

If you are in the 33% tax bracket, the actual cost of a $100 donation is only $67 ($100 less the $33 tax savings) [1]

Donating to a charity will get the company tax benefits. This enables them to give more.

The charity would get its money by collecting donations from companies (and maybe individuals). The charity would then forward the donations to OS developers selected beforehand. Developers can get into this program by applying, so only a few selected projects are supported directly. Developers are only supported for a duration chosen upfront, to enable support of many projects.

To keep the charity running, a percentage of the donations would have to be kept in. This money will be used to look for more donors, review which projects to support and so on.

Further possibilities:

• Hiring in tech is hard and companies go to great length to find talent. The README's of popular GitHub repositories and their websites are viewed countless times by the targeted audience. To further give back to the donors, a "Company X is using (and supporting) this project, and they're hiring" could be embedded. This would be a Sponsorship Payment, which is still deductible.
• Donors may influence which project their donation should count towards
• Micro donations to get some bug fixed or feature done in a specific project that is blocking the company
• PR: Let company use the charity's logo in their printed material, and link to them from the charity's website

Benefits:

• Developers can actually work on the OS project instead of spending their time doing something else, like writing a book about it or contract work
• Companies get tax benefits
• Companies may find new employees
• Companies can improve their image

Related:

• https://www.patreon.com/
• https://stripe.com/blog/open-source-retreat-2016
• https://www.gov.uk/tax-limited-company-gives-to-charity/sponsoring-a-charity

Making LTS version **LONG** term support as the corporate world hears it

So here is an idea, not sure how easily feasible it is but might be worth digging into since the subject has already been mentioned on the Django mailing-list. This proposition is mainly based on Django and not other open-source projects but I have the feeling this discussion is mostly geared towards the Django eco-system in general and not the open-source community. And this is just another one of those "find something to sell and use the money to fund the rest".

A lot of companies with means hear 10 or 15 years when they hear LTS, not 3 or 4 years.
So I understand that maintaining 1.4 (or 1.6 as it's the version of Django shipped with several LTS linux distros) for another 6 years represent some work and that there will be security features that will be harder to port than others.

But companies are currently paying huge amounts of money to RedHat to have those LTS versions, why not try to get a piece of that money by having Django propose "VLTS" versions for a fee (like for access to a dedicated Pypi server)?

It seems to me that:
a) porting security fixes back to older version, in general, is, in itself not the hardest job that a community has to face (not the most interesting one either, I agree)
b) the customer base is already there
c) that customer base has demonstrated willingness to pay lots of money for "special treatment"

Get companies to sit down with OSS developers and hear them out

From another underfunded industry, journalism:

I would love to see more people that benefit from the existence of journalism put their money where their mouth is. Facebook, Amazon, Apple, Twitter, Yahoo! and the many investors behind those organisations should all pool money with Google into an independent fund for journalism innovations that can be distributed globally.

Basically, Google created a £150m fund in Europe to support journalism (granted, it was a bit of a mea culpa), and the author of this article proposes Silicon Valley companies do the same.

Has anybody gotten Silicon Valley software companies to sit down at the table with OSS developers to talk about funding issues? I'm sure this has happened in many one-off conversations but what about framing it as a bigger conversation?

I'm just thinking about how media is widely accepted to be an underfunded industry, even if we don't know how to fix it, but I don't think OSS has yet achieved that same sort of visibility, which means nobody is motivated to address it.

If I organized something like this in SF Bay Area, would anybody want to come? Nominate others? Have ideas for agenda items that must be discussed?

Create a funding foundation

It would be possible to create a funding foundation with the explicit goal of sponsoring development efforts against specific criteria. It could also award prizes for community achievement to recognise major contributions from individuals. It would be possible to fund this through donations/bequests, such as bitcoin donations, direct dollar donations etc. This might help provide greater visibility for those involved in contributing to software but who don't have a clear funding source. It might also be able to fund sabbaticals or sponsor student research where there is an open source benefit.

Community source each feature / functionality

The idea?

I posed this at my previous role, it was largely overlooked as a viable strategy however I think the idea is pitched somewhere between freemium and traditional crowd sourcing.

You create your MLP

But instead of being very lean and scope tight by pruning features / functionality, you attach story points to them regardless. Story points can then be translated into funding. People argue you can't estimate accurately enough, but the T-shirt idea will do well enough. S, M, L

Depending on your project you can say that delivering a L T-shirt will cost you X. By breaking down the functionality as you'd intend to deliver it, the cost is reduced and then shared across the user base.

You then crowd source the funding for each story, depending on what people want from the project most depends on what you deliver and in what order.

As soon as a new T-Shirt is purchased, then that can open up new avenues for the project which can be sized and estimated accordingly.

Sabbatical financing

(Taking another approach to the idea proposed in #28 and #3)

Goal: Give an open source software developer three to six months of funding to work on a specific project/feature.

Three to six months is long enough for serious work to get done and not too long such that the developer couldn't return to the job/position they were working on before.

The sabbatical would be funded via a five-year zero-interest loan. The community/non-profit interested in supporting the developer would have to raise far less money (maybe $10-20k depending on the credit worthiness of the developer?). If there were a lot of developers interested in taking this deal, this approach could fund a lot of open source development. I'm assuming that a third-party, perhaps one of these new peer-to-peer lenders (e.g., https://www.upstart.com/), could handle the actual loan.

How do I give you money?

Please shut up and take my money. Seriously, giving your project money needs to be easy. Options:

• Patreon Example: DjangoGirls
• Square Cash
• PayPal? (not linked because...)

What companies will pay for

In my experience, companies are not very interested in paying for software as such, but rather in paying for solutions. This includes maintenance, support and liability. As a result, the open source nature of the underlying software need not be any issue.

Companies like Redhat pursue this strategy at the O/S level, plus the application level, plus the consulting level. This matches the commercial strategy of IBM who have roughly a similar market offering (although they also do hardware).

In my view, what is being paid for is confidence in the solution, rather than for closed vs open source as such. Redhat have invested in their reputation for providing solutions on open source software, and a part of their reputation comes from paying developers to work on open source software.

Perhaps the original question was directed more to how individuals could make money from open source, or how other businesses could reasonably be built which include paid open source developers.

I am not sure how to 'close off' my line of thought, so I won't. Comments welcome.

Add license terms to require crediting project when used

Credit for this idea goes to @inconshreveable. Thinking about the long-term goal of solving funding, there are shorter-term goals that will help get us there. One big problem is a lack of data around stats/usage for dev tools, which makes it hard to demonstrate value.

Creating a license that requires payment is still controversial and hard to enforce, but what about starting with amending license terms to require disclosing if the project is used? Not much different from asking users to credit you in any other context.

Also hard to enforce, but big companies will probably do it, which are probably the most important ones to know about anyway.

Exploit crowdfunding to raise money

Kickstarter/IndieGoGo exist, and have been used to fund some open source development:

• Django Schema Migrations
• Django PostgreSQL support
• Django REST framework 3
• Multiple template engines

How do you create a business that pays for open source development?

One way to get paid to write open source is to get hired by a company to do that, but it's hard. There aren't a lot of businesses doing it. The real question then is how to create a business model in which it makes commercial sense to invest money into open source development at a large scale?

Most very small businesses will not support a full-time software engineer, be that open or closed source. In general, "software" isn't going to be the product, rather some kind of service is going to be the product. If that's true, then the scale needs to be large before the company will need to fund maintenance on that software in order to support their customers.

If you want software to be the product, you must (like any business) identify who is going to pay for your software, and why? In general, the answer is going to be "big business", because small business will probably prefer to buy some SAAS over the web. The web is changing a lot of software into a service through the web as a delivery model, so you really might be able to go through the service business model.

However, let's persist with thinking about how to sell open source software commercially. License agreements do exist which cover this, as does the freemium model. I can think of one way to make this really work: compliance.

A lot of companies need accredited, compliant, secure software. They need to be running systems which are ISO compliant, or security compliant, or guaranteed to have code review etc. They need systems which integrate into their AD servers and other systems.

I would look at ways to make companies pay for these enterprise features, which open source developers are less likely to need for themselves to evaluate and try out the base product.

Snabb Switch experience

In the Snabb Switch community we have been exploring ways to sustainably fuel development. The first braindump was Snabb Switch for Entrepreneurs and our early experience so far is pretty positive.

We are in the networking industry. Big companies use our software as an alternative to spending millions of dollars on license fees to vendors like Cisco. Smaller companies use our software as an alternative to being neglected by vendors. Service providers (individuals, small companies, big companies) cooperate to deliver projects to users in the form of "provide functionality X on date Y."

The project has a little economy growing organically around it. I think about this in terms of GNP (money entering the ecosystem) and GDP (money circulating within the ecosystem). In both cases it doesn't matter who is paying for and delivering the services: it just matters that somebody is doing this and that activity is growing to create opportunities for new people. (There is no central person or commercial entity that we need to feed money to either now or in the future.)

Money enters the ecosystem in a few ways:

1. End-user company buys services related to the project. This could be to build a whole product as open source (years of effort), to make some modest customizations (months of effort), or to provide support or training (perhaps ongoingly).
2. People who are already employed decide to contribute to the project as part of their job. This could be an end-user who wants to use the software to solve problems in their own network or it could be somebody is a vendor who wants to use the software as part of a larger solution.
3. Service providers invest their own time in building a reputation and creating new opportunities for themselves.
4. Organizations such as NLnet sponsor people to make contributions to the project.

Money circulates within the ecosystem when service providers cooperate to deliver projects. There is no single services company in our community: rather there are many people and companies of different shapes and sizes who cooperate on projects. There are also no barriers to entry within this ecosystem: anybody can make an offer along the lines of "I will provide functionality X on date Y" or "I will spend Z weeks working on this project" and everybody is free to decide who to work with.

Currently this is working out fairly well. Gradually we are gaining more service-providers, more user-contributors, and more user-customers. There are positive network effects where each successful project expands the set of problems we can attack with confidence.

There is a long way to go though :). I would estimate that we are now less than 100 people using and developing the software in a professional context. Quite a bit of our work is interconnected. Over time we need to build a robust and decentralized commercial ecosystem like the one surrounding the Linux kernel. This takes time and our strategy is to keep growing at an organic pace.

I hope that braindump on our experience is of some use to somebody!

As a contractor charge an OSS tax

I'm a contractor and my standard contract states that I have the right to extract any generic code from the client's project. That has worked well but I'm considering adding a "tax" clause that states I can use 20% of the time I bill the client for to contribute to the open source software that is used in the project. The tax amount could obviously be any arbitrary number but 20% would allow 4 days on their project, 1 day polishing the open source software.

My reasoning for this is that I struggle with burnout if I'm not being compensated for the hours that I work on a project doing general maintenance and solving bugs for others.

If a client balks it should be easy to point out that they are profiting immensely from the thousands of hours that went in to initially building the framework and related software. It is easily boosting the project's productivity more than 20%

What level to pitch pricing tiers?

I thought I'd share a breakdown of the pricing tiers in Django REST framework's Kickstarter campaign, including number of backers and resulting portion of funding. Although all projects will have differing userbase/organization demographics and will have different skews, I still think it may be useful to others to get a sense of which pricing tiers are worth aiming at.

price	# backers	% backers	£ total	% total	tier equivalent (*)
£5	91	22%	£455	1%	~$0.6/mo
£10	124	31%	£1,240	4%	~$1.3/mo
£25	42	10%	£1,050	3%	~$3/mo
£50	60	15%	£3,000	9%	~$6/mo
£100	45	11%	£4,500	14%	~$12/mo
£250	26	6%	£6,500	20%	~$32/mo
£1,000	10	2%	£10,000	31%	~$128/mo
£5,000	1	0.2%	£5,000	15%	~$638/mo

Take home is that the lowest priced three tiers represent 64% of the backers, but only 9% of the total income.
The remaining five tiers are where there was money to be made for the project.

(That's not to say that engagement at lower levels might not still be valuable, ofc)

(*) I've tried to give a rough USD/mo equivalent by treating the Kickstarter funding as if it had instead been a dollar price invested in a year long project, and seeing where the $/mo tier ranges would come out.

Jobs boards

@nanuxbe Raised this indirectly in #41, but jobs boards are one way to generate revenue for a large project. Hiring is a problem that isn't going away, and in the grand scheme of things, doesn't require a lot of maintenance - some curation of content, but that's it.

A project is also in a prime position to provide the service (since the project website provides prime real estate and a communications hub). A project can also use it's job board to further social goals - for example, encouraging diversity in hiring, highlighting LGBTI-friendly benefit arrangements, and so on.

However, this option is only available to existing, large communities, or communities that act as a hub for other communities. Smaller communities or projects that are just starting wont yet have the momentum to support a job board.

Request for stories about *real humans* working on OSS

As mentioned in #49, the value of OSS is still really hard to explain to a layperson, but broader public support is needed to make this A Thing.

One way to do that is by highlighting individual stories of people who are contributing to OSS but find themselves short on time or money. The ProPublica story about Werner Koch for example helped make his situation real and tangible for people outside of the community, and he pulled in $250K in donations.

To that point, consider this an open call: I'm working with a foundation right now to collect stories about OSS contributors and share them with a wider community. I've reached out to some of you on here already. If anyone wants to share a story (about themselves or others) that highlights the issues around OSS funding, I'd love to hear it.

Note these don't just have to be stories about things not working: if you managed to make it work through consulting on the side, or getting hired by a company, please share. If you're good on money but still feel short on time and juggling priorities, I want to hear it. The more concrete you can make it, the better.

Feel free to post below or email me privately. If there's anything you want me to keep confidential, just let me know.

Paywalls on software repositories

Python has PyPI; other languages have analogous repositories of software.

However, that software is all free to use. There's no way to charge for access.

Adding a way to "license" access to content on PyPI - either by pay per download, monthly subscription initiated as soon as you download, Pay per version, or some other model,

The key is to make it as easy as possible to possible to collect small amounts of money each time a piece of software is used, and turn that into a bill that companies using open source can roll into their budgets.

Wordpress is a good model of a community that does this well.

Funding through sales of tutorials or documentation

For several years I've successfully run the RailsApps project, working full-time on the project without corporate sponsorship or gainful employment, by selling tutorials. I've found that developers are reluctant to pay for software but will pay for learning resources.

The RailsApps project is a collection of open source Rails example applications, hosted on GitHub and available for free, plus the open source and free-to-use Rails Composer tool for generating Rails starter applications. Developers contribute code and report issues. I provide detailed READMEs and basic documentation for free with the code. To support myself, working full-time on the project, I write and sell the in-depth Capstone Rails Tutorials plus a book Learn Ruby on Rails. Initially I sold the tutorials on a subscription basis for $19/month and I had over 500 subscribers paying $10,000/month. There was one significant problem with this model. I spent all my time writing the tutorials to support myself and had little time to actually work on the software. I recently changed the business model and now sell the tutorials for $95 as a one-time purchase instead of a subscription. Revenue has dropped to half what it was, so subscriptions were a better revenue model.

I believe this approach hasn't been explored by many open source developers. And it has potential as a sustainable source of funding for some open source projects. It's not for everyone, however. I've got years of experience as a journalist and technical writer. Many developers don't like to write documentation, much less in-depth tutorials. However, for an open source developer who likes to write, selling tutorials to accompany software can be a source of financial support. It also benefits the user community by providing documentation and learning resource beyond the basics.

Unionize

One way to force companies to pay for the open source they're using - collectively refuse to work for companies that don't pay for open source. If employers find they can't get employees because of their open source donation policies, then open source donation will become a big issue pretty quickly.

This could also be used to advocate for other desirable social changes - improvements in diversity, ensuring adequate training and mentoring for new developers, eliminating toxic work practices and work environments, and so on.

Unlike traditional labour unions, there's no reason this needs to be tied in any way to pay (except for establishing the social good of basic minimums).

However, it would require collective agreement from a large part of the community - which I suspect would be difficult to achieve without a triggering event.

@kelseyq's keynote at Forward3 is worth watching for some historical context - both in the sense of "things that have happened in San Francisco", and "things that affect dockers (as in Longshoremen) and containers".

Sabbaticals

I'm inspired by the GSOC model of funding student developers to work on open source projects.

The part I think they get right is A) making it a dedicated, focused period of time vs. ad-hoc "whenever I get around to it", and B) providing stipends to make it financially feasible.

The part I think could be iterated upon is A) providing stipends to experienced contributors, not just students, and B) widening the scope of projects to include more niche stuff. And, obviously, C) making it a year-round thing.

What do you think about providing paid "sabbaticals" for contributors to work on an open source project for a dedicated 1-3 months, a la GSOC? It would be harder for those with full-time jobs, I think, but people might be able to knock out a lot instead of dragging their to-dos out with a couple hours/wk here and there.

A Decentralised Collective Organisation (DCO)

Basically you issue some tokens that represents a share of the open source project (OSP). People/Companies that are interested to have an opinion about where the project should go, what should be the priorities should buy those tokens in order to "vote". Votes are done by giving back the tokens to the DCO, which are then put back by the DCO to be sold on the market again. The cash accumulated by the DCO can then be redistributed to its core programers as salary or as bounty for external programers.
Another aspect could be that, if you think that there is an issue that you think is important, you can buy tokens on the exchange market, and you allocate them to the issue. They work as a bounty, until the issue hasn't been closed, the token is kept under the control of the OSP (or even better an Ethereum smart contract). When the issue is closed, the tokens are redistributed to the programers that contributed to fixing the issue. They can then sold by the programmer on the exchange for e.g. bitcoins or be reused to vote on decisions concerning the OSP-DCO.
This way both people that work on the project and people that invest on the project can vote on the direction that the project should take.

Keeping thoughts on this matter organized

There's a LOT of discussion here, thus a LOT to think about. I'd like to keep my running thoughts IN my local copy of this repo, so everything's in one place. I'd imagine I might not be the only person who wants to do that.

So, I'm proposing a .gitignore file with mynotes_*. That will let everyone have a mynotes_YOURNAME.xyz file in their local copy of the repo, to keep their thoughts on this topic IN this repo, w/o flooding the repo with everyone's personal notes.

A pull request to that effect is on the way.

A new Open Source license

Open Source licenses focus on user freedoms and developer freedoms, but make no attempt to address the freeloader problem. There's nothing stopping a company from using a piece of open source software, making massive amounts of money because of that software, and then give nothing back to the community that developed the software that had a big part in generating that success.

This "Freeloader" problem is the flaw that needs to be addressed. If a company can't give back in kind, they can give back in a more meaningful way - by donating money.

The GPL and other Free (tm) Software licenses address the issue... by scorching the earth, and forcing all code that touches the released code to also be released. This condition means that the GPL is commercially toxic - even if you consider that assertion to be scaremongering and FUD, the fact remains that there is a perception that it is commercially toxic, which is reinforced by the fact that the premise it offers is so fundamentally alien to commercial entities.

So - can we address the Freeloader problem by a change in licensing?

The FSF lists 4 "essential freedoms":

• The freedom to run the program as you wish, for any purpose (freedom 0).
• The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1).
• The freedom to redistribute copies so you can help your neighbor (freedom 2).
• The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes.

Would it be viable to come up with a new license that ensures all these freedoms, but also prevents freeloading?

Would it be possible to reframe licensing terms so that anyone can get the code, use the code, and modify the code, but as soon as it is used to generate revenue/profit, a license fee kicks in?

Redistributors, like operating system vendors, would obviously be affected by any license change like this. Any license text would need to be careful that it didn't prevent this use case. The analogy here might be reseller arrangements.

It's also possible we would see the emergence of competing products - 0$ FOSS and Paid FOSS. It would then be incumbent on the paid FOSS to be better than the 0$ FOSS alternatives.

Migrating existing projects to a Paid FOSS license would also be a complex process.

Solved problem?

Just a reality check: is funding open source projects already a solved problem?

There are tens of thousands of people working full-time on developing open source software and being paid for it. For one example the OpenStack project shipped a new release this week that was developed by 1,944 people from 164 organizations over the past 6 months.

One alternative to inventing new ways to fund open source projects would be to think really hard about how to replicate the methods that are working for other projects.

Trademark licensing as a potential revenue source

There are two pieces of IP held by an open source project:

• The copyright over the code
• The Trademark over the project name.

The code is the usual place where people try to extract value. However, there is also significant value in the project trademark. If you were restricted from using the name "Project X" without paying a tithe to the project, that would mean the project would get revenue from any training company who wanted to produce a training course, author who wanted to write a book, or company that wanted to put "We use X" on their website.

The catch will be:

• Working out how to make this compatible with nominative use exceptions to trademarks
• Enforcement. If a big publisher published a book about Project X, and didn't pay a tithe... who pays for the lawyers to get them to pay up?

Core is open source, (enterprise) features remain closed source

Nginx Inc. the company behind nginx is using a model like this. Nginx is free and open source, but they offer a pro version called Nginx Plus to fund development. The Plus version is subscription based and targeted to enterprise customers.

Get some of that sweet, sweet Mozilla cash

Mozilla's launching an Open Source Support Program to "a) a “give back” [to] Open Source and Free Software projects that Mozilla relies on; and b) “give forward” [to] other projects where financial resources from Mozilla can make our entire community more successful."

It's unclear exactly how to engage or ask for money, but the wiki has some more information along with a list of (known) projects Mozilla relies on.

New vocabulary?

Hi everyone! I read through all the posts so far, and here are a couple of observations I've made:

Open source != open source != open source.
There seems to be tension around "I'm making it work fine doing X" vs. other experiences struggling. I think this comes from a conflict in what "open source" actually means. We don't have vocabulary to differentiate, say, a company that open sources its consumer app vs. a library built by a solo developer. Certainly, some open source has a clear business model, but some projects don't. So the question is not really, "how do we fund open source", but "how do we fund open source that is...", well, whatever we call it?

Maybe we start by listing out the different types of FOSS scenarios we can think of? Would be great to see where certain things work (ex. selling services, tutorials) but others don't.

FOSS is as valuable to society as bridges are to cities.
There's a cultural shift that needs to happen: the assumption that software is a commercial industry, and all useful things in software must have a business model. This may have been true in the early days, but today, given how technology permeates absolutely everything, I think of FOSS (at least the part with a funding problem) as the digital infrastructure of society. Funding non-commercial FOSS looks a lot to me like funding research, academia, arts, infrastructure, or any other public good in society. To build an institutional system that supports FOSS (not just a jumble of band-aid solutions), I think we can get a lot of inspiration from looking at how those sectors are supported. Curious to get others' thoughts on this.

Frame funding costs so they can be covered by discretionary spending

18F recently announced a plan to use discretionary spending limits to pay for open source code development on the micro scale.

The key factor here is that many employees have access to discretionary funding pools; if we can find a way to make "selling" something that can be purchased by these discretionary funds, then funding an FOSS developer becomes a lot easier.

In informal discussions, annual discretionary budgets on the order of $10-25k have been suggested as common for mid-high managers in established companies.

Funding open source books

As a first time author myself, dealing with funding is something that I've had to deal with myself. Given most people fail with their first book, I've been rather fortunate in comparison. It hasn't been easy, though, and I've had to learn some lessons the hard way.

I started by going completely open. Since then I've had to backpedal a bit and keep a part of the content behind a paywall. I'm not sure if that's a good long term solution, though, and I'm still experimenting.

Finnish Constraints

Given I'm a Finn, I have a couple of additional constraints:

• I cannot accept donations. You will require a permit and the system is meant only for non-profits. I don't want to try my luck with the law.
• The status of crowdfunding is a little dubious in Finland. I don't have easy access to Kickstarter for example. Apparently it should be legal as long as the word "donation" isn't mentioned anywhere.
• If I sell something myself, I'll have to deal with VATMOSS. I don't want to do that. Instead I've settled with proxies to deal with the requirements of the law.

Possible Models

The way I see it, there are a couple of basic ways to approach funding open source books. Note that by an open source book I mean a book that has its content open, not a book about open source per se. This means using somewhat permissive licensing and providing access to the content.

The biggest advantage of this has been that it has encouraged the community to collaborate with me. Given I'm using a self-published approach, this has been a huge boon for me. I believe this has contributed to the quality of the book immensely. I even managed to attract an editor for my book and have gained many valuable contacts as a result beyond financial gain.

I've tried to list models I'm aware of below:

Crowdfunding

Probably the best example of this is @getify's You Don't Know JS. The project managed to raise over $16k through Kickstarter alone.

Obviously for crowdfunding to work you will need some PR presence and a suitable legislation. The topic has to be interesting enough for a suitable amount of people. I don't expect you can target niche topics through this approach. I believe it's a valid option for some, though.

Self-funded

This is the approach I took with my book. @nzakas seems to have taken a similar approach with his Understanding ECMAScript 6.

The idea is that you fund the development by selling your book while developing it. Platforms, such as Leanpub work well, although there are other options.

In some cases this may lead to an actual publication deal. The greatest benefit of this option is that openness makes your work available to many. This likely cuts into potential income (why to buy if your offering is free?) but it's a good way to reach a wider audience without having to sell. In addition you'll get a nicer royalty (around 85% through Leanpub, more is possible) than through a conventional publisher.

The downside is that you'll have to perform all tasks a publisher would normally do for you. You may contract other people to help you. It is also possible volunteers will appear. The open approach is conducive to this.

There are a couple of additional models related to self-funding. The trick is in finding a nice balance between open and closed. You can, for instance, sell your book using the following hooks:

• Integrate Kickstarter to your sales model - i.e., when a certain goal is met (books sold, whatnot), something happens (a chapter becomes freely available, buyers get access to new one).
• Promise to open the content eventually (i.e., year from when a chapter is published). This provides some level of exclusivity to the early adopters while allowing the content to become content eventually.

Of course self-publishing approach can lead to other opportunities in form of consulting, training and so on. It might be just the means to reach your actual customers. Therefore optimizing for income may not be the right approach as that would hurt the reach and therefore your real business.

Conclusion

Perhaps some of these ideas are applicable to open source development in general. In the end you are playing with some of the basic concepts to provide value for your paying customers. Providing some form of exclusivity is a good starting point for example.

It would be very interesting to hear about your experiences. I know technical publishing is hard. There are certain fundamentals that are hard to work around. A lot of these things run on reputation. Especially as a first time author that's something you have to develop amongst other capabilities.

I believe writing guides to complement actual open source software projects might be one way to help funding them. This is the way Packt, Apress, and such operate after all. What if the initiative came from the projects themselves instead? That would allow them to capture more of the profit while helping to fund the development. You would likely have to collaborate with technical authors but I don't see this as a bad way myself. There's something to gain for everyone involved after all.

Don't use money to estimate the value

Economy needs balance. In computer games you can not balance the gameplay using only single kind of resources - gold. There are always at least three types of resources to keep things playable. Otherwise any game becomes a money hoarder game. This makes money a player's goal, as it already happens in current economy.

Bigger economy always eats lesser one. If you use money that is the main (and the only?) resource of current economy, you have no chance to stand over it. That system has a good protection mechanisms evolved at least through one century, so be prepared to met them (Gratipocalypse). Decoupling money from value is a must.

Gratipay 1.0 had made a good progress towards that - you could use a little sum, to say $1 donated to you by others, to redistribute the value as little as $0.01 to people who you find important. For me it was "Python mana" - I used to tag people based on how important they were to me. Thinking that they could buy a beer for that (not a healthy choice, but still) was fun to play with. In the end Gratipay 1.0 contained a graph of how different people were useful to each other. We never exported this graph and I will never have time to work on that, but that was the idea.

The graph can be used for different things. For example, when somebody leaves the community to join big company, that company may choose to compensate the community the loss of its member (his switch to passive) using this graph as a redistribution ratio.

Then the flow starts, people know how much do they need, so they will have the choice to redirect the flow after it exceeds their basic needs to other people. This requires them to know they basic needs requirements, which increases when they have families and rents. Sum of all means is the basic capacity. Capacity means how much people can this economy support.

Request for stories about real humans* working on OSS

As mentioned in #49, the value of OSS is still really hard to explain to a layperson, but broader public support is needed to make this A Thing.

One way to do that is by highlighting individual stories of people who are contributing to OSS but find themselves short on time or money. The ProPublica story about Werner Koch for example helped make his situation real and tangible for people outside of the community, and he pulled in $250K in donations.

To that point, consider this an open call: I'm working with a foundation right now to collect stories about OSS contributors and share them with a wider community. I've reached out to some of you on here already. If anyone wants to share a story (about themselves or others) that highlights the issues around OSS funding, I'd love to hear it.

Note these don't just have to be stories about things not working: if you managed to make it work through consulting on the side, or getting hired by a company, those are great to hear about too.

Feel free to post below or email me privately. If there's anything you want me to keep confidential, just let me know. Can't promise I'll use them all, but I'll try!

Developers negotiate their role better

This sounds daft, but I think the responsibility should fall to some extent on the developers. There is no other manufacturing industry whereby you can become an expert at building something tangible without first building up a toolset.

A plumber, can lend some tools from his mates when he's starting out. But at some point he's going to need to buy a pipe bender, or a cutter.

If developers were more hardline about their requirements. open sourcing would be more readily accepted by smaller companies.

I'll work with you to build out our reporting dashboard but - we open source it from the beginning.

I'll accept the position but on the condition that I'm going to be releasing our markup templates (sans styling / branding)

I'll only build a team from Open Source contributors.

Ruby Together style grouping

I really like the work going on at https://rubytogether.org/ -- which lets companies give money to the foundation that then gets doled out to community projects based on need. I see this as only really sustaining fundamental projects in the ecosystem, and not a solution for smallish projects.

In the Python world, the PSF does a small part of this job with grants, but it isn't nearly as focused on the goal of sustaining engineering. I'd love to have something like this be able to fund larger resources like PyPI, pip, Read the Docs, PyPy, CPython and other large core infrastructure.

It seems like a lot of us are doing legwork to raise funding independently, and merging these efforts to fund more projects would save us all a lot of work. Even just getting 1 person who could handle fundraising and then distribute funds to the projects, who could focus on doing work instead of raising money, would be a huge win.

Individual membership with varying levels of benefits

Taking a page from very well-established non-profit entities, art museums, why not allow individuals to become "members," where the benefits of membership vary depending on the contribution. It seems like one could do this not just for corporate sponsors (I gather this is already done) but also for individuals. That is, if it works for museums (and public radio in the USA) it might work for open source.

Here's one example, the Museum of Fine Arts in Boston: http://www.mfa.org/membership/levels-and-benefits . The MFA has 11 basic levels:

• Supporter $75–$109 (free parking, etc)
• Contributor $110–$249 (extra guest passes)
• Ambassador $250–$749 (guest passes to other museums)
• Sustainer $750–$1,499 (lots of guest passes)
• Leader $1,500–$2,999 (invitation to openings of exhibits)
• Patron Member $3,000–$5,999
• Patron Fellow $6,000–$11,999
• Patron Sponsor $12,000–$29,999
• Director's Circle $30,000–$49,999 (includes invitation to holiday party)
• President's Circle $50,000–$99,999 (dinner with director of the museum)
• Chairman's Circle Patron $100,000 or more

(there's a separate pricing tier with 4 more levels (same benefits, different titles) for younger people (who would tend to have access to less $) -- so there are even a few more levels in addition to these)

Who knows, maybe this could work? Has it been tried? I think many people would sign up to be a Django supporter if they got, say, a t-shirt and it was clear where the money was being spent (again, in keeping with the ideas in #43)

Snowdrift.coop is a work in progress — we have lots of resources/writings that fit this

We propose a real solution to this entire topic. We need to get operating to see how much impact it can have. We have worked hard, done our homework, and are unlike all the other attempts people have been trying. In short, it's a patronage model, but it's one that gets past the freeriding issues via a network style matching pledge, as in "I will chip in a tiny amount each month per how many others chip in with me", and we're 100% ethically aligned with Free/Libre/Open (FLO) values, plan to run as a co-op, and have a political message that is part of expressing why patrons should come join us to fund the commons. Lots more on the site.

So, check out Snowdrift.coop, read about what we're trying to do, and consider helping us get this new model off the ground to see if it can make a real change for the better.

We use the same license, CC-BY-SA 4.0. So, anything you add here we can use and vice versa, as long as we credit our respective works.

Now, here's resources we've already put together that are relevant to your work to compile resources:

• Existing Mechanisms to fund FLO projects
• History and Status Quo of FLOSS funding approaches
• Enormous summary of all the fundraising/crowdfunding platforms that exist that are relevant to FLO projects (we reviewed over 700 sites to make this summary)

Please feel free to simply add our resources as links, learn from them, use ideas or bits, and potentially come join us in building the resources and tools we're building.

Best,
Aaron, co-founder, Snowdrift.coop

Keep on the good work with diversity and education programs

This is clearly not a short-term solution, rather a long-term one but coming up in different threads on this repo, including #14. It seems to me that the funding problem is tightly linked to an awareness problem.

It would emerge that one of the reasons people outside the developer community are not more concerned about funding OSS is because:

• they are not aware what OSS is (ie: people selling gimp on e-bay
• they are not aware how important security in OSS is (large companies want to keep SHA-1 SSL certificates)
• they think creating software is "easy" as in they don't understand the work involved to create quality software (as in your manager doesn't think your team has time to write unit tests or deal with technical debt)

In the light of these facts, I think initiatives like Django Girls, Rails Girls or the BBC micro:bit are good for plenty of reason but are also necessary to educate more and more people to what software actually is and that it takes time and effort to create thins like the game that you just bought for $1 on the app-store or a website.
Since RMS was mentioned in another threat, let me just say that, at the time, it required a lot more knowledge to use a computer, nowadays, a 2 yo can use a tablet, therefore, outside our community, our work doesn't seem as valuable as it used to.

TL;DR; OSS won't get funding from people who don't know how much hard work is being accomplished => let's educate as many people as we can

Maintain a list of FOSS-friendly employers

It would help those of us who want to work on Free and Open Source Software to know which employers hire developers, writers and other roles to work on FOSS projects.

Many of the existing job sites are extremely poor at giving applicants enough information to know what a job requires, let alone give an insight into whether the employees work on FOSS. Partly that's due to a lack of transparency in the recruitment industry and poor tools for searching and filtering results.

Sometimes it's easier to look for promising employers then check if they are hiring than it is to start from the list of jobs available. A list of FOSS-friendly employers would help with that. It wouldn't even require their cooperation - you could post links to pages on employers' sites where they promote FOSS in their working environments.

A funding "wall of superpowers"

Based on a mixing together of some strands in other issues: what about a "funding wall of superpowers"?

Imagine something loosely like the Python 3 wall of superpowers, but where you have a list of companies. Then you have these columns:

• company name
• annual profit
• open source software used (maybe only the main projects)
• percentage net profit contributed back to open source

The strategy is to easily show which companies are contributing back, as a means of peer pressure.
The hypothesis is that companies that stand out as really bad community members might want to protect their reputation and will therefore contribute back. Something like this may already exist, I have not looked around much.

You could add a column that displays the current funding shortfall for the open source projects in question, so it could be quite compelling to see the company profit side-by-side with the open source project funding shortfall. There are probably other metrics even better than this, I haven't thought about it too deeply yet.

There are complications, e.g., some companies contribute employee time, which would have to be costed in order to make a fair comparison against other companies that contribute only funding. This sounds like the kind of thing that some companies which currently make huge contributions would support, as it would represent them in a good light.

Thoughts?

Ads in online docs and/or project website

One way to get revenue is to include ads in the project's website and docs.
For example, each page of Bootstrap's docs has 1 (fairly tasteful) advertisement at the top of the page.

Upside: "Free" money!

Issues:

• Ad blockers
• No matter how tasteful, some (would-be) users will hate any ads just on principle
• Being at least tangentially involved in the odious web advertising industry
• Finding an ad network with non-annoying ads while still offering a decent payout
• This strategy isn't applicable if you don't have online docs or if users don't consult the website/docs frequently enough
• At least theoretically, this creates a perverse incentive to make the software trickier so that users will read the docs more
• I'm not privy to the full numbers, but extrapolating based on my share, even for Bootstrap, despite its popularity and the "here are tons of snippets to copy-paste" nature of its docs, the current ad revenue wouldn't be viable as a sole funding source for the team.

Governmental research funding

An idea I've had knocking around for a while is governmental funding for OSS. Obviously this would be a hard one to manage, especially given the global nature of the projects, but there's actually a pretty strong political case here - investing money in open source projects helps power business in a profitable and growing sector, keeping the costs down for new (and large!) tech companies. Most companies put billions into funding science for the greater good, why not OSS as well?

Below is the content of an email I sent to my local MP (and minister for tech industry) yesterday.

As I'm sure you are aware, software engineering is a multimillion pound business which is growing rapidly in the UK. Many of the small and medium enterprises are built on open source software - tools such as Linux, Git, PostgreSQL, Python, Django, Ruby on Rails and jQuery. All of these projects are currently almost entirely volunteer run and volunteer driven. They are worldwide projects, but many of them have strong presences within the UK community. Personally, I am strongly involved with Django - a python web framework used to build sites such as Instagram and Pinterest, as well as many sites for NASA, Disney, Google etc. I have also recently seen an uptake in use of the project to build sites in the scientific community. For example, I was working with Oxford University on a STFC funded project giving visibility to atmospheric satellite data. This site was built using Django, and as such saved hundreds of hours of developer and scientist time on the project. Looking more at education, the huge success of the Raspberry Pi and the BBC Micro:bit would not have been possible without open source technology. I trust you can see the value in these tools.

Open source software is in a crisis. It seems every week I am hearing of volunteer developers who are stepping back from their projects, burning themselves out trying to fulfil the needs of the tech community in their spare time, normally around a full time job of their own. In many cases this can leave critical tools used by thousands of businesses completely unmaintained, vulnerable to security attack and eventually dying off as they don't stay up to date with the community. I would like to open a debate around governmental funding of this vital infrastructure. Research councils UK has an annual budget of £3billion - just 1%, just from the UK, would revolutionise the story for these projects and open source software in general. The stronger open source is, the faster tech companies worldwide and in the UK can innovate and develop.

The excellent gov.uk site is built on these open source projects, and the forward thinking which created the team who built it has given the UK government a strong international reputation for understanding how to utilise modern software engineering. This could be a fantastic opportunity to further enhance our international reputation as leaders in the tech community, attracting more businesses and talented people to move here.

This is obviously a bit of a long shot pipe dream, and would require political campaigning and effort to get it to happen. However, it has a lot of strong points. For example:

• There would need to be a governmental body who decides which projects get grants. These bodies would be able to easily set governance requirements for the projects in question - you must have a registered organisation, with an elected board, fair processes etc etc. This leans towards larger projects such as the DSF, PSF etc rather than smaller ones, but funding could be distributed to "community" projects like DRF by the DSF
• The amount of potential cash flow is ENORMOUS. As it says above, the combined body research councils UK has an annual grant budget of £3BILLION, and that's just one relatively small country. Across the EU, Australia and the US there must be an annual publicly funded science budget pushing £100billion. 0.01% of this would make a big difference to OSS.
• Political pressure could be put on companies to match funding from governments
• Can be politically spun as creating jobs, supporting vital infrastructure in the digital world, supporting research, investing in future businesses and probably several other ways I've not thought of

Biggest drawback? Involves dealing with politicians ;)

A view from the other side - the commercial interests

First a plea - please don't misunderstand me. I believe in the fundamental issue here - once Open Source projects grew beyond the 1- and 2-person garage projects, it became inevitable that some form of sustainable cash flow would become a requirement. I'm not trying to disparage the need - just to provide a perspective on some issues that I don't otherwise see covered here. This perspective comes from working as a "corporate drone" for 35+ years in very traditional, fundamentally conservative business environments. My opinion, for what it's worth, is that any model will need to address these issues if it's going to be successful.

1. Open Source - for the most part - made its way into the corporate environment via the techies, able to sell it to management as a lower-cost solution to proprietary products.The lower cost wasn't just the price of the software itself, but also the ancillary expenses involved in accounting, license management, acquisition management, etc. Those overhead expenses are, on a corporate hourly basis, often significantly higher than the cost of a commodity product. Force a corporation to go through that, and you'll have people searching for alternatives again.

2. For just about every significant Open Source package, there's at least one viable alternative. Need to pay (or donate, or contribute) to use Linux, but don't want to? Fine, there's always the flavors of BSD available. As one of the other issue authors pointed out, it becomes a very real issue of "competitive advantage". A company intentionally incurring an expense avoided by others is placing themselves at a real disadvantage.

3. Licensing issues abound. As Linus has pointed out in the past, Linux itself is encumbered by the hundreds of different people who have all contributed code with the understanding that it would all collectively be distributed under GPL 2. It's a practical impossibility for Linux's license to be changed at this point. (I do recognize that there are projects that require contributors to sign over their rights to an organization or foundation - making it easier for them to change their license. But...)

4. Distribution issues are real. I don't know how true it is any more, but when I started using OSS, the packages I used generally were those distributed by the distros. I would occasionally build packages on an as-needed basis, but if I had to make a decision between a package supplied with the distro, and one that I had to build myself, I would need a compelling reason to go the DIY route. (And that's going back to my first installation of Yggdrasil more than 20 years ago.) From a corporate perspective, staying with a managed source is considered "safer" that "side-loaded" builds. My point here is that any funding model needs to be sensitive to the common distros, and their ability to package and distribute this software.

5. Education and influence. Most of the techies I know in the corporate world actually are sympathetic to this need. But the techies don't control the budget or the funds. We (and I very much include myself here) need to do a better job of making the business case that this software has significant strategic value to the corporation and needs to be supported - even voluntarily. The problem is, that if project "X" goes dormant, the software built on "X" will still run - generally for long enough for an alternative to be found. That means that there's little urgency or incentive to be pro-active concerning project support. (Software in corporations does tend to stick around for a long time. I know a place that still has 3 servers running that were built in 1998 with 64MB RAM and an 8 GB hard drive, that are still running today as file and print servers.)

Solutions to these? Unfortunately, I have none - but then I haven't lived this problem like many of you here to have really thought about it.

I agree in principle with the issue author who said that the developers need to make contractual arrangements - but not for 20% time or anything else like that. Either the corporate developers need to require their companies to support the projects, or else require salaries that allow them to make the appropriate contributions. Again though, the problem becomes one of competitive advantages of those who participate vs those who don't.

Playing up the role of being a good "Corporate Citizen" may also be a part of this. Advertising - make it prominent in the projects themselves who is supporting you. (You could go the "Nagware" route. Build "watermarks" or other identifying information into your official build. Nothing truly obnoxious or disruptive - but visible somewhere. Charge for an official build of an unmarked version. Sure, people would still have the ability to clean it up themselves, but most won't want to bother doing that for every release / update.)

What I don't see of value are the suggestions along the lines of selling support contracts, training, or other ancillary services. If your core objective is making "X" better, any time you spend doing anything other than working on "X" is a net loss. All you've done is changed the business you're in to those other services, and you're back to working on your original project as a hobbyist effort.

Finally, any real movement in this direction needs to be significantly larger than just a handful of projects. The solution - if it's going to be truly effective - needs to have very broad support from the OSS communities. And at that point, it might become necessary or desirable to create an umbrella organization like an ASCAP that would be capable of supporting an effort like this.

Working around the edges

In the Laravel community we've seen a number of business initiatives work pretty well.

Taylor Otwell has launched a few fairly low touch SaaS apps around the Laravel ecosystem which allow him to work full time on Laravel without spending all his time on the businesses.

• Forge - https://forge.laravel.com
• Envoyer - https://envoyer.io

Jeffrey Way has his training site, https://laracasts.com which is an invaluable community resources and makes enough to allow him to do it full time and give back in multiple ways to Laravel.

At UserScape we run https://larajobs.com which lets us sponsor conferences, contribute financially to many of the Laravel community sites via 50/50 revenue sharing on job listings.

Eric Barnes runs https://laravel-news.com a community news site that is supported via sponsorship and membership.

None of these businesses are going to be fortune 500 companies, but all make enough money to allow direct or indirect support of Laravel and the surrounding community.

Training, jobs, community news, software that supports directly or indirectly the main OSS product are all ways to help financially support OSS.

"Pro" licensing

It's been suggested that all open source needs to do to get money out of enterprises is to send them an invoice.

Is it really just that simple? If you're running Project X, can you "sell" "Project X Pro", which is exactly the same project, but with an invoice attached?

Goals and models

Can you take a poll on Github somehow? It occurs to me that you can come at funding open source from a bunch of different perspectives and I wonder which people here want to accomplish:

1. Create a project and get paid to work on it.
2. Create a project that other people will manage to be paid to work on.
3. Get paid to contribute to open source in my current job.
4. Get a new job working directly on open source.
5. Pay other people to work an a project I care about.
6. Create a project as the basis for a startup company.
7. Create a project as the basis for a non-profit organization.

If you know which category you are in then you can decide which role models to pay attention to e.g. Linux, MySQL, SQLite, Mozilla, PostgreSQL, nginx, Inktank, and so on.

Create an endowment (for specific, known expenses)

The Stanford Encyclopedia of Philosophy (SEP) is volunteer driven but has ongoing costs, just like Django. It seems to have succeeded in raising money to support itself via an endowment. One feature of this endowment is interesting, if the SEP ever shuts down, those who gave money to the endowment will receive their donation back. Moreover, I think interest from the endowment can only be used to pay for a specific range of things. Both these features get at what @jacobian is talking about in #43: donors need to feel confident that their money is being spent effectively. Endowments where the range of spending is restricted to expenditures of obvious utility are one established way to address this concern.

Details:

• http://sca.jiscinvolve.org/wp/portfolio-items/stanford-encyclopedia-of-philosophy-building-an-endowment-with-community-support-stanford-university-california-usa-ithaka-case-studies-in-sustainability/

Coverage:

• http://qz.com/480741/this-free-online-encyclopedia-has-achieved-what-wikipedia-can-only-dream-of/ (goes into some detail about the endowment)
• http://www.neh.gov/humanities/2011/januaryfebruary/feature/homepage-philosophy

Resources

Talks & articles

Money, Money, Money - Writing software, in a rich (wo)man's world by Russell Keith-Magee
Funding OSS - Cory Benfield

grsecurity action

https://grsecurity.net/announce.php
Due to continued violations by several companies in the embedded industry of grsecurity®'s trademark and registered copyrights, effective September 9th 2015 stable patches of grsecurity are being made available to sponsors and commercial support customers only.

Central non-profit to collect and distribute funds

Reading about the various ideas here "with teeth," they all sound like they would be culturally unpopular, and difficult to implement. To my mind, there's plenty of good will out there. If we can encourage the idea that companies should voluntarily support OSS, and make it simple for them to do it, then we can start some money flowing.

What I'm picturing is a single organization that could collect money on behalf of projects. Companies could make a donation, and indicate what member projects they use. One simple way to indicate that is to upload a requirements.txt file :)

Some divvying-up algorithm would be needed, but roughly speaking, the more money that came from companies using Project X, the more money Project X would be entitled to. (BTW: Project X could in turn donate some of their proceeds to the projects they use.)

Lots of big companies make charitable donations for no other reason than the tax write-offs and image building they provide. These donations would be no different. If we can publicize the donations that companies make, it will encourage other companies to similarly donate.

And a simple economic argument can be made ("You paid X for New Relic? Isn't Django worth at least Y?") We can make some suggested guidelines for donations also.

Maybe I'm an optimist, but I believe companies would want to support OSS projects if they had a simple way to do so. Today, they can donate to the PSF and DSF, but what about the rest of the software they use? If there were one place that would cover all their OSS funding, they wouldn't have to chase down all the ways to donate money to all the long-tail projects they use.

(Sorry if this is duplicative of other ideas here, I read the ones that seemed similar.)