Why Funding Open Source is Hard

Over the past four months, I have had the pleasure of building a company focused solely on bringing funding to open source projects. Code Sponsor has gone from a simple proof of concept to a viable OSS sustainability solution.

Developer Earnings in USD ($) by Month

On November 21, I decided to shut down the platform. The goal of this article is to share what I have learned so that we as a developer community can continue to find and build upon solutions for sustaining open source.

Funding Categories

How do we change the developer mindset towards funding open source?

Nadia Eghbal is a tremendous advocate of open source sustainability. She maintains a list of open source funding options called the Lemonade Stand. In the list, one can find an extensive list of the different ways developers can find funding for their open source projects, along with the pros and cons of each.

Almost every solution provided on the lemonade stand falls into one or more categories:

• Donations. Ask for money from others to support the project.
• Support. Charge for support related products or services.
• License/Usage. Charge for usage of the project.

Let’s break it down further and learn what is involved in each grouping.

Donations

Asking for donations is by far the simplest form of generating funds. It doesn’t require the developer to change their existing behavior. Many projects have found great success by opening themselves up for funding through Open Collective.

Other projects have found success by utilizing a direct payment approach. Patreon, Gratipay, and Liberapay allow developers to add a “Pay Me” button to their project’s README. BountySource and Gitcoin focus on funding specific issues.

What is required to achieve significant funding through donations?

Raising funds through donations requires a lot of fund raising and building awareness. Sean T. Larkin shared his story of how Webpack reached $400k/year in funding. It was not easy. It was not quick.

Unfortunately, funds don’t start flowing in just by joining Open Collective or by adding a Patreon link to your README.

Kent C. Dodds has had a donation button on his repositories for over a year. He let me know that he has made a total of $0. Zilch. Why? Because those donation buttons are asking for money from other developers, who are also asking for money on their projects. It’s as ridiculous as having a hundred developers stand in a circle and pay the person to their left $1.

Many of my projects are highly impactful and widely used, but of those which I could accept donations, they’re relatively small and/or development is essentially done. Making shirts, hosting meetups, or even doing further development on them is neither reasonable or necessary. At the same time, I think devs should be compensated for the value they create.

- Kent C. Dodds

Donations work for some projects, but for the majority there is little chance of raising any form of sustainable funds unless the developer becomes a public evangelist for their project.

Support

Unpaid support is a given when it comes to open source. Developers find themselves answering questions, handling issues and providing overall support out of the goodness of their hearts and their desire for the project to gain user adoption.

However, as the project grows in popularity, it also requires more support. Some developers decide to monetize their efforts through books, merchandise and paid support.

However, most developers do not go this route. In reality, many smaller open source projects would not benefit from a support role. And if they aren’t large enough, paid training and books are rarely in demand.

License/Usage

Charging for usage of open source through licensing is often the most lucrative approach to open source. An excellent example of this is Mike Perham’s Sidekiq. Sidekiq is a free open source solution, but by offering a pro and enterprise version, the project pulls in over $1mil/year.

The primary question that a developer must ask themselves when deciding on following this funding path is “Do I want to make this project a business?” If the answer is yes and the project has enough traction, this approach is terrific.

However, most developers aren’t business savvy. They prefer building over spreadsheets and marketing.

Are you willing to change roles?

Now that we’ve broken down the solutions into three main categories, we can begin to see a pattern. This pattern also defines the reason why open source sustainability is still a problem today.

The existing path to better funding requires developers to change their role

To increase financial support for open source projects, the developer must shift their role from being a contributor to a support role, and eventually a business owner. The greater the change, the greater the potential of funding.

It’s my strong opinion that developers should not have to trade in their passion in order to find substantial funding for their open source projects.

Advertising on Open Source

Code Sponsor was born from the idea that it’s possible to provide developers with sustainable, scalable funding through the means of ethical advertising. It is is a mashup of Carbon Ads, Open Collective and Read the Docs (with a hint of grassroots marketing demonstrated by Wes Bos).

Two examples of open source projects finding success through advertising are Read the Docs and Hoodie.

The concept is simple.

There are thousands of companies that market directly to software developers (see the Heroku addon list). Each has a marketing budget. Many, many developers visit GitHub almost every day to read the documentation and contribute to open source. I knew that if I could get the developer to promote the company’s product or service in the form of an ethical ad, the company could pay them instead of other channels such as Google.

This idea has three things going for it:

1. The funding is scalable. As long as the company is seeing a return on investment, they will invest more.
2. The developer does not need to change behavior. They could start getting paid by adding one line of code to their README.
3. Anyone can participate. Because the developers were being paid on a per-click basis, any project could receive funding (no matter how small). The popularity of the project is what self-governed the amount of money they would receive. This is the key to broad-scale funding.

