Most companies treat open source as charity. They contribute code, build community goodwill, and hope something comes back eventually. At BlackBox Vision, we discovered — almost by accident — that open source can be a deliberate, repeatable source of business. Not through sponsorships or donations, but through the trust and visibility that a well-maintained library creates.
This is the story of how a single React Native package led to five client projects, dozens of third-party integrations, and a paid services model that continues to generate revenue years later.
The problem: payments in React Native
Several of our clients needed to integrate MercadoPago — Latin America's dominant payment platform — into their React Native applications. The checkout flow had to be native. Not a WebView, not an embedded browser. A fully native UI.
This wasn't a preference. It was a hard requirement. Apple was actively rejecting apps that used WebViews for payment processing. If you wanted your app approved on the App Store, you had to use the native SDK.
The challenge was that MercadoPago provided SDKs for Android (Java/Kotlin) and iOS (Swift/Objective-C), but nothing for React Native. Every team that needed this integration had to write their own bridge between JavaScript and the native layers — a painful, error-prone process that required deep knowledge of both platforms.
We were already doing this work for a healthtech client. They needed MercadoPago integrated into their app, and the constraint was clear: native UI only. So we built the bridge.
The decision to open source
After completing the integration for our client, we had a choice. We could keep the code private and rebuild it every time a new client needed the same thing. Or we could clean it up, document it, and release it to the community.
We chose open source.
React Native MercadoPago PX was born as a library that let any React Native developer integrate MercadoPago's checkout into their app with minimal effort. The bridge handled the complexity of communicating between JavaScript and the native SDKs on both Android and iOS.
But shipping a library wasn't enough. We knew from experience that integration libraries live or die by their documentation.
Documentation as a product
We built a dedicated documentation site with step-by-step installation guides, platform-specific configuration instructions, troubleshooting for common issues, and clear prerequisites. The goal was to make the library usable by any developer, not just the ones who happened to understand native module linking.
This was a deliberate investment. Good documentation reduces support burden, increases adoption, and — critically — builds trust. When a developer lands on your docs and everything just works, they remember who built it.
How open source became a sales channel
Here's where things got interesting. Once the library gained traction, we started hearing from companies that fell into two categories:
Companies without mobile developers
Many startups and small companies had web developers who were using React Native to build mobile apps. They could handle most of the app, but integrating a native SDK was beyond their skill set. They didn't know how to configure Gradle files, CocoaPods, or native module linking.
For these companies, we offered a paid installation service. We'd set up the library in their project, configure both platforms, run the integration tests, and hand back a working checkout flow. What might take an inexperienced team days or weeks took us hours.
Companies with developers stuck on compatibility issues
Other companies had capable React Native developers, but they were fighting version compatibility problems. React Native's ecosystem moves fast, and native dependencies break across versions. We saw teams spend weeks — sometimes months — trying to resolve build errors caused by mismatched dependency versions.
For these companies, we offered a technical support service. We'd diagnose the compatibility issues, fix the build configuration, and ensure everything worked across both platforms and the latest React Native version.
The numbers
Over time, at least five client projects came directly from the library. These weren't small engagements — they were full integration projects where the initial contact was "we're using your library and need help."
Today, 33 repositories and 3 third-party packages depend on React Native MercadoPago PX. Every one of those represents a developer or team that chose our solution over building their own.
The business model: free library, paid expertise
The model that emerged was straightforward:
- The library is free. Anyone can install it, use it, and contribute to it. This maximizes adoption and visibility.
- Installation services are paid. For teams that need hands-on setup, we offer a fast, reliable integration service.
- Technical support is paid. For teams fighting compatibility issues or edge cases, we offer expert troubleshooting.
- Full projects come naturally. Teams that have a good experience with the library and services often come back for larger engagements.
This isn't a loss-leader strategy where you give away something hoping to upsell. The library genuinely solves a problem. The paid services address the gaps that inevitably exist between "here's a library" and "this works perfectly in my specific project."
Why open source builds trust
There's a reason this works better than traditional marketing. When a potential client evaluates your company, they're asking: "Can these people actually build what I need?"
Open source answers that question before the first meeting. Your code is public. Your documentation is public. Your issue responses, pull request reviews, and release notes are all public. A CTO evaluating your company can read your code and form an opinion before ever sending an email.
This is trust that no case study, testimonial, or sales deck can replicate. It's earned through demonstrated competence, not claimed expertise.
A practical framework for turning OSS into business
If you're considering open source as a business channel, here's what we've learned:
1. Solve a real, recurring pain point
Don't open source internal tools that only matter to your team. Find a problem that multiple companies face repeatedly. Payment integrations, authentication flows, complex UI components — anything that developers need but don't want to build from scratch.
2. Invest in documentation like it's a product
Your docs are your storefront. If a developer can't get your library working in 15 minutes, they'll find an alternative. Write clear installation guides, provide working examples, and document every common error.
3. Design natural paid service tiers
Identify where developers are likely to get stuck even with good documentation. Those friction points are your service opportunities. Installation, configuration, compatibility fixes, and custom extensions are all natural paid offerings.
4. Maintain the library consistently
Nothing kills trust faster than an abandoned repo. Respond to issues, merge reasonable PRs, and keep up with ecosystem changes. Active maintenance signals that your company is reliable and invested.
5. Let the library market itself
Don't hard-sell through your open source projects. Let the quality of the work speak. Add a tasteful "Built by [Company]" note in the README and link to your services page. Developers are allergic to overt marketing in open source — earned trust converts far better than pushed messaging.
Open source is not just for techies
The most important takeaway from our experience is that open source isn't a developer hobby. It's a business strategy. When executed well, it creates a flywheel: the library attracts developers, developers become users, users become clients, and clients fund further development of the library.
You don't need to build the next Kubernetes or TensorFlow. A focused, well-maintained library that solves a specific problem for a specific audience can generate more business value than any marketing campaign.
The key is to approach it with intention. Don't just throw code over the wall and hope for the best. Treat your open source project like a product — because that's exactly what it is.
