Hello everyone, I would like to share with the community some reflections on the new add-ons with commercial license that are being published: Maps and BProc. First of all to say that Haulmont is in his right to follow the commercial guidelines that he deems appropriate, as I said before is only a reflection. I think that by publishing these two add-ons with a commercial license, those of us who have paid for the studio license for a long time have been a bit harmed. Now we have gone from functionalities that were already included in the standard license, to having to pay for them as a separate module. It is true that the old models are maintained, but we all know that if as programmers we want to offer the best to our companies and customers, we also have to develop with the best tools. Sooner or later there will be functionalities that we need of these two new modules and we will have to consider the purchase. If in the end we decide to make the purchase, at that moment the initial purchase of the standard product will be devalued, since in its day we pay for a module that we are not going to use. One of the strengths that I saw in Cuba, and the one that I chose as the main development framework in my company, was that practically all the functionalities that I could require for business development were already included in the product license, I paid and I forgot. In particular, I would have liked a prior warning of the policy change. Greetings to all.
Hi @albertosanchez,
First of all let me point that you are paying only for development tools and perviously the commercial add-ons were included in subscription for free.
Secondly, we release a lot of open source add-ons like IMAP, Report Templates, LDAP, SAML and so on. Honestly, haven’t gotten a lot of warm words… It was accepted as something we must do. There are a few of components which are really time consuming in development and support and we cannot afford doing everything for free.
Finally, just to give you a clear understanding - open source means that it is not free, but somebody paid for it and granted it to the community. We try to diversify the way to monetize our work, so most of community members could even keep zero price for using the product. We could pack it all in one, but then the price would grow even for a lot of users who have no need in the commercial part.
Regards,
Aleksey
Hi,
thanks @albertosanchez for your reflections. For me as an outsider and independent contributor it is interesting to see the different viewpoints on the open source topic.
First question: do you have purchased the CUBA Studio 6.x variant or the Studio after the license change with the 7.x release. From your statement “for a long time”, I assume you have started with a CUBA Studio 6.x release, correct?
Can you elaborate a little bit what you mean by you have been harmed? How have you been harmed by that release?
If you are talking about the friction that it creates in your company of going through the purchasing process, then I can see what you mean. However, actual since Studio is a recurring license, even “back then” it was not friction-free.
However, this also inherently means that except when you use 100% of the offering, you are by definition spend too much money, because you pay for a bundle although you are not using everything of it. In this regard, the way of pick-and-chose is actually better for the average buyer, because they can only pay for what they use.
Where do you actually see the policy change? IMHO the webdav component was the first one which was introduced quite some time ago and it contained completely new functionality and was an up-sell.
And also: just remember when CUBA 7.0 was released, the majority of the premium addons back then were open sourced as well (Reports, FTS etc.).
In fact when you take look a closer look at the changes that have happened to Maps e.g. and compare it to their predecessor, you will see that both can display Google maps (correct), but this is already where the similarities end and the differences start. Where the old one was mainly a thin integration wrapper of the Google Maps API into the CUBA generic UI, the Maps addon is a more-or-less a complete spacial aware software API, where one little part is rendering google maps.
The differences of the functionality are so big, that you could not even say it is a simple switch from version 1.0 to version 2.0, but more like a version 1.0 to version 4.0 switch.
I don’t agree with all of the statements from @stukalov, however with his main message he just describes what the majority of the open source vendors deal with: how to monetize open source software and make it sustainable?.
At the end of the day this is what matters most for Haulmont and for yourself / your company.
With the addons release it is basically just the “Open core monetization model” of open source, which is a common answer to this question.
By selecting CUBA as “the main development framework in my company” as you called it, you have placed a big bet on some technology (and this is what the majority of the users of open source do). This means that you would probably be in (big) trouble in case this technology stops being maintained all of a sudden.
Furthermore it means that it is in your very own interest that you ensure this project is sustainable (in order to prevent the above situation). You can achieve to ensure that by either contributing to the project directly (through code, bug fixes etc.) or indirectly by paying someone to do that.
From my side I always struggle to understand the discussion about license fees in particular in the CUBA world. Paying 200$ / 2000$ more or less overall on licenses is usually not a proper cost driver in a company.
In a business context (which the majority of the usages of CUBA are) a salary of a SW developer will eat up those licenses for breakfast. So optimizing for very good “utilization” of this resource will bring much more value short-, mid- and long-term.
Building something like the webdav addon on your own will easily take weeks / months to put it to a production grade. With an arbitrary salary of 60k$ p.a. for SW devs the amortization time is probably reached somewhere in the first week.
We are not talking about Oracle Enterprise kind of a license fee here.
Perhaps your situation is different in this regard. But at least for the average user that I saw of CUBA, this is more or less reality.
Bye
Mario
Good morning, first of all thank Aleksey and Mario for their reflections. I would like to make it clear that I am very happy with this tool and wish it to continue for a long time, so I firmly believe that it is good to express all customer opinions, not only the positive ones, but also those that are less. I would like to point out some reflections and answer some questions asked by Mario and Aleksey.
Starting at the end, and in relation to Mario’s comment that the average salary (even low) of a developer is 60K, and what more or less this is a reality, really Mario?, did you do a survey among cuba developers? I write from Spain, and what I can assure you that the salary you indicate is at a sidereal distance from the one paid here, is more, I also know the zone of South America and there they are even more distanced. I believe that in a world so globalized and unfortunately so unequal it is not prudent to make that statement to assess whether the cost of a product can be afforded by someone. Having said that, however, I agree with you that the relationship between the cost of the product and its quality is exceptional, hence our choice to develop with it.
Aleksey comments that they have developed many opensource add-ons and they were not thanked, I for my part have been thankful to acquire the licenses for three years, that is my thanks and I suppose others too.
I also read Mario’s example about the webdav add-on, I didn’t mention it in my comments because the first version has already been commercial, nothing to object.
As for the interest we should have in making the project sustainable, I reiterate my previous words, we acquired licenses for all our developers for three years. I think our support for Cuba is clear and sincere.
I think I did not explain myself correctly in my previous post, I hope to get it now, in most of the companies in which I have worked the department of I.T. has a budget and within it has to allocate the purchase items by products, these items are supervised by the internal audit department, we buy the licenses in version 6, we acquire several development licenses for a period of three years. When acquiring the licenses we have to make a report on the functionalities that are going to contribute us throughout those three years, and the department of internal audit hopes that those functionalities, not only are maintained but that they evolve and extend, logically within the three years of acquired licenses.
From there come my reflections in the sense that if some module that is opensource happens to be commercial in the period of three years, this does that it cannot take advantage of those advantages without acquiring it, it is certain that I can continue using the previous one, but the internal policy the department of internal audit asks me why the original module does not continue “extending” with new functionalities during those three years.
For example, let’s suppose that I don’t know Cuba and I’m evaluating it to acquire it in the company, in that evaluation I see that it has an add-on (imap) included, this for me makes it have a differentiating factor with other tools and together with the total cost of the product I select it as a development tool. I buy the license for three years, I develop with this add-on the first year, and in the second year an update of this commercial add-on is launched, the opensource version is maintained but NOT evolved, and how this profession and its requirements change at the speed of light, it turns out that to be up to date with the market I have to acquire the new add-on.
I want to make it clear, Haulmont has ALL the right to do it, but it is also true that the acquisition of licenses for three years have lost a part of value, it is only my opinion.
It is also true that another way to do it is to acquire the licenses for only one year, and when they expire, evaluate the cost of the product with the commercial add-ons again, in order to be able to face other opponents. This would more or less support Cuba’s project than buying licenses for three or more years? I think less, but it is only an opinion.
They are opinions made with respect towards Haulmont and the community that surrounds and supports the project.
Regards.
Once again, all the functionality that have been included in the subscription is available for the CUBA users. You claim that open source part is not evolving - that’s offensive. We put a lot of efforts in the opensource part and invest a fortune.
Regarding buying a year-long licenses - you may follow this way but it changes right nothing. In the end price will stay the same.
Regards,
Aleksey
Hi,
No. It was more to be seen as an example. Just to back up here a little bit here. The main point was that when doing a build vs. buy analysis on a particular addon / license buying will win quite often, because of the labor cost, which is normally the main driver in IT.
I did not want to provide a concrete number here and with that prove that in this particular case it makes sense or not (see comment above). Instead it was an example. I explicitly wrote that in your particular situation it might be different and that it only reflects what I saw where CUBA was used.
I know that in the different parts of the worlds different salaries apply (where the diff is measured in orders of magnitude).
I wrote “salary”, but what I actually should have written is labor cost. Even if the average salary is X k$ in country Y, depending on the context the price of the employee for company Z is more like 1.2X k$ - 1.8X k$, because of stuff that companies have to take care when hiring people. HR overhead, office space, equipment etc.
Not even thinking about opportunity costs which oftentimes are the biggest driver.
But as you see by reading this, it really drifts away from my original point…
Well, what should I say about that… The number was not meant to express the ignorance of a “white-dude in its thirties living in a privileged country at a privileged job” about what “the average person in the world is able to afford”. If I should have offended anyone by this number, I’m sorry for that. This was not the intention.
You can take the number and divide it by 2, 3, 4 or multiply it by 1.5, 2 or 3. From a pure economic perspective it will “just” shift the point in time of amortization to a certain degree.
For a business it is mostly an exchange of two goods. The company invests money to gain some value (which is normally the resulting application or the absence of development costs) which (hopefully) results in more money because of either higher turnovers or cost savings that will justify this investment.
Taking that topic aside, I think one point you have here is totally valid and good. You expressed that in your last sentence.
I think it is crucial for users of an open source project to have a clear roadmap and communication in general from the project maintainers. Because in particular in the case of CUBA, this is oftentimes software that their business rely on. Instead of paying with money users pay with trust in the livelihood of the technology (which is not less expensive).
If in this particular case reasonable or not, I’m not sure. However in general more communication and transparency is better than less.
Perhaps this is a good learning from your feedback.
Also I think it is important to have those discussions as a community and therefore I find it very good that you bring this topic up.
Bye
Mario
Hello Mario, I’ve read your clarifications and I totally agree with them. I also think it’s interesting that the community has these conversations, as long as they are respectful to everyone, I think they enrich us and the product. It is a pleasure to have exchanged these ideas with you.
Greetings.
Hi Aleksey, sincerely and seeing this last message I think we are not in the same constructive line of the conversation, as if I had it with Mario. Perhaps when translating into English I expressed myself wrongly, I did not mean that the open source product does not evolve, that comment is taken out of context, so that there is no doubt about what I mean, I’m going to use a phrase from the forum in which he explains it, in the topic: New BProc (business processes) addon beta released, Max Gorbunkov comments:
“The existing addon will be supported (bugfixes, compatibility with new CUBA versions, etc.), but no new features will probably be added there.”
For my part, I close this topic.
Greetings.
I see your point. Thanks for sharing it. I also don’t see any constructive points from your side. Your position is clear and understandable, but it doesn’t fit any commercial model, as price for Studio is very low and obviously cannot cover even a half of the investment Haulmont makes. I told you that we are trying to diversify income, letting people to choose and pay only for what they need. This allows a lot of people even stay at zero price.
This is going to be a little hard to understand CUBA strategy and would appreciate a little help. Today we have at least 2 app Components that are replaced by seperate commercial offering i.e. BPM and Maps which were originally part of the original license bundle. Do you also have similar plan in your strategy to add more to commercial offerings from the remaining (Reports, Full-text search…etc) and stop further development/enhancement? No offence to CUBA team, be assured, I am one of those who are really with CUBA team and highly appreciate for what you are delivering till today! This is just a question to understand where we are heading to.
I understand it’s difficult to reconcile one model with another. You talked to me about proposing some way, here goes my proposal.
I acquired the licenses with version 6, I did it for two years, its expiration is next year, here are two cases:
1.- I want to acquire the webdav add-on, as this commercial module did not exist in open source format when I acquired the licenses I must pay for it. It seems reasonable to me.
2.- Bproc, when I acquired the licenses there was the Bpm module in open source format, and from my point of view I see that it is reasonable to evolve while my licenses are in force. How the new functionalities are going to go to Bproc, could I enjoy the Bproc add-on while my licenses are valid? Once they have expired, when renewing again I would have to buy the add-on with its commercial price.
Would a similar solution be feasible?
Greetings.
As I already mentioned above, when you purchased the license we didn’t charge for addons. They were included into the studio subscription at zero price as bonus, but you paid for studio only. This promo is simply over now.
What you describe looks to me like you buy a car and then come again to the seller when new restyling is just released, saying that you want new features and improvements of the renewed version to be available in your old model :). And if you buy it today and tomorrow they introduce a 10% off discount, would you claim to apply it to your yesterday’s purchase when this promo didn’t exist?
BProc is absolutely new addon and not a reincarnation or update of the BPM one. There is no migration, there is no compatibility at API level… It is almost same far away from the old BPM as WebDAV. Same is right for the new maps add-on.
Regards,
Alex
Hi all, I think that this question from @mortozakhan is the most useful point from this discussion…
And (IMHO) it deserves an official response/announcement from the company (a blog post maybe?), so that everything is put in clear terms and we could avoid similar threads in the future.
Just my 2c, sorry for the interruption 
P.
I agree this is a valid point. We don’t have certain plans for now. It may be changed later on.
P.S. Once again, we are not talking about stopping support for these add-ons. We introduced completely different add-ons with different licensing policies.
Regards,
Aleksey