I resolved to ensure that all messaging placed on GitHub were:

• Unobtrusive — the banner would appear like the docs, but be different enough not to be deceiving
• Relevant — The message must be something developers would be interested in (based on the project’s programming language)
• Ethical — I did not want to track ANY personal information nor place cookies for re-marketing. I followed Eric Holscher’s Ethical Advertising guidelines

I threw together a simple Rails project and launched with one developer and myself as the sponsor.

Rapid Growth

In four months, Code Sponsor has grown relatively rapidly. Here are some of the charts I looked at every day. This one shows the total number of developers in the system.

Total Developers on the Code Sponsor platform

Here you can see total impressions over the 4-month span. In November alone, I saw over 3.6 million impressions. It should be noted that we never tracked anyone, even anonymously.

Total Impressions by Day

Developers received funding on a per-click basis. As you can see, there was a steady growth trend.

Link Clicks by Day (excluding bots, duplicates and fraud)

Developer distributions has increased month by month. In November of this year, Code Sponsor generated $4,781.80 in funding for open source.

Here are the final numbers (as of December 3, 2017):

• 1,471 repositories
• 95 websites
• 7,110,890 total impressions
• 35,544 total clicks
• $24,370 total revenue (although I refunded $1,500 of this)
• $23,474.55 total click income
• $12,387.65 total profit
• $11,086.90 total distributions to developers
• $1,051.55 total credits given to sponsors

Here is a screenshot of my dashboard. This data is for the full life of Code Sponsor.

Code Sponsor Internal Dashboard

Sustainable, scalable funding for open source is not difficult

I firmly believe that Code Sponsor has demonstrated a way to fund open source in a broad, scalable, and sustainable way. This can be accomplished by providing an advertising channel to companies where the funds directly contribute to open source. It was not depending on charity from others. It was a business transaction between sponsors and developers. The sponsors saw a return and the developers got paid to continue doing what they love without the need to change.

Mike Smith, Head of Growth at Rollbar, told me that Code Sponsor (in some months) provided more customers than any other marketing channel.

Code Sponsor was a success.

What makes funding open source hard?

I think the difficulty comes down to two key points.

1. Developers don’t want to change roles

I believe the majority of open source developers want to continue building open source. They do not want to take on a support role, nor build a business around their project.

Unfortunately, without change, generating funding will likely be a fruitless endeavor.

2. GitHub doesn’t allow or provide dynamic sponsorships

The primary reason that Code Sponsor worked so well is because everyone could participate. We had projects ranging from 0 stars all the way to 70k stars. This was only possible through dynamic sponsorships. In other words, sponsored messages that can change based on budgets and sponsor qualifications.

I love GitHub. I think they are a fantastic platform and company. I also empathize with their decision to remove Code Sponsor’s banners from their platform.

My honest hope is that they consider the good parts of Code Sponsor and either integrate them into their platform, or allow Code Sponsor to continue serving dynamic images in the README’s.

Code Sponsor is shutting down the platform

I appreciate all who supported & helped me along the way. Sustainability is an important topic & I hope we can continue the conversation & work together to find solutions.

I sent out an email on November 24 letting everyone know that Code Sponsor will be closing down.

I had considered that there might be a time when GitHub said “enough is enough” and had planned out the next steps for this scenario. It would have been easy for me to hide banners on GitHub and continue showing them on sites that consumed the README.

Payable Clicks by Domain

Here you can see a graph of the referring sites for traffic that leads to clicks. 53.49% of all revenue generating traffic is from GitHub. The 16.73% is from the iframe website widgets. 11.99% came from browsers with ad blockers enabled.

After reviewing this data, I realized that no matter how hard I tried, without GitHub’s support, the goal of helping sustain open source on a broad scale was not possible. They were and still are the key to solving this problem.

What now?

Code Sponsor is such a huge part of my life. I don’t want to stop helping developers.

Starting in January, Code Sponsor will take on a new role of matchmaker between sponsors and developers. Funding will be provided at a flat monthly rate. Code Sponsor will represent the developers as an “agent” and negotiate the highest rates on a month-by-month basis. The goal is to provide the highest amount of funding to the open source project. The developer will receive 85% of the sponsorship revenue.

As for me, I am going to step away from the entrepreneur lifestyle. I miss my family. The new pivot will not require much of my time. I’ve put in my notice at my current job and am hoping to find a new role come January. If you are hiring, I would be interested in talking with you.

Eric Berry | Professional Profile | LinkedIn_View Eric Berry's profile on LinkedIn, the world's largest professional community. Eric has 2 jobs listed on their…_www.linkedin.com

If you want to reach out to me, the best way is via Twitter (either @coderberry or @codesponsor).