Is open source the right move for indie hackers? Open-source founders weigh in.

Just about everyone likes open-source software, but few founders choose to build it. I did some digging to find out whether it's actually a good option for indie hackers.

Here's what OSS founders had to say about the problems — and solutions — with going open-source. 👇

Why should indie hackers go open-source?

Marko Saric of Plausible:
We open-sourced Plausible to be as transparent as possible and to give people more control over their data. We're in the privacy-first market so working on an open-source product is a way for us to build trust with our audience.

This trust and transparency aspect of open-source also means that building a passionate audience may be a bit easier than in the case of closed-source software. There are a lot of people that are really into open-source software and they're really passionate about it. These people wouldn't even consider something like Plausible if it were not open-source.

There's a lot of goodwill with people sharing and recommending Plausible to the world. We even had some people contribute code and improve Plausible for everyone.

Richie McIlroy of reflio:

Open-source software is magic. You're opening up your product to a wider audience, and if you nurture that audience properly you can create a thriving community of contributors, and people that naturally become strong advocates of your product.

Making your product open-source makes your product more diverse, as anybody from any part of the world can choose to contribute. This gives a small dev team unique ideas, opinions and collaborative ways of solving problems.

Open-source products are also more trustworthy for longevity reasons. Since the code is open, if the company behind the product ever ceased to exist, then code could still live on.

One of my favourite reasons for open-source is also the sense of giving back. People who are first starting out in their development journey can accelerate their learning by contributing to the product, and getting feedback from more experienced devs in the process. Source

Andrea Vacondio of PDFsam:

I think my OSS version helps sales of the premium ones because users trust it and trust the brand. Source

Bram Wiepjes of Baserow:

For us: Collaborative effort of multiple developers and communities helps us to find a solution a lot faster.

For our clients: Having an open-source model prevents vendor lock-in because they have access to the source code and can host on their own servers. This is something that's increasingly important as the no-code tools we create are built to scale. Source

Karl Eriksson of Mocki:

• Get traffic from GitHub
• Have your users improve your product
• Get included in open-source directories
• Improve [your] chances of getting backlinks published Source

Eddie Jaoude of Biodrop:

Going open-source from the beginning really helps build an authentic and engaged community. This is also a great way to get feedback sooner and early adopters of your product.

We have had contributors testing and reviewing the project from day 1. Additionally, we have contributions in various areas, some of which - if I was working on this project as a closed-source and on my own - I would not have the expertise to execute.

Objection (and solution): Monetization is hard

Andrea Vacondio of PDFsam:

I tried monetizing with donations, paid installers, website ads... and I was very frustrated because the user base was huge and I couldn't make decent revenue.

I finally found my balance with 2 premium versions sitting next to the free and open-source version. Source

Marko Saric of Plausible:
We've tried to do monetization with donations, which seems like one of the more common ways people in the open-source world fund their projects. This turned out to be a big failure for us.

At the same time, our cloud has grown to more than [$2MM ARR], so it is crystal clear that without us having people who are happy to pay for Plausible managed service in the cloud, Plausible itself and our self-hosted release wouldn’t exist. Or at least we wouldn't be able to work on it much because we would need to have other jobs to pay our rent. We also wouldn't be able to have a team like we have now.

So at least for our situation, having a managed solution in the cloud was the best way to go.

@nemiah of open3A:

I have a free version of open3A which is as useful as possible without any limits but, of course, it is missing advanced functionality. This version gets full support by me via phone and email. This is my bait I put out there and I'm sure there are hundreds of people who use it this way and it's fine for them. If someone wants advanced features, I have a shop! 🎁

In my shop the users can buy many of the extensions I have developed over the years... The price contains updates for this extension for one year which means the next two versions.

Here comes the crucial part: My shop remembers all the extensions a customer bought and every time she downloads her version it puts all the paid-for extensions together in a zip file for the update. This is how I sell open-source. The customer gets the code (and functionality) after she buys it.

In 2013, I added a cloud service where open3A can be rented from me and I take care of all the technical things like backup and updates. This is great for steady income. In 2018, I also added a subscription model after several customers asked me for it. [And] in 2021, I [launched open3ABox. It's] a raspberry pi with open3A pre-installed which I deliver to my customers who [don't have] the technical skills for their own server, but don't want a cloud version either. Source

Eddie Jaoude of Biodrop:

We have implemented the Freemium model for BioDrop: There will always be a free tier for BioDrop users, but there is also a premium tier for those who want more features.

Shayan Taslim of LogSnag:

Starting to really like this play:

1. Build something open source.

2. Build trust and a brand around it.

3. Monetize it with a SaaS offering.

I'm seeing more and more folks taking this route to build a traffic funnel and upsell users who want more than what their open-source product offers. Source

Objection (and solution): Too much management

Adam Wathan of Tailwind CSS:

There are some downsides like feeling pressure to do a lot of stuff in public that I'd rather have the space to work on in private, and managing GitHub issues and PRs from the community is an enormous amount of work that we're constantly trying to figure out how to deal with, but overall I think the OSS side of things is a big net positive for what we're doing. Source

Justin Hunter of Perligo:

