Next 6 months: The Open Source revolution.

Tl;dr: Every Tech leader should be asking themselves 2 questions: Would my business survive if my software was free? Is my business IP locked in a single (not FOSS) provider?

Early this year all big players clamored Open Source was dead. Immediately after, an Open Source project, Open Claw took over the world. The business behind it was unclear, however the explosive growth wouldn’t have been possible without it being free & open source.

Engineers in all companies are trying to leverage the latest provider, reducing their LLM costs, and building their own abstractions on top of Claude, OpenAI, and others, to provide faster value to the business. The hope is that this scaffolding will help them leverage future advances while keeping some sort of ‘secret sauce’. This is the reminiscence of our previous two decades of software engineering: specialized software was expensive. CEOs understood this best.

That’s changing, and the reigning opinion is that “Services will be the New Software”. That’s bullish on a simple idea: Consulting firms. For decades, consulting firms have leveraged the idea of in-house knowledge from working with multiple customers. This idea of quasi-realtime insights would give them an edge, when combined with superb talent. And it was survival of the fittest all the way to the top.

The conclusion that many draw was simple:

If replicating software is now marginally more expensive than checking out a repo, and accessing top talent is an API call away, then our technical leverage is organizational operational knowledge.

In that world, open sourcing code, seen as giving knowledge away, seems to be the worst option. That is wrong.

First: Open Source evolution.

Peter Levine wrote two amazing articles in 2014 and 2019 describing the business evolution behind Open Source solutions during the past 40 years. The path we followed was this:

1. 80s: Open Source as a tool for hardware adoption.
   
   BSD & GNU allowed anyone to actually use their new hardware. OEMs needed a way to ensure their devices could be used by as broad an audience as they could, and having a centralized organism made it so that they could grow faster.
   

2. 90s: Open Source meant broader talent available.
   
   Once Operating Systems became more standardized, and software companies grew enough to actually create deep collaborations with OEMs, the “driver” era wasn’t a problem anymore. OS companies will usually develop the basic integrations themselves, and help users adopt new technologies, favoring those companies they worked with.
   
   The new problem was actually running those large datacenters with particular architectures. That’s when support as a service originated. Large organizations needed experts that would help them run their software, even if they had the code. And they knew developing their own custom solutions will greatly reduce their available talent pool. They also knew they weren’t in the business of developing such solutions, and they couldn’t afford to depend on a private player, like Microsoft.
   
   RedHat, Ubuntu, and other Linux flavors revolved around selling those support services. They’ll provide you top support, develop specific solutions following a well known standard and, still, be flexible enough that you could potentially find others to take on the challenge. This is key, having “small competitors” working on their open sourced codebase was part of the value offered.
   

3. 10s: The SaaS shift
   
   Two things happened in 2010. Smaller teams started providing software solutions, and those teams didn’t have time to invest on running particular infrastructure or specialize on certain stack levels. That was the key for Software as a Service.
   
   Still, Open Source meant eventually you could run the software, however the true cost had shifted to optimize the infrastructure use. That was the most prominent billing item, and economies of scale didn’t kick in until your need for a particular product was too great.
   
   Hence, the math worked: running & maintaining a software solution for a fraction of the cost it would take you to do it seems like a no-brainer.
   

   Great examples of that are: Github, MongoDB, Databriks, Elastic, and more. Yes you could implement and run those, and competitors could provide alternative services, but usually going to the source meant you’d get a better pricing and, in many cases, the latest features early on.

Technology and Business innovation loop circle as we become proficient in each.

The interesting part is not how the business evolved, but that in every stage the advantage of choosing an open source solution stayed the same for businesses. You could always have the assurance that choosing Open Source meant low lock-in, and protected IP on your business layer.

Why?

You can always branch the solution and start your own, or look into their community, while deploying and evolving the software yourself, giving 0 visibility to external parties.

The Achille’s heel for Open Source
Hostile takeovers are a real thread for all OSS business models. You can always be a victims, it doesn’t matter who you are.

Second: The fallacy of these last 3 months.

Tailwind is no example of a business model that didn’t work with the new AI paradigm, in fact, it’s the worst one to reflect on. Their business model was predicated on access to specific add-ons, for life, almost like template as a service. The problem for SaaS is different.

Most SaaS, and those with Open Source versions are more vulnerable, are predicated on the idea that expertise on the area, combined with the cost of developing, deploying, running and maintaining software is sufficiently expensive that you are willing to pay the cost of 1 Software Engineer a year to have premium access to said solution. The math has changed.

For most SaaS, you don’t need their latest version and it’s now cheaper than ever to build that 80/20 solution. Hence, the argument that Sequoia makes around Outcome-as-a-Service.

Their thesis is simple: “if you can deliver outcomes, then you can capture the existing outsourcing budget (6x that of software)”. They paired this with the idea that AI will allow you to increase margins, however they fail to recognize a simple reality:

Every time you use software to do something that produces an outcome, you are outsourcing “that” to a computer.

