The Unintended Consequences of Open Sourcing Software

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.

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.