Today, erxes had the opportunity to chat with Sanket Sahu about his involvement in various open and closed source projects. His project NativeBase is currently used by over 37,000 projects. Sanket uses a very unique approach to monetization and balancing multiple projects at once. So let’s jump into the interview to learn more!

The Interview

Hello and thank you for joining us today. You’re deeply involved in the world of programming and already have many popular projects online, including BuilderX, NativeBase, Vue Native, React Native Seed, and you also run the NativeBase Market. If that wasn’t enough, you also contribute to many more open source projects. Can you kick off the interview by telling us a little bit more about how you got involved in the open-source space? What was it about the open-source community that drew you in and never let you go?

Whenever I have encountered problems in life it has always led me to build solutions that have not only worked for me but also for others. It was only through pure serendipity that I entered the world of open-source and started building communities. Getting involved with open-source has been a two-way street; in fact, it’s more receiving than giving. When we, at GeekyAnts, put our projects out there, the community responds, challenging our thought process and decisions. Something that starts out as an experiment, ends up helping so many, and in turn building a better community, and that’s what has kept me hooked.

You also run a development studio where you help clients build projects. You have so many accomplishments under your belt. Can you tell us a little bit more about how you’ve approached growing your portfolio of projects? What did you start with, and how many projects do you try to release per year (in-house)? How do you approach scaling, and how do you know when to add a new product to your portfolio?

Yes, GeekyAnts is a product studio that means we not only work on exciting internal projects but also develop products for our clients. At the core, we are driven by experiments, side-projects and R&D. These practices have been the entry point for open source contributions, and it has worked as a growth-hack for the development studio.

In simple terms, the mantra that has worked for us is a cycle:

It all started with the rise of Bootstrap CSS. We fell in love with a community project called StartBootstrap, a platform for free static dashboard themes built using HTML & Bootstrap CSS. Soon after AngularJS picked up the market of Single Page Applications and we made our first free dashboard theme for AngularJS called as SB Admin Angular, and we hosted it on our open platform called as StartAngular.com. Over the years, we have contributed to other technologies with similar platforms like StartReact.com, StartLaravel.com and the recently announced StartSvelte.com.

Starting early with React Native not only helped us enter the mobile app development space but being an early adopter meant that the ecosystem wasn’t mature enough, and there was a lot of room for contribution. We built some apps and later pulled out the reusable components from those apps to a repo which later became our most popular open-source project, called NativeBase.

We don’t have a plan for the number of projects we start every year. We keep looking. We jump in whenever there is a need.

When did the agency come along? How do you balance creating in-house projects with client projects? What percentage of your time does each take up?

The agency has a bit of history. It was incorporated by Pratik right after he majored in Computer Science, way back in 2006. The name of the company was Sahusoft. We were mainly a web-dev shop skilled in PHP & MySQL. We were less than a dozen people, and we had a few clients in the US & Europe. The agency slowed down with the 2009-slowdown, and it was when most of the employees moved out.

After a few years, in 2014, we gathered the courage to revive everything. We started a new company with a new mindset with the learnings of the past; we called it GeekyAnts. We kept experiments, open-source & dev-community at the centre of the company. It changed everything!

We had the formula of 70-30 where 70% of the workforce work on client projects which ensures that cash flow is coming in, and during the rest of the time (30%) we work on R&D and experiments. The 70-30 divide isn’t very strict. Strict rules curb creativity. We shuffle our members from time-to-time between teams, projects and technologies.

Let’s talk a little bit more about monetization for a moment. I think you have a really interesting monetization model. I’m sure I’m not even seeing the full picture. But let’s jump in and talk about the NativeBase Market. Can you tell us when you launched the marketplace? How have you gone about building the marketplace up in terms of product offerings?

NativeBase Market is a marketplace for developers to buy and sell React Native App source-code. It’s a closed-platform. It was announced after a few months of the initial release of NativeBase. The market works on a commission-based model where we charge a commission on each sale made on the platform. The offerings range from UI starter kits to full apps with a backend. The full-apps include location-based apps, social apps and e-commerce solutions, all based on NativeBase and React Native.

What other open source monetization models do you use to help you drive growth? I’m sure your agency work helps you fund projects, but how do you get your open source projects to a point where they are self-sustaining financially?