This is key, the budget for software is less because it’s software, ie. the expectations on pricing for software are ~15% of the cost of outsourcing. That is a standard SaaS practice. In particular, Sequoia refers to turnkey outsourcing (outcome based) and how that could be a software behind the scenes.

For Open Source, this is relevant because it is a particular way of turnkey outsourcing, it’s a way in which you keep all sub-products, and have full transparency on how something is being operated. This is always the preferred option for outsourcing for most serious businesses.

Finally, there’s a big ‘if’ in this scenario: AI doesn’t move fast enough, you can always be one step ahead, and your job is to always be there. To say it differently: you can leverage your customer base learnings to grow your product faster than they can and always give them better value:

Assume what you call judgement today, will be table-stakes tomorrow.

That’s actually more powerful that it seems.

Third: AI native Open Source will win

Back in 2010, one of my first jobs was to develop a way to update firmware on a network of custom hardware devices. It wasn’t my only responsibility, but it did take weeks of work to reach a stable state. Years before that, it would have required a whole engineering team to do so. Python libraries made it so that a quite junior engineer could do it. 15 years later, Tech accelerated significantly.

Nowadays, Claude Code can code that in less than an afternoon with the right prompting. That’s normal software evolution, and that’s also the power of Open Source projects. Why?

When we decided to Open Source our Agent Swarm, it was a result of hearing: “Tell me how you are doing it, we are trying to do the same” multiple times during December. It was a wake up call. The top startups in Barcelona, the ones we aspired to become, were lagging here. Furthermore, they couldn’t comprehend what we were already doing. It looked like magic to them. Since then, our swarm kept improving with self-learning, supporting multiple LLMs, and expanding beyond Software development. But that’s not the amazing thing, the amazing thing is the community around it.

Since we open source it, we have done more than 15+ workshops, talked to over 300+ individuals, and found out use cases beyond Engineering (e.g. Customer Support & Marketing). That engagement is motivated by giving away value, beyond software. In fact, our Agent Swarm is just a particular way to apply those learnings. That’s the new model:

Teach’em how to fish, and set them free.

It needs to be open source

If these agents are actually operating the company, then they are of such importance to the business as a collective, that they need to have full control. Vendor lock-in would be a no-go from day one. They would need to know they can easily scale and run this solution with competing providers, before being at the mercy of a single provider. Which is the known strategy of these big players.

In fact, daily operators should be company employees. You need them to react immediately, be able to influence the organization, be accountable and available 24/7. Above all, you need them to deeply understand your business, your customers, and your vision. They also need to be your subject matter experts, and that’s a challenge when added to all the rest. Hence also the importance of a community or advisory, to make that part of their job just that, a part of it.

To the two concerns above there’s a third one: would my providers become competitors? We’ve seen this play out before through history, Google Stich just threatened the whole Figma business model. It’s not exactly the same (Figma spends 100million USD/yr in AWS vs GCP), but you can see how it could be the case otherwise.

This IP challenge is a major one, when it’s so easy for companies providing this service to ‘anonymize, learn, and replicate’.

Judgement-as-a-service

We define Judgement-as-a-service as the continuous process of helping teams assimilate new capabilities faster than the market moves, an ongoing partnership tied to outcomes. Although counter-intuitive at first, it is the immediate corollary from combining Sequoia’s arguments of Outcome as a Service and Compounding learnings.

If Agents learn at a speed beyond that of their base models, then the only key value you can deliver to an organization is that of helping teams kick-off efforts in the right direction, and then ensure their learnings keep compounding exponentially. A continuous onboarding process.

During our last event with top AI leaders, we were surprised by the three learnings they shared:

1. Enabling new capabilities has an extremely fast compounding effect.
   This means, if you use AI well, the value that you get could be seen in hours. Hence, the question is how can you learn faster?

2. Companies are looking for Elasticity in candidates
   They want highly adaptable individuals that are always challenging their fundamentals to introduce new technologies and practices. Once they have that, they need to implement those across the organization, hence

3. They devote 50% of their time to introduce new practices, and improve their internal systems.
   This is for organizations that can afford it, which tend to be either new organizations or those that have a surplus of talented individuals available. Unfortunately, that’s not the majority of cases.

Welcome to the business model for Open Source solutions: Teams need an effective and efficient way to keep up with current trends through a trusted source. The bottleneck is not really the technology, but the humans that need to assimilate those new tools constantly. At least for the next 2 years.

The service is really continuous training in the fundamentals, tied to business outcomes, and free software updates. Whoever is capable to show that value, and earn the respect of organizations, will be able to convert their Open Source product into an entry point for their services.

The one thing

The value behind Open Source hasn’t changed in the last 40 years. It’s the value of the community, low vendor lock-in, and full control.

Through the years, we experienced the same cycle: businesses built around technical MOATs suffered when those were removed or reduced, and the first ones to experience that pain were actually Open Source Solutions.

As a leader then, you should look closely into what’s happening in the Open Source Ecosystem and ask yourself:

If my solution was Open Source, would I survive?

The business model that can’t survive open source isn’t a business model, it’s a ticking bomb. Start thinking on a pivot.