DEV Community

Cover image for The Unintended Consequences of Open Sourcing Software
Steve Sewell for Builder.io

Posted on • Edited on • Originally published at builder.io

The Unintended Consequences of Open Sourcing Software

Open source is pretty great. It's given us some of the most important tools we use every day — Linux, VS Code, React, and more. But there's a tricky situation that keeps coming up:

What happens when someone takes open source code, adds a few features, closes it off, and starts charging for it?

There is nothing illegal about this at all, and it happens all the time. But, does that make it right?

And if this keeps happening, will there be more open source projects adopting more prohibitive licenses like we’ve seen in some major projects recently?

If so, will this harm open source communities and innovation because a subset of people exploited projects for profits, just because they could?

The Cursor Situation

Let's talk about Cursor. They took VS Code (MIT licensed), added some AI features, and now charge $20/month for it.

They now have full control over the software and their users. If they want to make it so you can’t use other AI tools, like GitHub Copilot (probably the main thing that is creating monetary potential for VS Code), theres nothing stopping them.

Don’t get me wrong — Cursor's AI capabilities are great. It goes beyond GitHub Copilot, completing tasks end-to-end in one go. I use it, and I love it. But I’ll admit, that doesn’t make me feel any less “dirty” about using it.

When I pay Cursor $20/month, I’m paying for 99% VS Code with some AI add-ons. And all of that money goes to Cursor, not to the team who wrote most of the software I am using.

Is this right? I honestly don’t know.

Pie chart showing 1% cursor's code and 99% VS code

Sharing is caring. Or is it?

This highlights a fundamental tension in open source.

On one hand, licenses like MIT allow this kind of use. They're designed to give developers the freedom to use, modify, and distribute the code as they see fit.

This openness has been a driving force behind much of the innovation we've seen in software over the past few decades.

On the other hand, it can feel unfair when someone profits directly from work others gave away for free. The original creators and contributors put in time, effort, and usually real money with the intention of benefiting the community, not to provide free labor for a commercial product.

I've been on both sides of this. I once open sourced a project under MIT, only to have someone fork it, add minor improvements, close-source it, and start selling it. They even became a top app in a popular app store.

And I'll be honest, I was a little annoyed. I had given everything away for free hoping to make this a community project that anyone could contribute to and improve upon, and the first team to decide to make improvements, decided they will do it for their benefit and add nothing back.

But hey, in a moment of optimism about the world, I MIT licensed the software, so technically this is my fault, right?

Flow chart showing commercial vs free software use

The "it's allowed, so it's fine" view

Some argue that if the license allows it, there's nothing wrong with profiting from open source code. This view emphasizes the intentional choice made by project maintainers when they select a permissive license like MIT.

The argument goes that VS Code chose MIT knowing this kind of use could happen. If they didn't want it, they could've used a stricter license like GPL. By choosing MIT, they're implicitly saying they're okay with this kind of use.

Proponents of this view might point out that without such permissive licenses, we might not have many of the innovative products we have today. Cursor itself likely could not exist if VS Code had a more restrictive license.

This view is a 100% valid, but also feels like you're saying, “if your friend gives you a gift and you immediately turn around and sell it, there is nothing illegal or wrong about that." Which is true, but in that situation, you wouldn’t be my friend for much longer.

The "legal doesn't mean right" view

On the flip side, others argue that just because something's legal, doesn't make it ethical. This view emphasizes the spirit of open source, not just the letter of the license.

The argument here is that open source is built on a foundation of community contribution and mutual benefit. When a company takes an open source project, adds a few features, and then charges for it without giving back, they're exploiting a community for their own gain.

Quadrants wondering if profiting without contribution is legal but unethical

This issue isn't unique to software. In the world of literature and film, we see similar debates. Take the example of Dune and Star Wars. Star Wars borrowed heavily from Dune, to the point where Dune's creator Frank Herbert said, "I'm going to try very hard not to sue".

While what George Lucas did wasn't illegal, some feel it is at least a little bit questionable.

The "this drives innovation" view (and its limits)

Some argue that building on open source drives innovation. Each project builds on the last, creating a chain of improvements. Take the evolution of JavaScript frameworks:

  1. jQuery simplified DOM manipulation
  2. Backbone added structure for larger apps
  3. Angular introduced two-way data binding
  4. React brought the virtual DOM and component-based architecture

Each framework learned from and improved upon its predecessors, all while remaining open source.

Flow chart of progression of frontend frameworks

But there's a catch. When companies take open source projects, add features, and then close the source, they break this chain of innovation. They become a value siphon, benefiting from the open ecosystem without contributing back to it.

Redis Labs' license change in 2018 highlights this tension. They changed some of their add-on modules from open source to a more restrictive license. Why? Because cloud providers were offering Redis as a service without contributing back.

This move protected Redis Labs' business interests, but it also sparked debate in the open source community. It shows a potential risk: if too many companies profit from open source without giving back, we might see more projects adopting restrictive licenses.

Chart showing what happens when services are offered without contributing back

This cycle could slow down innovation and limit the benefits of open source. When projects go closed source, they cut themselves off from community contributions and improvements. They might innovate internally, but they no longer benefit from the collective intelligence of the open source community.

Another example of this is Ghostscript, a PostScript and PDF interpreter. It started as open source, but the company behind it, Artifex, later adopted a dual-licensing model. While they still maintain an open source version, the most advanced features are only in the commercial version. This has led to a situation where the open source version lags behind, and the broader community can't contribute to or build upon the most innovative features.

