Integration Platforms

"Integration Platforms" is quite a broad term and can include several types of tools. You can think of automation tools like Zapier, Workato, Torq, and Tines, as well as data tools like Boomi and Fivetran. Both categories share similar technical challenges and business economics.

Challenges

1. Limited Capabilities of No-Code Abstractions: If a user has a more complex automation requirement, it becomes very hard or expensive to modify it, or the user has to fallback to code (e.g., for loops, complex conditional logic).

2. 10%/90% Rule: 10% of integrations bring in 90% of the revenue, leaving the other 90% of the market underserved because it becomes uneconomical for the vendor to create more integrations.

Website Builders

Website builders like Webflow and Wix represent another interesting no-code category. These tools face similar challenges and drawbacks that resonate with integration platforms and no-code tools.

Challenges

1. Limited Capabilities of No-Code Abstractions: Once users require more custom features, customization becomes hard and expensive. Eventually, it becomes easier to hire a React/Next.js/JavaScript developer than a Webflow/Wix developer.

2. 10%/90% Rule: Website builders are essentially abstractions of JavaScript and web frameworks. Typically, 10% of the features generate 90% of the revenue and use cases for users who need a no-code website builder. Beyond that, there is a long tail of features that bloat the no-code framework, making it hard to develop and maintain.

What’s Next for No-Code Tools

Looking at the two segments and some of the challenges from both the user and vendor perspectives, I see a number of interesting developments with the advancement of LLMs for code generation:

1. Integrated AI: Current no-code tools can integrate LLMs into their frameworks to make it easier for users to create new integrations without hiring an expensive engineer who is a pro at the specific no-code product. We have some early signs of this already, such as Zapier AI.

2. New No-Code Tools with a Code-First Approach: This could be an interesting middle ground and an opportunity for new tools (aka AI Native 😆). Original no-code tools break down when customization or code is required. If tools can be built around code-first frameworks and give users the ability to always modify the underlying code, that could be a sweet middle ground. This is, of course, the holy grail and still poses many questions about feasibility, as some guardrails will need to be in place. The best example I found is the very early version of Vercel’s v0.dev. Vercel is a hosting company and by integrating a code generation LLM into their UI, it allows users to generate websites and deploy them immediately—all without coding.

3. Direct LLM Usage in Development Environments (GitHub Copilot, Claude.ai): More and more users can now code basic stuff whether it’s a small automation or a small website from scratch. This trend makes coding cheaper and lowers the barrier to entry for simple application development and maintenance , even for end users.

Personally, I'm most excited about options two and three as I think no-code UI abstractions are expensive to maintain and have too many limitations. I'm also a big believer that the “the best component is no component“, so if we can achieve the same business/user goals without having yet another component or abstraction this might be the best way to go. 

There are probably more interesting segments with similar challenges and limitations in the current landscape, so it will be fascinating to watch how the use of LLMs in different stacks affects both enterprise and consumer products.

Subscribe now

Instead of diving into the entire history of open source (starting with the Linux kernel, compilers, Git, etc.), I will focus on the last decade, comparing different companies, their strategies, licenses, changes they went through, and the lessons learned from those companies. I’m old enough to know that the future is unpredictable, so 80% of this post is dedicated to summarizing the recent past and 20% is reserved for my predictions and suggestions about what open-source business might look like in the future—because predicting is all the fun!

Comparison

I created a list of 9 companies (there are many more open source companies that changed licenses but I tried to focus on >100M in revenue companies and kept it short for the sake of brevity).

Let’s take a look at a few key trends:

1. Permissive (Apache 2.0, MIT, BSD, MPL) to Restrictive License (SSPL, AGPL, BSL) change - Six out of nine companies that started as open source shifted towards more restrictive licenses, beginning with MongoDB in 2018. Without delving too deeply into what SSPL, AGPL, or BSL are, the bottom line is that these licenses aim to prevent cloud providers and competitors from offering managed solutions without contributing back or paying to the open-source project (links to all license changes are in the footnotes).

2. Closed source features - Even with the move to restrictive licenses, companies still maintain closed-source commercial features to ensure there is a journey from free to paid, preventing major customers from remaining on a free plan indefinitely.

Now, let’s look at a few companies that didn’t change their licenses, as each represents an interesting case study:

• GitLab: Open Core from the start. GitLab's initial version was open source, but the company was incorporated shortly after with the intent to monetize. They were relatively diligent in deciding which new features would be free and which would be paid to ensure the free version didn’t give away too much.

• Confluent: Kafka was spun out of LinkedIn to the Apache Foundation, meaning the initial risk and R&D weren’t on the company’s budget. The company focused on building a commercial, closed-source platform on top of a mature and popular open open source project (that said, Confluent is still a major contributor to Kafka).

• Vercel: Next.js was developed by Vercel, it didn’t undergo license changes and stayed with permissive open source MIT license. This is due to a few reasons I can think of. Vercel is a “frontend cloud,” as they call it, or in simpler terms, a hosting company for frontend frameworks. Vercel's product is commercial closed source software, and it would be successful even without Next.js, perhaps even more so. It supports hosting websites written in almost all current frameworks, both client-side and server-side (https://vercel.com/docs/frameworks). The reason for Next.js being open source with a permissive license is actually technical, as there is no other way or license that would work for a library where developers need to import code.

