When @pquerna calls, I’ll answer. First, this is why open source matters, and why the Fair Source crowd are right that at least it’s open source eventually. @bcantrill is free to go his own way. It’s cockroach who chose to split.

https://twitter.com/pquerna/status/1824458963712344448

That said, Cockroach has been pretty clear about their intentions all along. I’m honestly surprised Bryan and team were willing to use it at all, if what they needed was a component they wanted to embed. They were already BSL - they told you it was about them, not you.

Okay, since @sogrady is a pal, here are my thoughts on IBM buying Hashicorp. First - congratulations to all my Hashicorp people - it's an incredible accomplishment to have built a company like that, and a crazy thing to have someone value what you built at $4B+. Congratulations.

https://twitter.com/sogrady/status/1783509933863977365

My read on it is pretty straightforward. Hashicorp had two main drivers of revenue afaik, Terraform and Vault. IPO to today they're down from $85.70 to $23.97 before the announcement. Absolute bottom was $19.68, I think?

So I’ve been talking about describing open source through a business lens, and leaning on increasing TAM as one theoretical impact. But you really have to take into account TAM, SAM, and SOM. Let’s break those down. Part 1/n. TAM gets measured by calculating the total number of theoretical customers and multiplying by average contract value (price). So your product sells to the global 3000 at an acv of $10,000. Your TAM would be 3000x$10,000=$30m. (This is much too small! Dream bigger!)

Here is part three of my thread on the FSL. Part two is linked here, with part one linked from there. This thread is about how FOSS can impact the business dynamics that create the free rider problem.

https://twitter.com/adamhjk/status/1726316725153775861

So if scarcity causes the free rider problem, and we need to create scarcity to feed ourselves, how do we build a company that both creates massive wealth over time *and* avoids the free rider problem?

Here begins part two of my thread talking about the FSL. First part is here: . So, while the software is infinite and its use doesn't cause the resource to degrade, the only way we know how to make money is from scarcity.

https://x.com/adamhjk/status/1726311265604374750?s=20

https://twitter.com/adamhjk/status/1726311299859247389

And without money, we can't have the other things we want in our life - like food, or shelter, or coffee (blessed, sainted coffee.) This is where the "your" part of the FSL comes back into play. The software exists to generate wealth for the creators.

Here is what I like about the FSL: that it clearly says what it's for: - it values developers "using and learning" from "your software" without "harmful free-riding". This is the clearest version of the source available movement. /cc @sogrady /part1fsl.software To fully understand what I don't like about these licenses, and what I don't like about the FSL, you have to pull apart the three things in quotes - "your software", "using and learning", and "harmful free-riding". We usually conflate all 3 when we talk about it.

Fastest way to ensure you have even more competition for your open source cash cow? Make it harder to compete with yourself. Example: suse.com/news/SUSE-Pres… RedHat looked at the problem of flat to declining revenue lost to clones and said: we need to stem this tide. Let’s put some space between us and them. They did that by getting marginally more closed functionally, and quite a bit more emotionally.

Seeing a lot of people "hearting" this one. My freinds - this is not how availability works in reality. Is S3 amazing at taking infinite (slow) storage and replicating it? Absolutely. Do you need it in order to fulfill requirements? Absolutely not.

https://twitter.com/johncodezzz/status/1628092892735733761

If you stored the data in two datacenters physically distant from one another, and fronted them with a CDN for edge delivery (which you probably will in both cases) - you'll be more than fine in reality. I have so much news for you on how most of the internet (still!) works.

We will just brush the whole “it doesn’t work sometimes” part under the rug. Don’t worry - just think of it like the worst software bug you’ve ever encountered, only “fixing” it has as much probability of making things worse as it does better. karpathy.medium.com/software-2-0-a… Do you have a workload where you are finding signal in noise? Where you want to predict the next right probability? Where you can accept a large failure rate, with no reasonable recourse? If so, guess what: software 2.0 is coming for you.