So while building on open source can drive innovation, closing off that source can ultimately stifle it. It's a delicate balance between protecting business interests and maintaining the open innovation ecosystem that made the success possible in the first place.

The venture capital effect on open source

The influence of venture capital (VC) on open source software has been significant, especially during the zero interest rate era that led to irrational amounts of VC investing.

This influx of VC money has both fueled innovation and created new challenges for the open source ecosystem.

VCs and vendor lock-in: A love story

VCs are often attracted to platform plays rather than individual products. This preference has led to some interesting dynamics in the open source world:

  1. Platform Over Plugin: Companies are more likely to get VC funding if they create a new platform based on open source technology rather than building plugins or extensions for existing platforms.

VCs see standalone platforms as having more growth and monetization potential. 2. Platform Lock-in: In order to become a VC-backed business, many open source projects create a platform around their core offering. The open source component runs best (or only) on their proprietary platform, creating a form of lock-in.

This approach can be toxic to the entire community, as you unknowingly adopt a project only to find later you will be forced into a specific platform made by the OSS creators and be price gauged accordingly.

Chart showing the VC path leading to vendor lockin

The VC cash rollercoaster

The influx of VC money into open source has created a sustainability paradox:

  1. Initial Boost: VC funding allows for rapid development and growth of open source projects.
  2. Profit Pressure: As VC-funded companies burn through cash, they face increasing pressure to monetize and become profitable.
  3. Monetization Dilemma: Companies struggle to find ways to monetize open source projects without alienating their user base or compromising open source principles.
  4. Unsustainable Models: Without a clear path to profitability, many VC-funded open source projects face the risk of closing shop or drastically changing their business model (at the expense of their users).

This cycle highlights a crucial point: open source isn't free. Development is costly, and finding sustainable funding models is essential for the long-term health of open source projects.

Flow chart showing the VC harm on ecosystems

So, what do you think?

The debate about profiting from open source without giving back isn't going away anytime soon. As open source becomes increasingly central to the software industry, these questions will only become more pressing.

There's no easy answer, but it's a conversation we need to have as a community. How do we balance the openness that has made open source so successful with the need for sustainability? How do we ensure that those who create value are fairly rewarded, while still maintaining the collaborative spirit of open source?

What do you think?

About me

Hi, I'm Steve, the CEO of Builder.io. We make lots of open source software. We contribute to lots too. We use even more.

Our latest product is Visual Copilot which turns Figma designs into spankingly good code. You should try it out.

Top comments (7)

Collapse
 
shnydercom profile image
Jonathan Schneider

Isn't it "lock-away" instead of "lock-in" if 9 out of 10 VC-backed companies are expected to fail? With customers of 9 failed companies being forced to migrate out of something that was designed to keep them inside, those customers have already spent money on that platform to achieve some business result - and are unlikely to put extra money on just maintaining that business result. In short: 1 in 10 customers of a VC-backed platform would be locked in, the others would probably avoid spending more than what they need for migration. Although the OSS steps in as a saviour, nobody talks about maintenance projects as much as about "lighthouse-projects". There are other ways of investment or company building than taking VC money, but similarly - they also get less press.

Breaking the market for competitors can also be a motivation of larger cooperations to offer free (as in free beer) products. Your point about platform-lockin is actually a good sign: In the past we had strong lock-ins by Operating system vendor, CD distributor, Webspace Provider, Browser-(plugin)-creator, App Market provider, chip producers and more. Building a platform and maintaining a thriving platform is hard, and if it's the only way left to build a monopoly I'd say it speaks to the power of open innovation.

But is building a monopoly the only way to create a lasting software business? Wouldn't it be nicer if we could swap out business models like sorting algorithms? Ideally showing that a business model that supports the livelihood of OSS contributors actually benefits the company more than a closed model? I think that could be the biggest innovation of OSS

Collapse
 
codeawareness profile image
Mark Vasile

I think it's clear for people willing to see overall, long-term social benefits. Supporting OSS contributors benefits the workforce at large, and the innovation across the industry. However, many investors and C-suite executives prefer only to look at their plate, and cut costs down to the bone. This attitude downgrades the long term performance of ALL the companies across the board.

In other words, more and more executives think something like this: "Yeah, I love progress, but I don't wanna be the one to pay for it. Let others do it, and I'll just take in the benefits."

It's a very similar situation with general urban behavior, where nobody spares the effort to pick up that trash and put it in the bin, because it doesn't benefit the individual immediately.

So you see, an innovation in this space would be a cultural innovation, nation-wide, not a technology one. In the absence of a culture upgrade we patch up licensing the best we can.

Collapse
 
fyodorio profile image
Fyodor

So, how can we actually make open source software sustainable while following the noble principles of the OSS community at the same time? Is it possible? Or it’s just a matter of one specific project’s luck surface area?

Collapse
 
winstonpuckett profile image
Winston Puckett

Wow, that was a comprehensive look into something I'd never considered before. Thanks for taking the time to expand on that!

(Btw, the link for builder.io is mistyped and leads to builde.rio)

Collapse
 
samuraiseoul profile image
Sophie The Lionhart

Pssst your link for builder.io is broken in your About Me at the end. It goes to builde.rio

Collapse
 
stahlwalker profile image
Luke Stahl

Fixed, thank you :)

Collapse
 
justgeek profile image
Mohammed Taher

I had an idea that I have been working on for almost 3 years, testing with different use cases to prove validity, and it worked great for internal use projects. However, I had plans to open-source it, so that everyone could benefit from it, but was afraid of the exact concern this article is discussing. However, I stumbled upon this, so a clear signal of what to do. Thanks for the awesome article