10 lessons on how we got to +16,000 GitHub stars in 16 months with . Medusa It has only been a year and a half since we fully open-sourced Medusa with the quest of building the best OS commerce engine for developers with Medusa. Since then, we have managed to gather: project starts +25,000 monthly npm downloads +20,000 GH stars +16,000 community members +5,000 $ in Seed funding 8M Below are some of my takeaways on how we built strong early traction as an OS project. What is Medusa Medusa aims to redefine the way ecommerce is built. Too often, developers are locked into platforms, hacking their way through a setup they have little ownership over. Our mission is to give developers the right primitives to build, deploy, and maintain commerce easily and reliably. We want to provide the architectural building blocks to build bespoke and modularized commerce applications with no platform lock-in. Repo: 🌟 github.com/medusajs/medusa TL;DR - 10 OS Lessons Solve a problem that hurts : Ensure you understand the user pain point you are trying to solve. Clear user pain point What you are building needs to be clearly differentiated from what is already out there. No good alternatives: Ask yourself whether an OS solution is needed or if proprietary solutions actually solve it. Why it must be open source: Create a delightful product experience It can be easy to get distracted, so keep focusing on your core product priorities. A focused product approach: Building traction requires you to ensure your community feels your commitment to their success. Support your community: Make it easy to get started with Docs, quick onboarding flows and supporting tools. Invest in your DevEx: Get the word out there Have a simple product description ready that makes it easy to comprehend what you are building. Make it easy to understand: Ensure your product gets attention in forums and blogs where developers are present. Focus on dev channels: Prioritize events you know have the potential to send your product viral and make sure you execute these well. Make big bets and follow through: Build content that is authentic and useful to developers instead of regular marketing messages Make it authentic: Below I will go into a bit more depth with each of these steps Find a problem that hurts Your project must address a pain point for developers that really are meaningful to them. Three things to watch out for are: In the world of ecommerce, we knew from experience how painful the developer experience was with many proprietary tools (e.g. Shopify) and legacy open source tools (e.g. Magento and Woo). All of them build with an all-in-one monolith architecture, that forces developers to pursue hacky workarounds for customizations and new integrations. Having experienced the pain points ourselves from our previous careers made it easier to verify, that there indeed was a problem to solve in this space. Clear user pain point: Make sure you understand the user pain point you are trying to solve. In our view, the ecommerce landscape seemed to crave innovation. API-first solutions like Elasticpath, Commercetools, etc. seemed to focus on enterprise sales and less so on developer experience while their proprietary nature made it difficult for them to offer the same customization options as an OS tool. On the open source side, most existing solutions were offering PHP-based backends staying out-of-touch with modern developers, and no one had nailed it with a JS-based alternative yet. No good alternatives: What you are building needs to clearly differentiated from what is already out there. It can be tempting to assume that open source is always the path forward, but it might not always hold true. With ecommerce platforms, the complication is that user needs vary a lot for different business types (e.g. just from serving B2C to B2B customers) and this means a proprietary one-fits-all-solution is seldom the right path when a use case is a bit outside the box - which explains why more than half of the world largest ecommerce sites are still built with a custom or open-source commerce backends. Why does it need to be open source: Ask yourself whether an OS solution is needed in the space, or if proprietary solutions actually solve it. Create a delightful product experience Identifying the problem is not merely enough. Building a product to solve it and investing in the community and DevEx around it is also key. Building open source, the community will have lots of opinions on additional features, plugins or functionalities to build. Some of this feedback will be less relevant to your core audience. Therefore, be selective of the inputs you get and build the few features that will make a meaningful impact for your core audience instead of a lot of half-decent features for everyone. A focused product approach: It can be easy to get distracted, so keep the focus on your core product priorities. From our early days, we have been razor focused on our community. We do this through a wide array of activities from community events to our transparent product discussions to our continuous focus on building community support materials. Likewise, we are dedicating a lot of time to answering community inquiries on GitHub and Discord helping devs get started. Support your community: Building traction requires you to ensure that your community feels your commitment to their success. We prioritize the developer experience by putting a lot of focus into areas such as our Documentation - which we treat as a product of its own with a full-time team member dedicated to it - while ensuring that our onboarding flow is easy to get through with supporting project starter templates. Invest in your DevEx: Make it easy to get started with Docs, quick onboarding flows and supporting tools. Get the word out there When you have a great developer experience set up, your key task becomes to create awareness around the project. We focused a lot of our messaging around being "the open source Shopify alternative" which instantly resonated with developers (see e.g. our HN launch). In reality, Medusa is much more than open source Shopify as our modular architecture better fits more bespoke ecommerce cases than typical "mom and pops" Shopify stores. Yet, the simplicity of the messaging made it easy for developers to categorize the solution when quickly hearing about it for the first time. Make it easy to understand: Have a simple product description ready that makes it easy to comprehend what you are building. We have always remained focused on developer channels and spent energy creating content and initiatives to target these; e.g. leveraging Reddit to make a lot of "mini launches" or setting up a Writers Program to produce content for channels like , Medium and Hashnode. Other tools like Supabase focuses on Twitter, while Digital Ocean is a prime example of own channel content done right. Focus on dev channels: Ensure your product gets attention in forums and blogs where developers are present. Dev.to Once in a while, we have events we believe have the potential to make Medusa go viral, e.g. ProductHunt launch, Series Seed investment announcement or our recent Medusa Hackathon. For all of them, we prioritized planning ahead and making a structured campaign around it to ensure maximal exposure, sometimes preparing videos, announcement content, and website updates weeks or months in advance. Make big bets and follow through: Prioritize events you know have the potential to send your product viral and make sure you execute these well. Since starting, we have not spend a single dollar on ads for Medusa. Instead, we focused our resources on building content that was authentic to developers through articles and tutorials that were centered around explaining what our product did instead of more sales-oriented messaging. 10) Make it authentic: Build content that is authentic and useful to developers instead of regular marketing messages. A word of caution I hope the above gave some useful inputs from our journey. One last disclaimer: In all honesty, GH stars can be a bit of a vanity measure for a project's popularity when used as a standalone metric. I will be an advocate for looking into more usage-related metrics as well such as project starts, active developers, monthly contributors etc. Where GitHub stars do serve as a fine indicator is to understand if people are interested in what you are building - and it is one of the few OS metrics that are comparable across projects. A version of this article appears . here