Other than NativeBase Market, we don’t have any direct open-source monetization model. Open source has largely helped our agency to build a brand and trust for our customers. Agency remains the primary source of funds for all our projects, internal and external.

NativeBase can be considered as self-sustaining financially with the help of NativeBase Market. But it doesn’t mean that it is very profitable, it keeps fluctuating every quarter above and below the breakeven point.

So you have to get creative. For example, I would like to give a shoutout to initiatives like OpenCollective that are helping indie-developers and small companies with backing. For, e.g., Our project, Vue Native, receives $100 per month by Concreit to support the project.

You’re also not only working in the open-source space. Some of your projects are closed source. BuilderX, for example, is closed source and monetized through a subscription model. When analyzing a project idea, how do you know if you’ll work on it as an open-source or closed source project? What’s the logic behind your decision?

It depends, open-source gives gratification and works well for popularity. It’s hard to monetize immediately, but it has a long-term effect. For example, Adam Wathan and team created Tailwind CSS, a utility first open-source CSS framework. It took 2.5 years to mature and gain popularity, and it was a couple of weeks ago they announced Tailwind UI, a closed-source set of UI components built using Tailwind CSS. They made sales of $500,000 in the first three days of announcement.

In the case of BuilderX, it’s a different story. It’s a tool that helps designers and developers, but it can’t be a direct dependency in their workflows like an npm package or a plugin. The source-code of BuilderX doesn’t directly help the developers either. The output what it generates matters to the users. It’s more like a platform, and that’s why it wouldn’t add a lot of value as an open-source project.

NativeBase, on the other hand, is an open-source project with over 100 contributors and over 13,000 stars! Well done. Because you work in both open source and closed source projects, what are the most important lessons that you think that open source projects should learn from closed source projects?

Thank you so much! Closed-source projects usually have a business model attached to it that involuntary adds seriousness and responsibility. On the other hand, open-source projects usually start as fun side-projects. As soon as these open-source projects gain popularity, the responsibility inflates. The creators don’t often realize the scale of such responsibilities. E.g., NativeBase is used by over 37,000 projects, that makes me feel spirited but scares me at the same time.

Like closed-source projects, open-source projects can also have a business model attached to it, not a direct one but more like providing a platform or a service for the solution. For, e.g., WordPress is an open-source project and the parent company Automattic is valued as a unicorn.

What are the biggest lessons that closed source projects should learn from open source projects?

Open source projects receive immediate feedback from the community, and they evolve very fast with the input. Closed-source projects can learn to accept feedback early and improve in iterations.

Big companies like Microsoft have also learnt a lot from the open-source community. A company that has evolved from a license-based closed-source software company to a company that has now put open-source at its heart with great projects like VSCode, TypeScript & React Native for Windows. They are making open source as a channel for developers to build great apps for their platforms using their Cloud Services.

Let’s talk about growth for a moment. What are your three most valuable organic growth channels?

Not three, but we have the four most valuable organic growth channels.

1. Community building: Articles, Discord, Reddit
2. Speaking Engagements: Meetups & Conferences
3. Engineering as Marketing: Technical articles, Github readme
4. Search Engine Optimization

If you had to double down on just one channel, which would it be and why?

For GeekyAnts as an agency, I would double down on “Engineering as Marketing” because our services are very technical and that adds a lot of value to the community members and also builds brand and trust for all the demographics.

For a product like BuilderX, it would be “Direct Sales” as we are very clear about our end-users and who we want to reach out to.

Lastly, if you could go back in time and give a younger version of yourself three pieces of advice about what it takes to run a successful open source project, what would those three pieces of advice be and why?

The three pieces of advice would be

1. Documentation: The success of an open-source project largely depends on how well it is documented including installation steps, the use-cases, the APIs, the shortcomings, the demo, screenshots and GIFs.
2. Quality: High-quality solutions with consistent APIs backed with proper reasoning and design philosophies give confidence to the end-user.
3. Maintenance: Attending issues, merging PRs and writing the proper roadmap of the project is a great way to maintain the project. Most of the developers quickly lose interest after the first significant release. Try to overcome that and keep improving after the first release with patches and minor releases.

Thank you for taking the time to chat with erxes today. We really appreciate it.

To our blog readers, if you’d like to learn more about Sanket and the many projects he manages, you can follow him on GeekyAnts or head over the NativeBase project here.