Making open-source development work for businesses

Open-source software suffers from a tragedy of commons. Since the benefits are diffused and costs are concentrated, it does not receive the investment that's proportionate to the amount of value it generates for its users. Things really are in a bad shape.

Like all tragedies of commons, this cannot be solved merely by private efforts. If you do OSS development in-house, you'd be burning money for little return on investment. If a feature or bugfix, that costs 1,000$ but generates 800$ of value for 100 businesses, your personal RoI would still be a loss of 20%.

What's usually needed to get out of such logjams is coordination - either by regulations or by network effects. We're a FOSS-only software development agency who's trying to make network effects work by distributing costs over multiple customers.

We work pretty much like a software development agency. Your team sends a list of issues in your open-source software dependencies that matter to you, your CTO allocates a budget and sets priorities. What's different though is that we pick up the tasks for which we can find multiple customers. If you want a new feature in Django which is popular, you'll get this at a fraction of the cost. But if you want us to improve some obscure library, the pricing adjusts in proportion.

We reduce the costs further by leveraging a community of remote, part-time developers, including the open-source maintainers and developers themselves.

Now, there are some key things to keep in mind. Our pricing model has two components. Part of the payment is about developing the feature in our own branch. This is in our control and once we have picked up this task, we can guarantee delivering at least this much. However, due to the nature of open-source, we cannot always guarantee that our changes will be merged in the upstream repository. Perhaps the developers of the FOSS project don't want to cannibalize their premium, non-FOSS version, or perhaps they disagree with the approach of our implementation and so on. This risk is very real.

This is where our pricing model comes in for aligning incentives. We receive 30% of the cost ONLY if our work gets accepted in the upstream repo. This is the model we've found to work for both us and our clients to make this a sustainable offering. On a standalone basis, this would be too risky for us. We solve this via volume using a seat-based pricing model which guarantees us some consistency of work. To use some rough numbers, you pay us 1/3rd of a full-time, in-house developer's cost but get 2/3rd of their output in return. And what's more: All the work produced in this way, remains open-source. We are a bit picky in choosing our clients and are only interested in working with businesses which uses enough open-source software that can justify at least one employee worth of effort per month.

Frequently Asked Questions

What if the upstream does not merge your pull requests?

This is a valid concern due to the nature of FOSS projects. Our points-based model accounts for this and aligns incentives. We get paid 70% on feature-completion and the rest 30% on upstream merge.

Who are the developers?

We have an open, remote team of 60+ developers (and growing) - covering skills such as Java, Python, Javascript, Ruby, Swift and much more. Remote work allows us to find the best talent from all over the world and we can pass on the benefits to you.

Can we pay per-task instead of per-seat?

Yes, it can be considered on a case-by-case basis. We'd appreciate if you can bring a referral from any of our existing customers. Just write to us.

Can you do custom work too?

Yes. Our point-based contribution model recognizes the continuous spectrum of the nature of software: from being a fully private good (custom work) to fully public good (popular FOSS).


By leveraging remote part-time developers from across the world, and by distributing the cost of FOSS development across multiple customers, we're able to reduce our costs to a fraction of what it would cost you to do this kind of development in-house.

We've been working with a few customers already and we'll be publishing their case studies soon. Meanwhile, if you'd like to talk, get in touch.