My first SaaS was Graphite Docs. It was in the privacy and blockchain space, so it made total sense to open-source it and let people self-host. My GitHub backlog grew to hundreds of issues I’d never be able to get to. Source

Eddie Jaoude of Biodrop:

Overall I think it is important to make it easier, accessible and clear for people to contribute to open-source and get value out of the contributions which go beyond a green square on GitHub. Here are a few things we have implemented in BioDrop:

• Having a Contributing Guide which explains to prospective contributors the requirements and guidelines of the project - this will give them a starting point on what is expect of them and what to expect.
• Having maintainers that cover various timezones, but also different areas of expertise. It is not about the number of maintainers you have but how much they feel invested in the project - and don't forget to reward them for their time and efforts.
• Create templates that contributors can use so that they know what to include when raising an issue for example. This will help maintainers understand what is being raised but most importantly perhaps, for that contributor to have their issue accepted.
• Remember that open-source is community-based. We say that BioDrop is "powered by" my open-source community EddieHub and it really is. One thing I would add to this point is that it is important to share your vision and roadmap of the project with your community as well. Not only will this help them feel invested in it and a part of it, but will help with issues which are raised.

Objection (and solution): Getting your code jacked

Marko Saric of Plausible:

We launched with what's called a permissive open-source license. When we started getting some buzz in different niche communities, we realized that there were some negative aspects of having a permissive open-source license (i.e. corporations were happy to take advantage of us).

There were cases of larger teams that took our code and used it to create and sell proprietary tools that directly competed with us. There were cases of corporations that wanted to resell our software without wanting to contribute anything back to the project. These were serious threats to the sustainability and longevity of our (at that stage) very young project.

Plausible is our first open-source venture that got any traction, so we were surprised by some of these issues and had to spend time researching and picking a license that better fit our needs.

I’m pretty new to the world of open-source licensing, so I ended up learning about AGPL only a few days before we officially switched. We haven’t had any other issues with this since we made that switch.

Richie McIlroy of reflio:

This is one of the questions that I used to ask myself when originally thinking about making an open-source product.

What helped me get over this was realizing that the value in a product isn't just in the code. Hear me out.

Anybody can theoretically build a product. If they can't build it themselves, then they can hire somebody else to build it.

What they can't steal is your mentality. If somebody copies your code and sets up their own product, you can almost guarantee they won't stick it out and it won't last longer than 6 months. If the person isn't committed enough to build out their own product, then they won't have the guts, determination, and willpower to build a real business. Source

Eddie Jaoude of Biodrop:

It is important to remember that behind any project and particularly a startup, is that there are so many other elements other than the code. There is the design, hosting, bug fixing, support tickets... the list is endless.

Objection: Takes longer to build

Eddie Jaoude of Biodrop:

I think it [actually] decreases the time because people really want to help and support the project to succeed. Later as the project gets more popular, there will be more notifications which might start to have a knock-on effect but let's be honest, this is a good problem to have.

Overall, what is your stance — would you recommend it?

Marko Saric of Plausible:

I would do it again and I would recommend it to others especially those that are in the privacy-first market, or those that are having a more technical audience as their market. Source

Iain Cambridge of Parthenon:

While there are many great things about open-source, I feel that one major issue is that people aren't getting paid for their work, and this results in a poorer product. A product that many companies depend on. These companies can afford to pay but choose not to. Many companies don't even contribute developer time back to projects they use heavily. Nor open-source any of their own internal libraries.

But while I think companies should pay, I think the ability for developers, charities, etc. to use code to build things makes for better developers and charities and, overall, a better world. I wouldn't be able to do what I do if it wasn't for someone providing me [with] free tools. So I want to be able to provide others with free tools while they build their projects. And if they can afford it, pay. Source

Justin Hunter of Perligo:

While I don’t think [my backlog of GitHub issues] was the reason Graphite failed, I am not interested in open-sourcing my new SaaS. Source

Caleb Porzio of AlplineJS

Sometimes open-source sucks. Sometimes it's awesome. Lately it's awesome ❤️ Source

Bram Wiepjes of Baserow:

I believe using an open development model helps us create more stable and secure technologies...

I’m an open-source advocate myself, some of the Baserow team members were our open-source contributors whom we hired, and we back up our belief by actively using open-source software like GitLab, Sentry, Visual Studio Code, Git, Discourse, Weblate, Proton mail, etc.

Eddie Jaoude of Biodrop:

Every company should make their project open source.

A tip for deciding: Be very clear on why your product needs to be open-source

Andrea Vacondio of PDFsam:

My advice would probably be to really think about the "why". Why OSS? If it's because you believe in OSS and its philosophy, then go for it. It's very fulfilling, you feel like one of the good guys, sharing knowledge and enabling others to do things with your project/library/software. You can also be part of a community with similar views etc.

If you are not 100% convinced, then it may become a source of frustration, it's very hard to find a way to squeeze money out of it. Many users don't even know what OSS is, they just see free stuff and that's a bit depressing. Moreover, many users feel like they are customers so you get comments or support requests that leave you with a "WTF?" feeling.

[Just] know what you are getting into. Source

Salai Vedha Viradhan of Blender-FreeCAD Live Link:

Think about how it could be a value proposition.

---

Subscribe for more how-tos, roundtables, and interviews with people in the thick of it.