Two racks. My friends, it fits in *two racks*. I love the cloud as much as the next person, but $7m over five years to run a workload that will fit in *two racks* makes me want to sleep for a year. Fully automating two racks was not hard. world.hey.com/dhh/we-stand-t… The story that says this isn’t real cost savings hinges on how hard it will be in comparison to manage these workloads. Let me say, if you believe there is $7m in mgmt spend over 5 years for two racks of computers: you’re wrong.

I made a joke, and it turned into a whole thing about building on top of various API shapes. In particular, why declarative APIs are in general harder to build new things on top of. Let’s see if my thumbs can help shed some light on what I mean. First, a note about “build on top of”. There are many different reasons an API exists - some (like k8s) exist primarily to be the mode of user interaction. You might use kubectl, but that’s mostly just conveniently passing data to the api.

Maybe that's the move. Rather than explaining it all patiently, when someone asks me what to do, I'll just say: "Do you want a billion dollars in ARR?" When they say yes, I'll say: "okay, then do what RH does - it might not work, but it's the only example consistently working" Not for one product! Not for one vertical! For a *bunch* of things.

Even @ubuntu couldn't figure this out! They're a *fraction* of Red Hat's revenue! On an OS that dominates cloud deployment. They would probably literally murder someone to have $1B in ARR at this point. Why can't they do it? My friends, it's because they *open sourced the product*. You can just... run Ubuntu. Great for adoption! Don't worry, they'll make it up in volume! Meanwhile, everyone making fun of RHEL.. just over there cranking dollar bills.

I want to dig in on why Red Hat is better at generating revenue from open source than anyone who has ever done it. This is a perfect example. Do you know how rare it is to generate $1B/ARR? Hashicorp is *half* that number. Let that sink in.

https://twitter.com/krishnan/status/1618745809880875009

What does Red Hat do differently? First - they trust in the power of collaborative communities. They open source everything, not just some things. What's good for the upstream is good for them.

One good thing about the ASF is the declaration of a zone of “pure” collaboration. For projects with a strong open source community, and many downstream companies, I think it’s the best model. It normalizes having people put aside their external motives inside the zone. Nobody can actually do that, obviously. But it means you don’t have to hide it either - you’re not less of a contributor because you’re affiliated with a company, or because you’re furthering your own interest.

This is a case study in how I think you shouldn't do your initial go to market: wundergraph.com/blog/the-end-o… - lets talk about why. 1) It's essentially a negative pitch. In the first couple paragraphs we get stupid executives (who I suspect you're going to to want to sell to some day!), and stupid systems administrators. We care about developers, because they matter!

I acknowledge this is real, and that in many cases, it's worth optimizing for. At the same time, languages being able to express complex behavior succinctly is an important part of their being maintainable over time as well.

https://twitter.com/kelseyhightower/status/1580988384306077696

Since Kelsey used Ruby, I will too. The Attributes subsystem in Chef is one of the most complex parts of the code base (people love to talk shit about how complex, and if you want to crawl into my mentions to do that, fuck off in advance, as its not the point)

I no shit read a release announcement for a new platform-y like ops tool, promising to make your infra work disappear. It started with what a bunch of assholes systems administrators were, and then proceeded to just keep punching from there. Besides being awful strategy (guess who has the money you need when you want your magic platform to seek to a large org, asshole?), it shows how deep it goes.

I think we are seeing a shift toward enterprise teams using more cloud platforms fully, rather than intermediaries. Multi-cloud as a strategy for a single app appears to be dead/dying. Instead it's "choose the right cloud for the application", based on what can be rearchitected That's a big shift from how this was talked about even a couple years ago. A lot of the fundamental marketing for this generation of tooling was based on the fact that the market wanted that.

I’m starting to think that a lot of our foundational metaphors for how to build startups and companies is off, in ways that dramatically influence our behavior. For example, that software engineering and product development is like a factory. It kind of is, if you squint hard enough. By studying those worlds, we do get some wonderful techniques (lean, theory of constraints, etc). But others really break down (measurement, etc)

We are going to see more of the BSL, not less. These are frequently great products - Cockroach, Akka, Red Panda - which means they likely will sell their product to folks. Which means from their perspective the license absolutely works. When you compare the difficulty of running an open core business, the BSL eliminates most of it. The product is proprietary. The code is free years and years from now. Nobody but you can monetize it.