{{announcement.body}}
{{announcement.title}}

Open Source Software Is Eating Developers: The Complete Guide to Survival, Sustainability, and Monetization

DZone 's Guide to

Open Source Software Is Eating Developers: The Complete Guide to Survival, Sustainability, and Monetization

Technology seems to be kinda hungry these days, doesn't it?

· Open Source Zone ·
Free Resource

“Software is eating the world”…and Open Source Software (OSS) is eating software! According to Black Duck, 78% of 1,300 companies surveyed recently confirmed that their products were built on Open Source Software.

This is music to the ears of an OSS developer…but catchphrases don’t pay the bills. Unless you have a steady source of income and enough free time to maintain your project, the project will eat you alive.

The bad news is that there is no silver bullet. There are many valuable software tools that are struggling because they are not supported by a commercial model (remember OpenSSL Heartbleed?).

The good news is that there is a wide range of “sustainability models” available to OSS developers, and this article will outline them all, from the familiar to the outlandish.  The aim of this article is to help you broaden your thinking and awareness of possible approaches so that you can craft something that works for you.

Image title

We will make a distinction between “sustenance” models designed to keep your project (and you!) alive, and “monetization” models designed for a company’s growth and financial success.

If you want even more in-depth information, have a look at this comprehensive training course on OSS from a business perspective.

OSS Sustenance Models

  1. User Donations. The simplest model. As you already know, making this work for you in a truly sustainable manner is a low-probability event. This is basically a lottery so you’d better have a Plan B. Read on.
  2. Employer Support. Open source work builds your portfolio and helps you get employed. That is the first element of this tactic. But that is self-defeating if the job doesn’t afford you any time to continue working on your project/vision. So, the second part of this approach is to convince your (prospective) employer to support the project, either by way of time (e.g. allowing you a specific number of hours to dedicate to the project) or money (random example: pay for a “supported by” logo on your project page, or hosting on servers paid for by the company). The important thing here is that the employer’s willingness to afford you some flexibility or support should be a key determinant of your choice of employer. The issue has to be tabled and discussed before you put pen to paper.
  3. Employer Adoption. This involves becoming an employee of a technology company that markets products that can use your software as a dependency. Take the example of the Python library urllib3 that was developed by Andrey Petrov: Hewlett Packard Enterprise (HPE) employs people like Cory Benfield to work on urllib3 because HPE is quite dependent on Python. This tactic involves you combining the roles of Andrey (as the original developer) and Cory (as the maintainer), and then finding an employer that is a large user of OSS and also a potential user of your project.
  4. Crowdfunding. People like Andrew Godwin have raised significant money on Kickstarter. Crowdfunding is viable but it will not resolve how you will deal with ongoing operational expenditure far into the future. There is a lot of time and effort that goes into setting up a successful crowdfunding campaign.  You can't assume that you will have the time and energy to run a campaign every time you run low on cash.
  5. Patronage. This is what platforms like Patreon and Gratipay exist for. Your “patrons” are entities willing to pledge small amounts every month as a sign of support for your work. In practice, most patrons tend to be developers themselves and they don’t have much to pledge. "Beer money, not rent money." But if you are willing to put some hard work into reaching out to a wide number of potential supporters (usually via Twitter), this can go a long way in reducing your ongoing expenses. Here’s an example, and there is an additional list of sources here.
  6. Parentage. Sometimes only the mothership can give you safety. The Mozilla Foundation, Apache Software Foundation, and the Software Freedom Conservancy are all examples of organizations that take OSS projects under their wings from time to time. There are hundreds of examples including JQuery (supported by Mozilla) and Git (supported by SFC). This is a tough one because these supporters prefer to support projects that already have some traction within the developer community.
  7. Partnership with a University or Research Agency. Many OSS tools originated in academia (R, LLVM, countless MIT-originated projects, etc), and universities are consistently strong supporters of OSS. The idea here is to find an ongoing (or proposed) academic project into which you can wrap yours, such that a large part of the cost burden will be taken off you. Obviously, this applies only to relatively technical/scientific projects.
  8. Grants & Awards. The Mozilla Open Source Support (MOSS) Program has a pool of funds for OSS projects and so do a number of other organizations — review this list.
  9. Trial Licensing. Here commercial organizations can use the software but have to pay for it after a certain amount of time (usually 90 days). Basically a try-before-you-buy model for OSS. License Zero has built a business model around helping developers set this up.
  10. Open Source Marketplaces. Platforms like Tidelift and Open Collective seek to collect funds from enterprises and distribute the funds to the OSS developers. If your project can qualify, these can be very good low-effort alternatives.

OSS Monetization Models

Here we have "proper" business models. Obviously they require more focused effort and would usually involve at least one person focused purely on business development.

  1. Consulting. Note that this is not the same as “Support” (see below). Here the revenue model tilts heavily towards business-facing consulting and not technical support. The OSS vendor combines the technical credibility gained from their OSS efforts with an understanding of how to build business solutions. A successful example is GlobalLogic.
  2. Charge for Support. The familiar model (without Consulting). Example: Red Hat.
  3. Dual License. One license deals with a free OSS version that cannot be redistributed, while there exists a premium version that is also OSS and can be redistributed but must be paid for. Example: MySQL.
  4. Embedded. In this model, the OSS is a key component in a larger product set. The company in question is not selling the OSS per se, but is using the OSS for much faster time to market and as a means to deliver the entire service at a much lower price point than would ordinarily be the case. For example, Neoteris was able to bring a new class of network devices to market months ahead of larger competitors by using Linux as an embedded OS.
  5. SaaS. “Rent” the software, don’t sell it. There are a number of advantages to this model and that’s why it is fast becoming the dominant approach.

Conclusion

Making a living off Open Source Software is not so simple if you’re an independent developer, but it is doable. 

What is important is to do enough research early enough in the process (on the ideal monetization/sustenance model for your product, and then on funding sources aligned with your model) and to start the work involved in generating the funds so that the money starts coming in early enough in the process to keep the lights on. Unfortunately, you can’t spend 100% of your time developing software while hoping that the required funds will magically show up.

Hopefully, this article has given you enough pointers to get you there. Good luck!

Topics:
open source ,open source business model ,open source licensing ,open source monetization ,monetization

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}