5 ms·
Maintainers should be given the tools to monetise their projects using a cloud offering early on so they don't burn out on the way to learning what control plan
by smashah 4y ago
Maintainers should be given the tools to monetise their projects using a cloud offering early on so they don't burn out on the way to learning what control plane/data plane nomenclature actually is!
Unfortunately there are limited tools/resources out there to answer the question "how can i build a cloud deployment option for my open source project" without 25 layers of abstractions. This is why open-source projects end up raising millions of dollars (e.g strapi, appsmith just off the top of my head). All this money just for all these companies to essentially build the same thing.
Ideally, there should be a service/tool (maybe thenile will be it) where I answer a few questions.
Containerised?
Stateful?
Long lived?
Keep alive?
Allow end users to deploy many instances?
% premium per instance over cloud costs?
License per instance?
Pricing (tiered, volume, stairstep?)
On end customer's own infra?
Min resources per instance.
Airgapped per user/airgapped per instance/all instances running on same cloud?
Instance management API?
Update strategy?
Big Green button to update all instances at once?
And it should spit out a ready to deploy setup where I can start monetising my open-source project while concentrating on maintaining the project.
If the above exists then congrats, you disrupted the main reason for open source projects raising millions of dollars.
- deleted 4y ago[deleted]
- ibeckermayer 4y agoSounds insanely difficult to get right
- smashah 4y agoYES! Imagine trying to do all that while maintaining and growing the source project. This is why I've never been able to get there with my project. Instead I have to make deployment buttons where DO makes all the revenue and their broken referral system doesn't even give me anything back. One shortcut with all this is just to allow maintainers to surcharge a premium with deploy buttons.
- infra_dev 4y agoHey smashah, this is Ram, the author of the post. Everything that you said is pretty spot on. It is a really hard problem and pretty repetitive in many of the companies including open source projects. We hope to build a platform that can help with this and over time cover all the use cases you mentioned.
- gkapur 4y agoHow do you think about partner versus build? Usage based billing on its own is a pretty complex topic as an example with multiple startups that have tried to do it right. It is pretty data intensive as usage frequency increases, as well. It seems like you may be trying to do too much here. Just one opinion but something to think through (build versus partner.)
- nussbaum9696 4y agoSpecifically for API, seems better to just partner, focus on building core product and getting users.I've seen tools out there to manage usage based billing and auth for APIs, archetype.dev is one. Seems like no brainer vs. trying to spend eng hours in house to figure out, thoughts ?
- kisheemon 4y agoI saw a pretty good article the other day about the some of the difficulties on the build side. Might be worth taking a look https://www.getoctane.io/blog/usage-based-billing-complexity https://www.getoctane.io/blog/usage-based-billing-complexity