Just upgraded our DataGerry deployment on OKD4 from v3.0.0 to v3.2.0 (becongmbh/datagerry-backend:3.2.0) — turns out many of the useful features are now paywalled, and it’s not something I can justify upgrading. Time to look at alternatives or other community recommendations?
Thanks for the honest feedback. I completely understand the frustration when upgrading from 3.0 to 3.2 and discovering that features you were used to are now part of a subscription.
The change was intentional, but we probably need to do a better job of communicating it.
DataGerry is still open source, and we remain committed to the self-hosted/community edition. At the same time, we have started to separate some of the more advanced features into paid editions. The reason is that maintaining DataGerry as a product — including ongoing development, security updates, documentation, infrastructure and support — requires a sustainable business model.
We also don’t want to hide that this is a business decision. We are a small company, and if DataGerry is going to continue to be actively developed for the next years, we need customers who use the commercial features to help finance that development.
That said, I take your point seriously: if an existing community user upgrades and suddenly finds that an important part of their workflow is no longer available, that can understandably feel like a step backwards.
We’re currently working on making the boundaries between Community and the commercial editions much clearer, so that users can make an informed decision before upgrading.
If you can share which features you are specifically missing in 3.2, I’d be very interested to hear about your use case. Not as a sales pitch, but because this kind of feedback is important for us when deciding what belongs in the Community Edition and what should remain part of the commercial offering.
And of course, if the current 3.2 licensing model doesn’t work for your use case, I understand if you decide to stay on 3.0 or evaluate alternatives. I’d rather have that conversation openly than pretend the change doesn’t have an impact.
— Jakob
CTO, becon GmbH
Thank you for the detailed reply.
In my case, switching from an open-source platform to a subscription-based one, with a product my organisation doesn’t officially support, is not possible. For a highly customisable resource inventory for a small group which is what I planned to use DG for, it would be hard to convince anyone.
I understand that the company needs to make a profit to keep running, and that your decisions will be business-driven from now on. However, even if you agree that a certain set of features remains free today, a future release could paywall them. Furthermore, the Community Edition advertises PRO features on almost every page, which undermines the Community Edition philosophy entirely.
The most important feature I lost was the REST API and rolled back to 3.1.
Thank you for the clarification — and especially for explaining the actual use case. That makes your decision much easier to understand.
I also think your point about long-term certainty is a fair one. From your perspective, it is difficult to build a system around a feature being available in the Community Edition today if there is no clear expectation that it will remain there in future releases. I don’t want to give you a promise that I cannot guarantee for the next five or ten years.
What I can say is that we don’t want the Community Edition to become a “demo version” of DataGerry. We want it to remain a genuinely usable self-hosted open-source product. The commercial editions are intended to provide additional capabilities and services around that core, rather than making the Community Edition unusable.
Your feedback about the REST API is particularly valuable. I understand why losing that capability would be a major breaking change for your use case. If REST API access is essential for a resource inventory, then 3.1 is obviously a much more practical version for you at the moment.
The other point you raised — seeing PRO features advertised throughout the Community Edition — is also something I agree we need to look at. There is a difference between making users aware that additional functionality exists and making the Community Edition feel like a constant advertisement for the paid version. We need to find a better balance there.
I don’t expect you to change your decision based on this discussion. If 3.1 gives you what you need without requiring a commercial subscription, staying there is a perfectly understandable choice.
What I do appreciate is that you’ve given us very concrete feedback rather than simply saying “the new licensing is bad”. The concerns around the REST API, long-term predictability, and how PRO features are presented in the Community Edition are all things we can take back into our product discussions.
Thanks again for taking the time to explain your perspective.
— Jakob
CTO, becon GmbH