Looking at these nine companies and the recent changes some of them underwent to ensure their businesses are sustainable, let’s recap the current options/models:

1. Restrictive (RSAL, AGPL, BSL) source available license + closed source features.

2. Open core with a small set of features being free with a permissive license and others being commercial and/or closed-source.

3. Closed source or commercial platform on top of an established open source product.

4. Closed source or commercial platform with a separate and standalone piece/ library/framework being open source.

What’s Next

I think the future is still unclear, and companies are mostly in a reactive state. We will likely see different approaches emerge, as companies can succeed despite not having a perfect business model or license.

That said, out of the four options mentioned in the previous sections, I’m most excited about options 3 and 4 (an already existing mature OSS project incorporated into a commercial platform, or a completely separate standalone OSS project that is supported or incorporated into a commercial platform). The reason for this is that it removes any confusion and constant discussion about what should or shouldn’t be in the open-source version. It also avoids the license sprawl and gymnastics (AGPL, BSL, SSPL) that everyone is trying to navigate to remain both open source while simultaneously avoiding being fully open source to combat cloud providers and competitors.

Another trend I think we’ll see more of is closed source but self-hosted. In the last few years, we’ve seen open-source projects that were started as open source primarily for marketing purposes rather than solving a real pain point by being open source. A common theme is that many open-source projects can be easily self-hosted, which is a real need, especially in the enterprise. By also offering a free tier, enterprises have the option to test a product for an extended period in their own environment, which provides real value—but this doesn’t necessarily mean the product has to be open source.

OSS licenses is a hot topic, so I’m curious to hear your comments and new ideas 👇

Leave a comment

1. Redis License Change

2. Elastic License Change

3. MongoDB License Change

4. Grafana License Change

5. Terraform (Hashicorp) License Change

6. CockroachDB License Change

Just to give a bit more history on buzzwords, buzzwords are helpful sometimes, and sometimes they help describe a very big shift in technology, architecture, or way of operations sometimes they are helpful in the beginning and then stop being useful (see modern data stack - now it’s just a data stack) and sometimes they are also not useful from the start because they try to identify a trend that's happening but it either end up not being a trend or just being a sub-case of an already well known technology. 

Enough with the introduction and disclaimers, let’s dive right into that.

What is a data fabric?

First, let’s break down what is a “data fabric” before going into “security data fabric”.

“data fabric” is also a pretty confusing buzzword, in my opinion, but I will try to break it down (on what I think it means). Data fabric is not a technology but rather a strategy of building your data strategy and stack in the company and collecting, storing, enriching and analyzing that data. This is it. So now you think, Oh, so why do we need a word for it? Well, because there are vendors that try to sell more integrated solutions rather than you buying different pieces and trying to differentiate themselves in the market. Not to say that what those vendors provide is not useful as you can definitely buy more integrated solutions, either one or multiple, and build your stack in many different ways depending on requirements and business goals. So now that we have a better understanding that it’s a combination of technologies, I’d like to suggest a different term for that and call it just a “data stack.” Just like in more mature markets, we have a “marketing stack” or “martech” (collection of tools and software that marketers use to improve, analyze, and perform their services, and it’s up to the marketing team to build their stack with integrated and non-integrated solutions).

What is a security data fabric?

Now that we have defined “data fabric,” what is a “security data fabric”? If “data fabric” is “data stack” then “security data fabric” is "security data stack“? Doesn’t make a lot of sense as you have one data stack for different types of data and use cases. So what is it then? Well, actually, I'm not sure myself, but I’ll try to explain. First, from the end, what does a “security data fabric” try to solve? The challenge is the rise of the number of security tools in an organization (solving different problems) and getting insights/analytics from data that is generated by those tools. If we look at the last sentence, we can actually take the goal or the challenge and describe the category in those words, which we think will make it much clearer then “security data fabric” is a way to run analytics on your security data from different security tools.

So now that we have eliminated the “security data fabric,” we can just call it “analytics for security data,”  which both describe the goal and the “category.” 

How to build one?

Now that we have cleared both terms, let's discuss how to build one (if you need one). So, assuming you already have some sort of data stack or even if you don’t, you will need at least one central location like a database, data warehouse, or data lake where you are going to run your analytics (can be PostgreSQL for smaller amount of data and BigQuery, ClickHouse, Snowflake, Databricks, and other data warehouses and data lakes for a larger amount of data).

Now you will need to get the data out of different security systems such as CSPMs/CNAPP, Vulnerability management, EDRs, MDMs, and any other stuff that you have in your security stack to that central location. Here, I’m going to plug CloudQuery, which part of what we do is an ELT (Extract-Load-Transform) for cloud and security tools, so you don’t need to write your own connectors (though you definitely can; it’s not a lot of fun and usually not the interesting business part like writing the analytics that you want to get ).

Once you have the data in your central queryable location, you can start running your analytics, creating query views, creating the necessary answers, and exposing those programmatically or via BI/Dashboarding tools.

Final Thoughts

Before committing to any new buzzwords, first, understand what you are trying to solve. If you are looking to run analytics on your security data and (have the bandwidth to create those analytics), then definitely give CloudQuery a go to remove the slog of writing connectors for security APIs so you can focus on your business use case!