TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Open Source Is Ready for the Application Layer

2 pointsby hekikeabout 2 months ago
Open source has always been a big part of my career. I worked and maintained multiple Node.js libraries, joined the Node.js Diagnostics WG, and am now building OpenMeter. So I&#x27;m probably biased, but I think we reached a new inflection point with open source. The infrastructure layer, coding languages, and frameworks are all de facto open - what&#x27;s next? Services that help teams build ‘applications’, like analytics and billing. Let me explain why I think this way:<p>Let’s look at billing as a use case, as this is what I’ve recently focused on. Billing is like choosing a cloud provider. It’s for life, hard to change, and dictates what kind of sales deals you can execute. Building requires lots of code and integration, and you lose money when it breaks. This is why you need to be strategic about it.<p>These three issues must be carefully considered when deciding if you should go with open-source:<p>1. Your use cases will evolve, and so will your dependencies<p>For example, every startup goes through an evolution of product packaging and billing requirements for their self-service credit card sales:<p>a. Early-stage startups usually hardcode pricing into their app to get started quickly b. During the growth stage, requirements for pricing models change, and now code is scattered between the billing platform and your product code c. When you become an enterprise, your sales team wants more flexibility to quickly structure custom deals and visibility in the CRM, like Salesforce<p>But as your company grows, you have now gone through all three stages, and your product catalog is all over the place: in your code, billing platform, and Salesforce. This is why you should build on extendable open-source components.<p>2. Beware of vendor lock-in<p>For example, billing is for life. This code becomes the revenue lifeblood of your company and is not easy to replace. That calls for no vendor lock-in and maximum business flexibility. Big vendors tend to push up prices at renewal time. It’s not a risk with open-source applications.<p>3. Mission-critical, and therefore strategic, components should be Open Source<p>As you evolve your pricing and sales motion, you produce large amounts of new code tied to the billing solution. This is problematic because open source will always outpace and out-innovate closed-source vendors over time. But now you are stuck with proprietary integrations, which become an expensive challenge over time.<p>—<p>This sounds like infrastructure, right? As an industry, we have already agreed that infrastructure should be open-source. Are more things becoming infrastructure as applications become more complex, or is it a progression that open-source evolves to include application services? Time will tell.<p>One thing is for sure: open source reduces cost and vendor lock-in while increasing customization options and talent density. This is helpful in every layer of your business stack and an insurance policy against poor vendor behavior.

no comments

no comments