I love open source. I've been using open-source tools since I was quite young, and you had to get Linux from a CD in the mail. Actually, I was using open source well before that, but just didn't realize it. Probably the same with you. I've built an entire career out of open source, from freelancing to dev shop owner to senior developer, and then on into the "corporate" world as a solutions architect for Acquia (the largest commercial contributor to Drupal).
Through that time, my relationship with OSS (open-source software) has changed. My love has only gotten stronger, but my view on 'free information' has evolved. It's not just black and white; it's a spectrum of gray that's as complex as it is fascinating. I've seen too many great projects die from lack of support and funding to be overly militant about OSS. We also need to be pragmatic. Great projects need a way to generate funding to pay for development. While the code may be free, developers still need to eat... and if your diet consists mainly of youthful ideals, then your ability to create great stuff will rapidly diminish.
I've seen many, many different approaches to OSS sustainability, from the purely donation-based to the heavily commercialized. I've seen companies that tout open-source as a value, but then effectively roll out "crippleware" that is almost useless without paying. I've seen organizations build massive coalitions of commercial support for projects that are completely free... and seen more than a few of those fall apart over time. One thing I can say is that there is no "one right way" to do open source. It depends on the project, the person or team behind it, the complexity, and the industry.
As a result, I am incredibly fascinated with the strategies and licenses that open-source projects choose to adopt, and the results of those choices. In this post, I want to talk a bit about my understanding of how Appsmith makes these decisions, and how that has worked out so far. While this is based on many deep conversations with the leadership and engineering teams, please understand that this is my own personal viewpoint. Like you, I am a member of the community but I don't have the authority or power to make decisions. As an employee of Appsmith and Head of DevRel, I do have a rather loud voice when I express my opinions (sometimes too loud, right Nikhil?), but the heavy burden of managing, building, and ensuring the success of the project is not for me to carry.
A simple philosophy
When I was interviewing with Appsmith about a possible role, I was very eager to talk with the Head of Product - Nihil Nandagopal. We had a great discussion about the Appsmith philosophy, and I had lots of questions. During my interview with Appsmith, I didn't hold back. I grilled them, pushing for answers, digging deep. And you know what? They didn't just respond; they impressed. Every question I asked, and every potential "trap" I set was easily dealt with. The approach is very simple and very direct - focus on the needs of the average developer, and add paid features for larger teams and organizations. It just makes sense.
"Features that are necessary for the 80% of developers to build apps should be in the community edition - we never gate keep the ability to build an app. Thats why all our widgets and datasources are always in the community edition.
Features that are really only needed for large teams or commercial organizations should be in the paid edition.
We are developer first in all things.
-- Nikhil Nandagopal
While I enjoyed talking to everyone, and recognized that Appsmith was a cultural fit for me personally, it was my conversation with Nikhil that really sealed the deal. I felt that he was committed to a strong open-source project and would be a great steward for the Appsmith Community Edition. Almost two years later, and I still feel this way.
Don't get me wrong - there are still grey areas where a decision can go either way, and I don't always agree with the decisions, but there is no doubt that the product team at Appsmith is devoted to maintaining and supporting both the community and commercial sides of the project.
What it looks like in practice
Saying is one thing, proving it? Now that's where the real challenge lies. But let me show you how Appsmith walks the walk. Let's look at a few decisions made over the past few years so we can understand how this philosophy plays out in the real world.
Want a quick cheatsheet of what is available in different versions? Check out the feature comparison page on the main website.
SSO - App-level vs Platform-level
Single sign-on is one of the key features available for internal teams, and it is one place where there were lots of discussions. The community edition supports Google and Github for auth, which makes a ton of sense. These are widely available, widely used, and offer two great options for teams. Lots of teams use Google Workspaces for email, so having an easy, unified SSO system there is great for organizations of any size. Even without that, you also have plain old Gmail accounts that can auth in, and many people have one of those. In addition, we offer Gihub auth as well. Most developers have a GitHub account, even if they primarily use another tool like Gitlab or Bitbucket. So when you have a platform for internal developers, those two options cover a lot of ground.
Of course, it isn't just developers that need to auth into the platform - often, you will want app users to be able to auth in to use a private app. In those cases, Google and Github can still be very useful, but then we see requests for things like AD, Okta, Auth0, or general standards like OAuth, SAML, or OIDC. So should that be a paid feature or not?
Well, lets go back to the philosophy - do 80% of our community developers need advanced platform SSO in order to access and use the product? No, not really. Most of these requests come from larger companies and teams, or people who want to build a commercial application on top of Appsmith. So, this is a great candidate for the paid version.
At the same time, we can see the application of a small detail many people overlook. Providing a feature or capability OOTB is not always the same as providing the opportunity to create your own implementation of that feature. For example, community users can always implement an app level external auth solution like Supabase, Github, APISIX, or pretty much any client-side auth provider.
Not that this allows developers to create "application-level" auth, not "platform-level" SSO. But, the capability is there - Appsmith doesn't block you from rolling your own solution using its tools, it simply provides a paid option for a more convenient OOTB approach that is more useful for large teams. In deed, we see many people who don't want platform-level for their apps, and they prefer the app-level option. Appsmith provides that level of flexibility.
Custom Branding
This is a pretty easy one, but lets take a quick look. One of the things companies will ask for early is the ability to rebrand their Appsmith instance so that it removes the Appsmith logos and colors. Custom branding is a great feature, but is it necessary for the average developer? Does it provide any capability or features that will help them create the apps they want?
No - it doesn't. It allows an organization to "white label" the platform. The use case is very valid, and very important... but it's not a developer feature. It is a business feature. So, that capability is a clear case for the commercial edition.
Reusability
This is a big topic, but this is a good example of where things can get a bit fuzzy. While reusability is not an absolute requirement for building apps, it can be a hindrance when you want to extend your app or create multiple variations or reuse common patterns across your apps. So, while it is not required for building an app, some reusability is imperative for a solid developer experience.
Want more info? We have a video and another article that explains our reusability strategy and how it works across versions.
This topic has become even more important as Appsmith has invested more in reusability across the platform in 2023, and this trend will continue for some time. In late 2022 we started talking about a concept of reusability called "modules", and how this would let us encapsulate and reuse work between apps. We already had app forking and cut/paste options for the canvas, but we wanted to create a way to share work from within a page and with more than just widgets.
At first, it seemed simple -apps are, in effect, a bundle of configuration (this is what the exported JSON represents). So, we just need a way to bundle and import/export config, right? Well, it is not so simple. As we started talking to customers, it became clear that they wanted more. They wanted the ability to reuse JS, datasources, widgets, and queries from a central repository. They wanted to be able to version and update those reusable entities, manage access, and also potentially force upgrades to specific versions. This drastically increased the scope and complexity of the solution. It also meant that we would have to enforce certain limitations and patterns that were optimized for corporate governance over developer productivity.
This understanding of the larger scope led to many discussions and debates, some quite heated. We realized that the modules concept could either serve the commercial use case or the community one... but couldn't serve both equally well. The needs and requirements were just too different. So, what to do?
Instead of choosing one or the other - we found a way to have both! The Modules Pod continued on its more complex path towards corporate-focused reusability features (which is a much longer roadmap), and the Templates Pod expanded its scope to include community features to empower the average developer:
- community templates
- partial import/export (sub-page)
- building block templates (coming soon!)
- custom JS libraries
In addition to putting more resources into community reusability, the simpler scope means that we are able to deliver these features at a faster pace for all developers! Again, the focus here is no providing the features and tools that will be most useful for the average developer and will provide the foundation for all kinds of benefits. Plus, when larger organizations need more tooling and capabilities around governance and larger team usage, we have the modules features available for them. Everybody wins.
Custom Widgets
I saved one of the best items for last, and that is because this shows how committed we are to this philosophy. Many people have long used the iframe widget to do all kinds of crazy or custom things. The iframe widget became a de facto "custom" widget. As useful as it is, we also knew that we could make it easier. So, the team set out to create a custom widget that made getting the benefits of an iframe with a simpler and more useful interface easier.
This is an incredibly powerful feature, and it unlocks so many other things. It basically allows you to create your own mini-applications in your apps that are easy to use and extend. Now, this feature is not a requirement for developers - they can always use the iframe widget like they always have. Plus, this killer feature would provide more value for the commercial edition.
As such, you may expect that there was a big debate on where it should go... but that is not the case. From the start, the product team recognized that this feature would be incredibly valuable to ALL developers, making their lives easier and giving them a better development experience. It also makes it easier to customize their apps without needing to go through too many extra hurdles. Plus - it's a widget (which means it should go in the community). As a result, it was designed as a community feature from the beginning. No debate, no questions, no conflict. The philosophy wins out.
Other features
There are plenty of other features we could discuss like access control, audit logs, datasource environments, or user provisioning... but most of those are clear in their decision. Overall, though, I think the Appsmith track record speaks for itself.
There will always be some decisions that we, as individuals, may not agree with. But, on the whole, it is clear that the Appsmith approach finds a fairly consistent balance between paid and free features. This is vital to the company's success and the project's longevity. While this is an open source project, very little code contributions come from the community. This is not a deficiency of our community, but a reflection of the complexity and power provided by Appsmith. With a super performant Java backend, responsive React front-end, and a secure-by-design architecture... it is difficult for individual developers to contribute code with the necessary time it takes to write, qa, test, and work with us to get inclusion.
As a result, we have to expect that future of the project will require 99.9% of the codebase to come from employed engineers. This means we need to have a successful business model in order to keep providing updates and features to the entire community - free and paid.
In just the past year, we've watched giants fall and projects dim. It's a stark reminder of the volatile world of tech. This is always a risk, and something that developers need to keep in mind as they choose their tools. But here's where Appsmith stands out. Appsmith is a safe bet because we do have an open-source community edition, which is a comfort. But beyond that, we also have a great business model that ensures that we will be around for a long time.
The best part of all is that we also have a winning philosophy for maintaining the balance between the free and paid features on the platform. This comes from our open-source roots, and it is a driving value behind all of our decisions.
