This interview is part of the Decibel OSS Spotlight series where we showcase founders of fast-growing community-led projects that are solving really unique problems and experiencing strong community adoption.
Sudip Chakrabarti spoke to Tomer Barnea, co-creator of Novu, the open source project that is building a unified infrastructure to send notifications through multiple channels, including In-App, Push, Email, SMS, and Chat. Tomer is also the co-founder and CEO of Novu, the company that is commercializing the open source project.
Tomer shared with us his inspiration behind creating Novu and how he is keeping up with the fast growth of the project.
I have been a technical founder for nine years now and all that time I have worked together with my friend and co-founder Dima Grossman. We had built a couple of software companies together and a baking blog, and Novu is our third software venture together.
I have always been interested in cooking - the chemistry, biology and physics of it, not to mention the creativity, have always interested me. We got into baking and realized that there weren’t a lot of online resources on how to bake great bread. So, we partnered with one of the greatest Israeli bakers and started a tech-heavy baking blog called Oldough. Our goal is to serve as a home and a reliable source of information for the community of amateur and professional bakers. One of the cool things we built was a recipe generator so that you could get customized recipes for exactly the quantity of bread you want, without having to deal with leftovers. Later on, in the middle of the COVID pandemic, Dima and I also enrolled in a 6-month culinary course and cooked a lot together.
Yes! Of the three software ventures Dima and I have built together - not counting the baking blog of course - Novu is the only one that originated from our personal frustration and pain.
In both our previous software businesses, we had to build mechanisms to push SMS and email notifications, with advanced in-app experience and digest capability. So, we had a pretty good idea of how hard it was to build, customize and operate such notification infrastructures at scale. After exiting our last venture, I was advising a company and saw them struggle mightily to build a similar infrastructure over RSS feeds, trying to deliver personalized notifications to each individual user. And then another company asked us for help with exactly the same problem. At that point, we decided that we are going to solve this problem once and for all so that no other developer would need to reinvent the wheel when it comes to notifications.
The Novu project got started with a different name - Notifire - before we thought Novu was a better name and hence, switched it. But much more importantly, we had started by making a hugely mistaken assumption about our target user persona. We thought that because user experiences were masterminded by the product teams, product managers would care about how notifications worked across channels - SMS, email, in-app, etc. We were completely wrong! After pitching Novu to product teams at over a hundred companies, we realized that it was actually the development teams that were responsible for implementing and maintaining notification workflows. The developers were the ones who owned and hence really cared about a unified notification infrastructure. And, they were all struggling! That realization had a profound impact on everything we did subsequently - the design of the product, the on-boarding experience and our go-to-market strategy. I am really glad that we had learnt that extremely valuable lesson very early on because it completely changed our thinking and plans.
Novu provides a notification infrastructure that simplifies sending notifications through multiple channels, including In-App, Push, Email, SMS, and Chat. With Novu, you can create custom workflows and define conditions for each channel, ensuring that your notifications are delivered in the most effective way possible.
As I had mentioned before, Novu was born out of our own frustrations. In our prior lives, we had to build our own notification infrastructure multiple times. Large companies spend years building (and rebuilding) notification infrastructures and we wanted to bring that same capability to every company, small or large. There are a host of communication tools out there — SendGrid for email, Twilio for SMS, Slack for direct messaging, etc. Those tools can be customized to fit the company’s and the users’ specific needs and goals. But this forces developers to manage all of those APIs across the codebase, leading to hundreds of modifications and rules hard-coded into their code.
Novu simplifies all of that by providing a unified infrastructure that integrates with Twilio, SendGrid, MailChip and other delivery providers responsible for actually delivering the notifications on a specified channel according to the users’ preferences. Each provider is stateless and adheres to a specific interface, while Novu manages state and mediates across all providers using rules and filters, priorities and other metadata that affect the delivery of a specific message. Developers can embed Novu as a React, Angular, Vue component or an iFrame using community-built SDKs in multiple languages.
Once we identified developers as our core users, making Novu open source was a no-brainer. If you are building a solution for a developer and expect your solution to be part of the technical stack, then you must open source. There really aren't a lot of other ways for a developer platform to become best practice without being open source. If you want engineers to adopt your solution, you will need them to join the community and build with you.
We indeed have a rapidly growing community that is building and using Novu. Last time I checked, we had over 19,000 stars and 250 contributors on GitHub. One thing that has gone right for us is that we have been able to tap into several adjacent communities, partly because the problem we are solving is so universal, and partly because we were intentional about it. Lots of folks building open source projects sometimes miss the fact that it is very hard to create a new community from scratch, but it is much easier to grow an existing one. Hence, if you are able to tap into the community or communities that you believe might care about the problem you are solving you can accelerate your adoption exponentially. In our case, multi-channel notification is a problem that interests a lot of communities working on programming languages and frameworks. We were fortunate enough to tap into those, and that has led to a lot of our early exponential community adoption.
Looking back, I would have prioritized communicating with the open source community even more than what we had done in the early days. For example, we initially had two different Slack channels for engineers building Novu - one that was for the internal engineering team and another that was external and was for the community. That was a mistake. While we had a ton of product roadmap and architectural discussions on the internal channel, the broader community was largely left in the dark. As a result, the community had little visibility into what was being developed, what was being worked on, and what problems were being considered. And of course, we were unable to benefit from any insight from the community. Once we realized our mistake, we moved everything to a single public engineering channel where everyone can see everything we are working on and can collaborate much more effectively. The resulting benefits have been so great that I wish we had done it sooner!
I actually love any open source project that is welcoming, fun and trying to solve an engineering problem. I know how hard it is to build such projects and a thriving community; so, I have a lot of admiration for all. That said, three projects I follow closely are Cal.com, Posthog and Medusa. I think that we all are trying to build something similar in our respective niches and therefore, I have learnt a lot from all those projects and the fantastic open source communities they have built.
I have two. First, if you want to build just an open source library that is one thing. But, if you are planning to build a business around the open source project you have created then you must evaluate everything very differently. First, you must convince yourself - before asking anyone for any investment - that there is a viable business opportunity here. You will be spending years building the project and the business; so, you must think through carefully. Second, be clear with your open source community about what will stay in open source and what might be commercialized. Open source communities are wonderful and loving, but if you lose their trust then they will move on just as fast. But when you communicate clearly and earn their trust, thriving communities can accelerate the development and adoption of your open source project so much faster than anything else can.