#143 — How to start an open-source startup

Expect 6-8 weeks minimum for a proper launch—2 weeks for foundation (vision, goals, license selection), 3-4 weeks for code prep and documentation, plus ongoing community building. Companies like Redis and Apache took months to establish initial community traction. Rushing launches without proper docs is the #1 mistake that kills OSS projects.

Apache 2.0 includes explicit patent protection and requires stating code modifications, while MIT is simpler with fewer conditions. Choose Apache 2.0 if you're in patent-heavy spaces (databases, infrastructure, AI/ML) or expect enterprise adoption. Choose MIT for maximum simplicity and adoption velocity—it's preferred for libraries and developer tools where friction kills adoption.

Technically yes, but it's extremely risky. Redis switched from BSD to dual RSALv2/SSPLv1 in 2024, and MongoDB changed to SSPL—both sparked major community backlash and competitive forks. HashiCorp faced similar issues. License changes signal broken trust and often accelerate the very fragmentation you're trying to prevent. Build your monetization model before launching, not after.

Budget for 1-2 full-time employees minimum: one for code maintenance (bug fixes, dependency updates, security patches) and one for community management (responding to issues, reviewing PRs, documentation). Red Hat invested heavily in community before profitability, taking years to reach its 2012 milestone of $1 billion in revenue. Underfunding community work is why most OSS startups fail.

Fork if the existing project is 85%+ of what you need but abandoned, poorly maintained, or heading in a conflicting direction. Successful forks include X.org from XFree86, WebKit from KHTML, and CentOS from RHEL. Start from scratch if you're solving a fundamentally different problem—forking inherits technical debt and community expectations that may constrain your vision.

The top three fatal errors: Not asking users what they'll pay for (building features nobody buys), attempting too much too soon with limited resources, and chatting about perfection instead of shipping MVPs. Many founders won't even pay for their own premium product because they're not the target customer—a massive red flag for product-market fit.

Track active contributors (not just GitHub stars), issue response time, PR merge rate, and commercial conversion percentage. Red Hat took 13 years from founding (1999) to hit $1B revenue. Apache HTTP Server grew to power millions of web servers by focusing on community documentation and support. If you're not seeing regular external contributions within 6 months, your project likely has poor docs or unclear contribution guidelines.

Yes, but you need aggressive differentiation in your paid tier. Redis, MongoDB, and Elastic all changed licenses specifically because cloud providers commoditized their core offerings. The solution isn't just licensing—it's building premium features (security, compliance, performance, integrations) that cloud providers can't easily replicate. Cloudera and Confluent succeeded with hybrid open core + professional services models.

Stars are a vanity metric—investors care more about contributor growth rate, enterprise adoption signals (Fortune 500 using it), and clear path to revenue. GitLab reached Series A with strong community engagement, not just stars. Focus on 'good first issues' completion rate, external PR acceptance rate, and converting users to paid customers. A project with 1,000 engaged contributors beats 50,000 passive stargazers.

GitHub Discussions for searchable Q&A, Discord for real-time community building, Slack if you're B2B enterprise (where buyers already live). Apache, Linux, and Kubernetes use mailing lists for permanence and searchability. Avoid fragmenting your community—pick one primary channel. Dead/slow-response channels kill credibility faster than no channel at all.

OSS-first means community comes before revenue—you're building distribution and brand through open source from day one (like Redis, GitLab). OSS-late means starting proprietary, then open-sourcing after achieving product-market fit. OSS-first requires 18-24 months of runway before meaningful revenue. OSS-late loses the community distribution advantage but validates commercial viability faster. You cannot pivot between them without major disruption.

You don't—and that's the point. Forkability is a feature, not a bug. Instead, focus on moving faster than forks (Redis, Elastic), building stronger community relationships (Apache), or creating proprietary integrations that are hard to replicate. If your only competitive advantage is closed code, you don't have a defensible business. The best defense is aggressive innovation and community engagement that forks can't match.

PostHog reached 300 deployments in days after launching on Hacker News with

Yes, if you plan to commercialize or need legal protection. A CLA grants you perpetual license to use contributions while contributors retain ownership. Apache, OpenProject, and PKP all require CLAs. Without one, contributors can dispute commercial use of their code. Set this up before accepting external contributions—retrofitting CLAs after the fact creates friction and trust issues with existing contributors.

Track activity (PR velocity, ratio of new:closed issues), community size (contributors, not stars), code performance benchmarks, security vulnerabilities (CVE count), backlog health, and time-to-close for issues. Key KPIs: external contribution rate, contributor diversity, deployment numbers, time between releases, and commercial conversion rate. Use GitHub Analytics, Bitergia dashboards, or Black Duck for automated tracking.

Use both—GitHub Sponsors integrates directly with repositories and charges 0% fees, while Open Collective provides fiscal hosting and transparent budget management with 10% fees. Open Collective + GitHub partnership enables automatic monthly payouts. GitHub Sponsors works best for individual maintainers; Open Collective suits projects needing organizational structure, expense tracking, and nonprofit status. JSON Schema uses both simultaneously.

Dual licensing releases software under both an open source license (GPL) and a proprietary commercial license. MySQL and Qt pioneered this model. Use it when you want community adoption via GPL but need commercial revenue from enterprises integrating into proprietary products. The tradeoff: managing two codebases and ensuring contributions comply with both licenses. Ghostscript abandoned dual licensing for AGPL due to complexity.

Uno Platform raised $3.5M CAD seed from AQC Capital and Scott Hanselman with Apache 2.0 core plus premium add-ons. Other OSS-friendly investors include Sequoia, Google Ventures, YC, and M12. Pitch OSS as distribution strategy, not just product—show how open core drives bottom-up adoption that converts to enterprise deals. Investors want to see contributor growth rate, enterprise pipeline, and clear differentiation between free and paid tiers.

Your README needs five elements in under 3 minutes of reading: what problem you solve (1 sentence), installation (copy-paste commands), basic usage example (real code), link to CONTRIBUTING file, and badges showing build status/test coverage. Tag 'good first issues' for newcomers. Projects with 1,000+ contributors emphasize well-documented contribution workflows and responsive issue management. Poor docs kill 90% of potential contributions.

GitHub for maximum visibility—it has the largest developer community and best discoverability through trending repos. GitLab if you need built-in CI/CD and self-hosting options. Bitbucket if your team is Atlassian-native. GitHub's network effects matter: PostHog got 300 deployments by trending on GitHub. Don't fragment across platforms—pick one and commit fully to its ecosystem.

Transition when you hit three signals simultaneously: 50+ active external contributors per month, 5+ enterprise users asking for paid features, and 20+ hours weekly spent on maintenance. If you're turning down commercial opportunities because you lack time/resources, it's time to fundraise. Uno Platform raised seed after establishing business model sustainability. Don't raise too early—investors want proof of commercial demand, not just GitHub stars.

Launch simultaneously on Product Hunt, Hacker News, and relevant subreddits. List in Open Source Collective directories, Awesome Lists for your tech stack, and AlternativeTo if you're replacing proprietary software. For dev tools, post on DevTo, HashNode, and relevant Discord servers. Submit to GitHub Explore trending. Time launches for Tuesday-Thursday 9-11 AM PT when tech communities are most active.

Allocate 60% time to OSS core, 40% to premium features until you reach $100K ARR, then shift to 40/60. Never let OSS core stagnate—it's your distribution engine. GitLab maintains feature parity timelines to prevent OSS from lagging. The fatal mistake: building premium features nobody will pay for because you didn't validate commercial demand first. Survey enterprise users quarterly about paid feature priorities.