I'm really happy to see that this is an example of really selling free software: no non-free software in sight. I'm so used to the usual response to "how do I sell free software?" to be "write some non-free software and sell that instead", that I was surprised and pleased to see that Guacamole really is selling 100% free software. All they had to do was attach a price tag, not change the license.
Another counterexample to the proposition that you have to make your users give up their freedom in order to coax them to pay you.
Indeed. I hoped that Ubuntu, Debian and the other understood that the APT repository is nothing but an App Store. Ubuntu was in great position to start asking for money to divert to projects. Who wouldn't pay $10 for the convenience to install Gimp or libreoffice with one command?
>>> Who wouldn't pay $10 for the convenience to install Gimp or libreoffice with one command?
I hope this is an ironic comment? If Ubuntu asks for money, it will be uninstalled the next day. Debian and CentOS do just as well without the shenanigans.
elementary OS has something similar to what you're proposing.
All the apps created specifically for elementary OS[0] are available on GitHub, authors set their preferred price in the app store. As a user you can pay-what-you-want for the app (including $0, which allows you to download an app without paying for it).
They're working on an online account feature for the next release so that they can remember your credit card to make the process more streamlined, persist between installs and similar. At the moment, it's more convenient to specify $0 than it is to enter your card over and over again.
You can also skip the AppCenter all together by specifying the package name (example: "apt install com.github.alaim23.planner").
The big issue with this type of thing is that there is no moat. As long as it is small not to attract attention, you are fine.
However, if it becomes big, or a larger company sees it as strategic, then it is hard for you, especially for Enterprise software. Suppose Microsoft or Amazon uses the same Guacamole components to create a solution. Then they send their sales people to the CTO of the Enterprise. "We heard you are using this Guacamole software in your enterprise. Why don't you buy our solution instead. It has the same features (actually, even the same code), but it is supported by Microsoft (or Amazon) instead of Glyptodon, Inc."
The moat with the Red Hat model is the trademark. Someone else can build an alternative (such as CentOS), but they cannot call it Red Hat and they have to do their own brand development.
I think Red Hat is pretty unique. In the decades since Red Hat was founded, I don't think a similar company has emerged at Red Hat's scale and reputation.
There are other open source companies using the Red Hat licensing model now such as Chef. Some are coming to the realization this license style is the only one where the goal of both being open source and having some kind of moat are easy to accomplish. Otherwise every time you start a new code repository you need to think about its license and your future business strategy.
I don't really understand the argument. Does the commercial version have something that the open source one doesn't have? If yes, is the commercial version also open-source, but with a different license?
And what exactly differentiates the commercial version from the open-source one? Is it that they took the lessons from their support & service business, and formalised them into a product?
It sounds like what Caddy tried doing years ago, with an open source thing you could build from source and paid commercial binaries. Especially since the Apache Guacamole installation docs don't mention RPM, it seems like the value-add here is in the packaging.
I think the lesson here is that if open source software has nontrivial setup, there's money to be made by simplifying the packaging and distribution. Perversely it suggests you should make your open source software harder to integrate, so that people will pay you to set it up for them.
I don't think that's really true. In Caddy case for example, simply it's a software space where the rivals are AWS, GCloud and Nginx. But Nginx (enterprise) came way before the cloud boom and so they had already a foot in the market.
The Guacamole case is really different since their customers will be by definition the IT departments. So, even if OS packaging was already good enough, you will still have a big chance of selling it to a big corporation.
That does make sense and in practice I think this does currently work for a little while.
But given enough time, isn't someone always going to come along and provide open source packaging for the project?
If so that would mean you're choosing to trade ease-of-install and community goodwill against revenue -- and revenue with a limited time horizon, at that.
I can see how that could appeal in situations where decision-making incentives are not aligned with long-term value of the overall ecosystem.
Selling services and expertise seems more sustainable, since offering those doesn't imply that you should add complexity or difficulty to your project. By providing expertise you can continue maximizing community goodwill and contributions, while reducing your own maintenance costs.
Providing services also enables the creation of an ecosystem around your project; that may include competition for your services, but it also implies a larger customer base and project adoption -- and more job creation and skill development.
and with the VDI-crowd you still can sell that as a feature, as they don't like random containers in their auth-workflow. Seems like being conservative is rewarded sometimes.
> I think the lesson here is that if open source software has nontrivial setup, there's money to be made by simplifying the packaging and distribution.
I think this lesson is there throughout the market - there are many companies now selling "X as a service" where X is something you can get and use for free, but there may be setup and maintenance costs.
Unfortunately the answer usually seems to be "make it difficult to build or set up so people will be pay you to do that for them" (or put no effort into making it easier).
I think the open core model is better - it provides less incentive to make the open source version difficult to set up, and I'd guess it provides more stable income.
Another counterexample to the proposition that you have to make your users give up their freedom in order to coax them to pay you.