When we took over maintenance of @turbodocx/html-to-docx and launched our open-source SDK ecosystem, people asked us: "Why invest so much in free software when you're building a commercial product?"
The answer is simple: Open source isn't a marketing strategy—it's a commitment to making better tools for everyone.
After thousands of npm downloads per month, hundreds of GitHub stars, and rapid growth powering production automation workflows, API integrations, and developer toolchains worldwide, I want to share why we're doubling down on our open-source commitment and what it means for the community.
How It Started: The @turbodocx/html-to-docx Journey
The story starts in 2019. I was building TurboDocx and needed a reliable way to convert HTML to Word documents. I found html-to-docx by privateOmega—a close friend I'd met years earlier. It was brilliant. Pure JavaScript, no browser automation, no external dependencies. Perfect for developers building APIs and automation workflows.
I started contributing PRs to improve it for our use case. Then life happened: I flew to India for his wedding, and what was supposed to be a quick trip turned into an incredible two-week journey—Delhi, the Taj Mahal in Agra, Jaipur. Experiencing the culture, riding the trains (which is an experience in itself), flying around in rickshaws. Somewhere between wedding celebrations and long conversations about technology and the world itself, the seeds of something bigger were planted.
Fast forward to 2021. TurboDocx was growing rapidly, and we needed enterprise-grade features that went beyond what the original library offered. Rather than fork it privately, we made a different choice: take over public maintenance and evolve it to be production-ready for companies running critical workloads. Developers were already integrating it into their automation workflows and custom API integrations—they deserved a maintained, reliable solution.
We'd built our careers on the backs of open-source tools created by people who chose to share. And this wasn't just any project—it was built by a friend. We chose to continue its development, make it enterprise-ready, and keep it free for everyone.
The Commitment
As an original contributor, I reached out to privateOmega about taking over maintenance. With his blessing, we published it under the @turbodocx scope on npm. Our commitment: keep it free and MIT-licensed forever. No paywalls, no enterprise-only features, no bait-and-switch. Just a reliable tool that developers could depend on.
Years later, through the ups and downs of the startup journey, that commitment hasn't wavered. If anything, we've doubled down.
What Happens When You Show Up
Something interesting happens when you commit to maintaining open source: the community shows up too. Not because they have to, but because they want to contribute to something that's genuinely helping people.
Better Software for Everyone
Thousands of developers testing in production means edge cases get found and fixed fast. The library became more robust because developers across different production scenarios—from automation platforms to API integrations—stress-tested it in ways we never could alone.
A Real Community Formed
Developers worldwide started contributing—not because we asked, but because they wanted to improve a tool they relied on. Bug fixes, performance improvements, new features. The community made it better for everyone.
Connections with Talented People
Some of our best team members found us through our open-source work. They'd already read the code, understood how we think, and shared our values about building in public. That's a far better signal than any interview.
Trust from Developers
When you maintain open source with integrity—no paywalls, no bait-and-switch—developers notice. That trust matters more than any marketing campaign ever could.
The Responsibility We Signed Up For
When people depend on your code—in their automation workflows, their API integrations, their production systems—you owe them reliability. Maintaining open source isn't just about shipping features. It's about showing up consistently.
- Responsive Maintenance: Developers using our tools in their automations and APIs deserve timely responses. We review PRs, triage issues, write docs, and cut releases regularly. It's not glamorous, but it's necessary.
- Patient Support: Not every GitHub issue is a valid bug. Some are learning opportunities. Some are misunderstandings. We try to help everyone, even if it means pointing them to the docs one more time.
- Stability Over Speed: When thousands of developers rely on your library—in their production automation workflows, their critical APIs—you can't just break things. Every change needs planning, deprecation notices, and migration paths.
- Security First: When a vulnerability is reported, everything else waits. Developers trust us with their production systems. That trust is sacred.
The responsibility is real. But when you help thousands of developers build better things, it's worth it.
Making It Sustainable for Everyone
Open source only works long-term if maintainers can sustain it. Burnout kills more projects than anything else. Here's how we think about sustainability:
Keep the Core Free
The core libraries stay MIT licensed, forever. If you need advanced features like our API platform with webhooks and enterprise capabilities, those help fund ongoing maintenance. But you never have to pay to use the open-source tools.
Build in Public
Our open-source libraries power our commercial product. When we improve one, we improve both. This alignment means we're incentivized to make the open-source code as good as possible.
Show Up Consistently
We respond to issues, merge good PRs, and ship releases regularly. This isn't a side project we'll abandon. It's a commitment.
Lessons from the Trenches
Write code you'd be proud to show anyone
Every commit is public. Every decision is visible. That pressure makes you a better engineer. You write clearer code, better docs, more thoughtful tests—not for your ego, but because people are counting on you.
Consistency builds community
Developers using your library in their automation workflows or API integrations don't need flashy features. They need to know you'll be there tomorrow. Respond to issues. Merge good PRs. Ship regular releases. Show up.
Protect the core, enable the edges
Every feature request sounds reasonable. But adding everything bloats the library and makes it harder to maintain. We focus on keeping the core solid and well-documented, then help people extend it for their specific needs.
Documentation is half the product
A developer integrating your library into their automation workflow shouldn't have to read the source code to figure out how it works. Good docs lower the barrier to entry and make the community more welcoming.
Our Open Source Ecosystem
@turbodocx/html-to-docx
MIT LicenseConvert HTML to Word documents. Zero dependencies, pure JavaScript, battle-tested in production by hundreds of companies.
n8n-nodes-turbodocx
MIT LicenseAutomate document generation in your n8n workflows. Generate documents, create templates, and integrate with 400+ n8n nodes.
The Bottom Line
Maintaining open source is hard. It takes time, focus, and patience. But when developers tell us they shipped a feature faster because @turbodocx/html-to-docx just worked, or that they built reliable automation with our tools—that makes it worth it.
Every bug report makes the library better for everyone. Every PR is a developer choosing to contribute instead of just consume. Every GitHub star is someone saying "this helped me."
What started with PRs on a friend's project, a wedding trip to India, and a long startup journey has become something bigger than we imagined. We built our careers on open source created by people who chose to share. Now it's our turn. And honestly? We're just getting started.
Show Up Consistently
Developers depend on you. Respond to issues, merge good PRs, ship regular releases. Reliability matters more than flashy features.
Keep It Sustainable
Burnout helps no one. Find a way to maintain the project without sacrificing your health or the community's trust.
Build for Everyone
Your library might power a developer's automation workflow, an API integration, or something you never imagined. Make it reliable, documented, and accessible.
Nicolas Fry
CEO & Founder, TurboDocx
Ready to Join the Movement?
Check out our open-source projects, contribute to the community, or use our tools to build something amazing.