diff --git a/priv/posts/2024-08-02-commercial-oss.md b/priv/posts/2024-08-02-commercial-oss.md
new file mode 100644
index 0000000..c9fbc00
--- /dev/null
+++ b/priv/posts/2024-08-02-commercial-oss.md
@@ -0,0 +1,27 @@
+---
+title: "Exploring commercial OSS"
+description: "This post touches on the models we looked at to draw inspiration to make Tuist financially viable."
+tags: ["Open Source"]
+---
+
+How and when we can make Tuist fully open source end to end is an ongoing conversation between Marek and me. We conceive open source as a key element in building the best platform to create better apps faster. Open source is freedom; it’s diversity of ideas, it’s accountability, and it’s empowering others to explore new ideas. However, doing this while remaining financially viable is where the challenge lies. In this blog post, I’d like to share with you our learnings, the mental models that we built around sustainability in open source, and how we see the future of Tuist.
+
+If your software has low packaging, distribution, and scaling costs, you’ll have a hard time building a source of revenue for the project—at least with an open-source license. Examples of those are CLIs or client-side desktop or mobile apps. Anyone can easily repackage your app and CLI and throw resources that you might not have into monetizing it. We’ve seen many examples of this, from storage solutions like [MongoDB](https://www.mongodb.com) to Tuist itself. It’s such a known thing that it’s gotten a name—being “Jeff’ed”—which comes from the idea of Jeff Bezos packaging your software and selling it as part of their cloud offering. I said earlier that this is a model that happens when the cost of scaling is low, but if you are an Amazon, that’s not really a problem because you have a large pool of resources to figure out scaling. They might be able to offer a better and cheaper solution, and there’s no way you can compete with them. Tuist was close to being Jeffed. Thanks to that, we learned an important lesson: companies can embrace this model without feeling any need to support the underlying pieces of technology. If this had happened at a different moment in the lifecycle of Tuist, we wouldn’t have minded, but at the time this happened, we were very limited in resources, which is something we were open to them about, and the additional bump in support and feature load would have put us at risk of burnout. So we had to put a pause on our idea of everything being open source.
+
+There are some models to prevent this. Some embrace what’s called source available. They choose a license that’s not approved as an open source license by the [Open Source Initiative](https://opensource.org/), like [Functional Source License](https://blog.sentry.io/introducing-the-functional-source-license-freedom-without-free-riding/) or [Fair Source](https://openpath.chadwhitacre.com/2024/the-historical-case-for-fair-source/). The code is available in those cases, but the license limits what companies and developers can do with it, usually putting the focus on financially protecting the project. For example, [Tart](https://github.com/cirruslabs/tart/blob/main/LICENSE) limits the users that can use the license. I personally like the balance that this model achieves because small companies or indie developers can use it in their projects, but if they grow, which usually means they have financial resources to support the project, they can pay for another license. It’s called [dual licensing](https://fossa.com/blog/dual-licensing-models-explained/). There’s one caveat to this model: you might get fewer contributions because you have to require developers to sign a contribution license agreement to own the rights of their contributions to be able to provide a dual license for that code. Those same rights can be used to even close the source code, change the license down the road, or sell those rights to another company. When using an open-source license and no CLA, in scenarios like those, the community has the freedom to fork the project and continue its development in a different direction and most likely under a different name. For example, when Terraform [changed their license](https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license), limiting the freedom of the software, a bunch of companies with the support of the Linux Foundation forked the project [under the name OpenTofu](https://opentofu.org/).
+
+Soon after being close to being Jeff’ed, we learned through the creator of Docker, [Solomon Hykes](https://github.com/shykes), about the importance of trademarks. He mentioned in a podcast that we developers tend to put a strong focus on the license and forget about trademarks, despite this one playing a crucial role in situations like the one described above. When someone builds a project, there’s value in the code, but also in the brand that emerges and the community around it. Terraform and OpenTofu have a point in time in common, but the brand of the former might have more value and support, which the latter does not. That’s why when forks happen, they either happen with enough support from a big portion of the community and companies, or you are prone to have a difficult time promoting it. Imagine if AWS had to sell Redis under a different name. Do you think people will be more inclined to get it from there vs from the organization that created it? A brand is something that takes many years to build, and shortcuts with money don’t usually yield good results, especially if the people that you build for are developers.
+
+We have a trademark now in Europe and the US, but we didn’t have one back then, so a company took the freedom to fork the tool and use the brand to market an integration from their service. An open conversation with them about our concerns went nowhere, so the question of whether trademark guidelines would have nudged this in a different direction remains. I have high doubts we’d have reached an agreement, but at least we could have pushed to stop using the Tuist name under their umbrella of services. In hindsight, I think close-sourcing part of the code was the right move. That was not an easy decision emotionally, but we felt it was the right thing to do, and I’m proud of the job we’ve done to navigate that and think about a future where we can go back to everything being open source.
+
+There are open source projects that fit the above model and remain with a permissive license and in some cases no trademark. In those cases, maintainers have a full-time job at a company and treat working on open-source as a gift for a community that they do in their free time. I respect that model and admire maintainers that are able to do it sustainably, especially if the project is successful, because the maintainer’s limited attention and time are impossible to scale. Hence why there are many cases of burnout. And at the end of the day, the project itself also suffers because they tend to stagnate, often with the hope of not increasing more the load of requests the maintainers receive. Tools like Fastlane, Mise, or many Swift Packages fit into that model.
+
+There are companies like [37Signals](https://37signals.com) that open source some of the tools that they develop internally to support the development of products that are not related to the tools they are open sourcing. For example, Ruby on Rails or the many utilities that the company open sources. I like this model. That open source is often a gift and is published with no strings attached. It’s a bit like we are doing well, and we are contributing some of our work to some commons for others to build businesses upon. However, the closed-source products miss the opportunity of bringing diversity of external contributions. I think it’s beautiful, but the more I familiarize myself with sustainability models, the more I realize that it might not be possible with all kinds of products. I’ll expand on this later on.
+
+A different model, which is the one we are starting to embrace, is providing value from the server side. Because it comes with some costs and complexity of hosting and keeping up with the software updates, some companies will be inclined to pay, especially if the complexity of maintaining the service running is significant. An example of that is [Cal.com](https://cal.com). Most people will pay for their hosted version because they are not developers and most likely don’t know how to self-host. The ones that do know, and that’s ok. You might think that they are not contributing back, or at least financially, but there’s a chance that they do so through code. They sometimes also become evangelists of your software, which is an excellent marketing tool. Some projects extend this model with some features that are released under a paid license. Those are usually the ones that large enterprises need. They also do dual licensing for companies that have strict policies against copyleft licenses like [AGPL3.0](https://www.gnu.org/licenses/agpl-3.0.en.html). However, do note that hosting AGPL3.0 software on your server is entirely compliant with the license. An Amazon could still take a service, host it, and sell it, but without owning a trademark, that’s a very unlikely thing to happen because they’d need to make a huge effort to understand software that they are not maintainers of and market it under a different name.
+
+The challenge with the above model is that if your market is small, and it’s mostly developers, then you can find many companies, especially the ones outside of the US, that are willing to take the little risk of hosting AGPL3.0 software on their servers, and some are willing to go even further and self-host the pieces that are under a different license. At the end of the day, it’s impossible for you as the creator of the software to know if something like that is happening, and even if you knew, would you go the legal path against a small random company somewhere in the world? Cal.com can afford this because their market is huge, but ours is small still, so doing something like that will slow down reaching financial viability and be detrimental to the product. There are products like [Supabase](https://supabase.com) that can afford that, even if they haven’t captured a big chunk of the market yet because their value of the software lies also in the complexity of scaling a database. In our case, the value at the moment is mostly on the client, so until we have more value on the server and some complexities or enterprise features that make the product compelling to pay for, I doubt we’ll make the server open source. We believe we can get there, but it’s a matter of time to do that shift in value. What we know for sure is that we are not going to introduce complexity for the sake of making paying for Tuist compelling. For instance, once we step into the continuous integration space with Tuist Workflow, that might change the story. We could become the first CI service for app developers that’s open source, and the complexities associated to that are worth having company dealing with them. Note though that there are projects like [YunoHost](https://yunohost.org/) or [Cloudron](https://www.cloudron.io/) that make the installation of services like GitLab, that are in theory complex to run and update, a one-click action, so I believe having a few features for large enterprises under a different license will be key too.
+
+We discarded other models like Pointfree’s of selling courses. We’ve learned a lot about Xcode and Xcode projects and that’s certainly a sellable thing, but we find joy in building a useful platform, so we went this path instead. Along the journey we’ve been open-sourcing, and we’ll continue to do so, MIT-licensed gifts to lift innovation at a layer above the layers that are common across similar businesses out there so that we don’t waste time building proprietary technologies in silos.
+
+We see in 5 years an open-source [Vercel](https://vercel.com) or an [Expo](https://expo.com) that bets on standards to support teams in the journey of turning an idea into something that they can share with people (not users). It’s a matter of shifting value to the server and expanding the market that we can open source everything. Can’t wait!
\ No newline at end of file