Pricing an open source project is tricky. Especially so because the traditional COSS strategy of the last 10 years used by the likes of Mongo DB, Hashicorp and others, has received flak for the “BUSL rug-pull”.<p>It is our firm belief that Digger will continue to be Open Source, and we have built the product around gitlab’s buyer based open core model [1] from day 1. The enterprise edition features around collaboration and governance would be what people would pay for, with the features around automation being free.<p>This however, presents somewhat of a chicken-egg challenge in the early stages. Being a super small team, while the community edition brings us user love, the features in the enterprise edition brings us revenue, and for sustainable continuance of the product for both CE and EE features, we need to prioritise the requests and features of users that are willing to pay.<p>We have slowly started figuring out the features that people would pay for and we are working hard to onboard our enterprise customers.<p>But a question we repeatedly get asked is: how are you thinking about pricing? Why is it not transparent?<p>The simple answer is that we are still figuring it out.<p>The complex answer, is detailed in our current thesis below:<p>We think that where Digger wins amongst its existing user base is that most “middle tier” features amongst competitors can be used for free either via self hosting the community edition or via using the free automation tier. Digger’s collaboration tier also presents a significant advantage vs competition in that it doesn’t charge “self hosting” tax, and allows users to self host the features available in the collaboration tier at no additional cost. Now coming to the governance tier, Digger allows users to consume the features in this tier via their preferred means, and also has a bunch of governance features such as SSO, Audit trails, log forwarding and private VCS support which are often hard enterprise requirements.<p>We’d love the community’s feedback on this. Both regarding the feature split and on the actual pricing.<p>We've also created a github issue regarding this:<p>https://github.com/diggerhq/digger/issues/1589<p>[1]: https://handbook.opencoreventures.com/open-core-business-model/#764604b5c6db4107bb84bbc427d81b87
You should price based on "what value does this product bring to the customer". For example if the product might increase a particular customer's profit by $1M per year, you should price it at just below $1M (maybe $0.9M?) per year for that particular customer.