Someone told me recently that open source is no longer cool. That it was a trend, and the trend has passed. I've been thinking about that comment ever since, not because it upset me, but because it revealed something about how a lot of people in our industry think about openness. They reduce it to a tactic. A distribution strategy. Something you adopt when it's fashionable and abandon when the winds shift.
I think that's a very narrow way of looking at it, and I think it misses the point entirely.
The recipe and the chef
There's an analogy I keep coming back to. If you search the internet right now, you can find recipes for almost anything. The best restaurants in the world, the dishes that people travel thousands of kilometers to eat, many of those recipes are out there, publicly available. You could technically replicate them at home. But if you try, you'll quickly realize that having the recipe is not the same as having the craft.
A chef who has spent years working with ingredients, who understands the subtleties of heat and timing and texture, who loves the act of cooking itself, will always produce something different from someone following the same instructions for the first time. The recipe is open. The magic is in the hands.
I think about this a lot in the context of building software. There's this pervasive fear in the industry around sharing. Around being open. Companies treat their code, their ideas, their roadmaps like they are the entirety of their value. As if showing someone what you're building means they can instantly take your place. But the truth is, when you're building something with genuine passion and deep understanding of the problem, openness doesn't weaken you. It strengthens you. Because the value was never just in the code. It's in the obsession, the taste, the accumulated understanding of the problem space that took years to develop.
What I see when I look around
When I look around the industry, what I feel most is fear. Fear of sharing too much. Fear that someone will copy your feature, your architecture, your positioning. Companies build in private for weeks or months, then task someone with creating noise around the announcement, hoping the algorithms will carry the signal. And it's getting harder and harder to make that work. You can't just publish a blog post and expect it to spread. The platforms don't reward that kind of content anymore. Search is less reliable as a discovery channel. The old playbook is breaking down.
And then there are the blog posts themselves. I came across one this morning from an engineering leader at a company, and I could tell immediately it was generated by AI. Not because using AI is inherently wrong, but because no one had bothered to read it. The post said nothing. It had no point of view, no depth, no personality. It was content for the sake of content, published so that a checkbox could be ticked somewhere.
When I read something like that, what I take away is that the people behind that company are not deeply connected to what they're building. Because if you love what you do, you don't put out something empty and call it done. You care about every word because every word represents who you are and what you stand for.
The long game of trust
I believe the only way to genuinely reach developers is through trust. And trust takes time. It takes consistency. It takes showing up, over and over, with substance. Not fireworks. Not growth hacks. Substance.
At Tuist, we've been doing this for years. We share what we're building, what we're thinking about, what problems we're trying to solve. Not in polished marketing campaigns, but as part of how we work. Our code is open. Our design process is open. Our technical decisions are open. Support happens in public. We're starting to have our marketing conversations in public too, making videos of the discussions, the scripting process, all of it. I don't know if people will participate, but the invitation is there. If someone wants to throw in their ideas, why not?
This is what resonates with developers. When they see a team that is contributing to making things better, that has a clear vision, well articulated, that they can connect with, something clicks. It's not a transaction. It's a relationship built on shared values. A developer who has been using Tuist for Xcode, who has watched us share our thinking for years, when we announce that we're expanding to Gradle, there's a natural interest that emerges. Not because of an ad. Because of trust earned over time through openness.
I don't think there's another way to build this with developers. You have to be a community builder. You have to do the work in the open. You have to make people feel like they're part of something, not just customers of something.
The balance
I should say that openness doesn't mean naivety. There's a balance to find, especially when it comes to licensing and business models. Cloud providers can take your open source project and sell it as a managed service on their infrastructure, and competing with that is nearly impossible. If your audience is developers and there's no real incentive to pay you, many will self-host even when it's painful to do so.
This is something that continuously evolves at Tuist. We haven't fully settled on our licensing for the server side. In fact, our goal is to be fully open source when most of the value lives in the infrastructure itself, which is where the real pain is. There's so much accidental complexity in running and managing that infrastructure, complexity we can't fully eliminate, that most people genuinely don't want to deal with it themselves. And the bigger the market becomes, the more attractive this model gets.
You need to understand who you sell to and who might want to sell what you've built. That awareness shapes your licensing decisions, your business model, the way you think about where the value lies. It's not something you figure out once and forget. It's a continuous conversation.
Building in public is building with others
One thing I've noticed is that when you build in the open, you expand your pool of ideas dramatically. When we discussed publicly that we were going to introduce compute as an internal primitive, someone told me it was a bad idea. I didn't agree, but the conversation itself was valuable. When you share your thinking openly, you're socializing ideas. You don't need a big launch event. You keep talking about what you're doing, what you're considering, what you're solving. And slowly, people start to engage.
On our platform, people contribute things like new languages for the dashboard. When you invite contributions, you get a design surface that accounts for a diversity of ideas and needs you could never imagine on your own. Otherwise you're limited to the ideas of your employees and your existing customers, and that's it. The pool becomes the world versus you and your small team. And the world, as it turns out, is more creative.
This is precisely what companies tend to lose as they grow and focus narrows to meeting investors' expectations. Their websites fill up with webinars, demos, contact-sales buttons, and factory-produced blog posts. The craft disappears. The personality fades. And they wonder why developers don't trust them.
This is what we believe
I know that some people look at how we operate and feel uncomfortable. Some have tried to dismiss our approach as a trend, or put it down as unsustainable. We couldn't care less. This is not a posture we adopted because it was convenient. This is who we are.
We believe that openness builds the kind of trust that marketing budgets can't buy. We believe that the best products come from people who love what they do and aren't afraid to show their work. We believe that inviting the world into your process makes the result better, not worse. And we believe that this is the path to building something that lasts, a company we can be proud of, with a community of people who believe in the same things we do.
The recipe is out there. But we're the chefs. And we love what we cook.