Dirk Riehle's Industry and Research Publications

How to think about a dependency on commercial open-source software

Another day in open source land, another vendor relicensing away from an open source license to a source-available license. What was new for me this time, however, was that Apache Flink, a community open source project, had a dependency on Lightbend’s Akka, the commercial open source project that relicensed.

This is surprising, because in my book the general rule is that community open source code should only depend on other community open source code. Community open source shouldn’t surprise its users with a dependency on commercial open source.

How to think about using commercial open source (like the old Akka) in your project and products?

There are clear benefits: Commercial open source, backed by a vendor, is often of high quality and as long as it is open source, it is free!

I recommend you view using commercial open source, in particular if owned by a single vendor, as a short-term gain and long-term liability. It is like taking on a loan, to use a common financial analogy: You get a boost or benefit now, by using high-quality software for free, but you will eventually have to pay for it.

Payment day is when the vendor decides to tighten the screws. For this current third generation of commercial open source vendors, it typically means to slow or stop the open source development, for example by relicensing.

Your payment can be to

  1. become a customer and pay the licensing fees, or to
  2. migrate away to an alternative solution, or to
  3. start maintaining the software yourself.

Of course you can combine 1. with 2. by grudgingly paying while migrating away.

Unlike a traditional financial loan, a commercial open source liability has a hitch: You don’t know when payment day will come around, i.e. when the vendor will try to tighten the screws. You can make guesses about where the vendor’s product is in terms of maturity and market saturation, but you won’t get an exact date.

Hence, if you decide to introduce a dependency on commercial open source like building on a commercial open source platform, it will take significant discipline to keep that liability in your mental books and be ready to repay the loan when payment day comes.

On a related note: I can help you with strategically managing these dependencies, as a user, and designing a business strategy that will not upset your community, as a vendor.


  1. […] but chilling nevertheless, because they should have known better. With a fair bit of complaint, a well-known Apache project decided to remove its dependency on an underlying vendor-owned open sour… because the platform relicensed away from open source. Here, the open source project had assumed […]

  2. […] longer explanation can be found on my professional […]

  3. […] longer explanation can be found on my professional […]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.



Share the joy

Share on LinkedIn

Share by email

Share on X (Twitter)

Share on WhatsApp

Featured startups

QDAcity makes qualitative research and qualitative data analysis fun and easy.
EDITIVE makes inter- and intra-company document collaboration more effective.

Featured projects

Making free and open data easy, safe, and reliable to use
Bringing business intelligence to engineering management
Making open source in products easy, safe, and fun to use