5 min read business

0x00D - Open-source Business Models 💸

0x00D - Open-source Business Models 💸

Should you open-source your product or not, and how do you make money out of it?

Brought to you by:

Dodgeball - a developer-centric way to block fraud in your app w/ a single integration.

P.S. Dodgeball is our first sponsor! I spent 13 hours on this issue, so their help is amazing, show them some love :)

TL;DR:

  • Problem: Developers easily adopt open-source, but it’s unclear how to monetize an open-sourced solution.
  • Solution: Using an open-source business model and keeping it sustainable while maintaining high developer adoption.
  • In Sum: There are several exciting open-source business models that you can incorporate. Just make sure to do your research and strategize before committing to one.

How does it work? 💡

There are several business models that an open-source tool/company might want to leverage:

  • Open-core 🥝 - The main product is open-source; additional enterprise offerings (services/extensions/performance/compliance) are monetized.
  • Services (i.e. “Active” Revenue) 🧑‍🏭
    • Hosted (SaaS offering) - commonly included with a relevant license (like AGPL).
    • Support-based - some use an SLA.
    • Distribution Model - Building a cohesive product from a set of open-source components.
    • Professional services.
  • Passive revenue 🌾
    • Ad-based.
    • Paid development (see bountysource.com) - waiting for features until someone pays for them.
    • Donation-based (can include merchandise).
  • Legal ⚖️
    • Re-licensing - Allows the buyer to distribute their code without open-sourcing it.
    • Dual-license - The commercial license takes place when the buyer deploys the software at scale; it is generally sold as a "community version" and an “enterprise version.”
    • Certificates and trademark - the ability to use the name and trademark of the software.
  • Marketing asset 📺
    • Note that some companies don’t make money from the open-source offering but just use it as a marketing and crowdsourcing (community contributions) avenue, which is a totally legitimate reason to open-source something.

Licences?

Be sure to check out the digest on open-source business-centric licenses:

Who is this for? ✅

ℹ️
I decided to change this category from Outcomes (which was a bit ambiguous) to “Who is this [trend] for?”
  • Developer-facing companies and products.

Why? 🤔

  • Marketing: Having a successful open-source product can drive a lot of organic awareness, traffic, and community engagement which becomes almost self-sustaining at a certain point.

    • It adds the developer equivalent of “street cred” if that’s missing from your brand image.

  • Adoption: Developers are more open (get it? :)) to using an open-source tool (assuming the license & usage limits are clear) than a closed-source one. An open-sourced solution:

    • Enables on-premise customers.
    • Mitigates the fear of lock-in - the buyer can always host it (again, assuming the model allows it).
    • If the buyer misses a feature or has a bug, they can always extend the code base.
    • Enables standardization (like how Docker became the container standard).

  • Free distribution: No need to set up a self-service / SaaS dashboard, and the like. Users download, install, and run your open-source product themselves. Why waste resources on free users anyway?

  • Hiring: A great way to find hiring opportunities is by contacting contributors directly. See companies hiring from open-source avenues.

  • Unlimited feedback: The community will let you know when something doesn’t work or a new feature is needed.

Why not? 🙅

  • Confusing: Frustrating contributors with the distinction of free and paid (which needs to be very clear).
  • Legal gray area: Many open-source business models require a special license, which can be ignored or take you [the seller] into an inconvenient legal battle. Having an ambiguous license can also decrease user adoption (especially enterprise users).
  • Letting Go of Your IP: You need to be OK with open-sourcing your product, and all the benefits this gives your potential (and actual) competitors. Unless you know that you will execute and achieve market adaption better than them, this is a genuine concern.
  • Distractions: Parts of the community might ask for features that aren’t relevant or helpful for your business or product, especially if they are not paid customers.
  • Overhead: Managing the community, handling issues, and implementing processes like a CLA might not be worth the hassle.
  • Conflict of Interest: With some business models (like open-core), you might be directly competing with your open-source offering (e.g. deliberately not open-sourcing a feature), paving the way for competitors to open source your additional features — See example.
  • Bad Press: If your open-source offering doesn’t bring concrete value, it could be seen as inauthentic and create negative marketing - the opposite of what you want.

Tools & players 🛠️

For “players”, see the “Who uses it? 🎡” section below.

🤠
My opinion: Make sure to figure out your open-source strategy from the get-go, not to create antagonism by backtracking and pissing off the open-source community. Make sure your open-source offering is really valuable; developers are notorious for detecting BS. In most cases, I would consider open core or marketplace-based approaches (see the “Forecast 🧞” section below).

Forecast 🧞

  • Market adoption: With more and more novel open-source business models, I can see how the trend continues and creates a big slice of companies that incorporate open source with minimal downsides.
  • Maturing ecosystem: I can see how there will be more consultancies and tools to help companies navigate these unique business models.
  • Sponsors via GitHub: GitHub recently launched Sponsors, a way to contribute to open-source projects directly. I can see this taking off as GitHub is the de facto open-source hub; add to that the ad inventory mechanism it provides at the side of each repo, and I see a bright future in that direction (mainly from businesses and not direct contributors).
  • Compliance push: Because of GDPR and the like, some companies are moving from SaaS offerings into their own self-hosted infrastructure, which might increase the market adoption of on-prem open-source offerings.
  • New contributor incentives: As more and more companies move into the open source monetized zone, I can see that contributors are less likely to contribute freely. I suspect to see new creative approaches to incentivize contributors (swag, payments, remote work, fame?).
  • Marketplace-based model ✨: I haven’t seen this model become popular with many open-source players yet since only a few big players are utilizing it. See Android → Google Play Store. I suspect seeing an increase in usage of this model with smaller players. A company will open-source a base product and create a hosted proprietary marketplace for that base product. The revenue will come from commissions of paid extensions (in the marketplace) and listing fees. Hit me up if you want to brainstorm this for your open source product :)

Who uses it? 🎡

Extra ✨

Additional information related to the subject matter:

Thanks 🙏

I want to thank @TomGranot (an amazing DevRel and friend ❤️), @shar1z (DevRel star and co-org of Dev Community TLV).

EOF

(Where I tend to share unrelated things).

I stumbled upon this lovely website that lists all the free tiers we can use as developers - I hope it helps someone out!

Agam More

Agam More