I agree that open core is not ideal if you do it to the extreme as described in the article, but it can be done with moderation to get much more money, which could be invested in the open source part and have it thrive as well, like for example done by Sidekick.

From my experience the alternative support and donations business models don't really work. I'm the initial author and maintainer of Autospotting, a piece of software that saved the users in the millions dollars aggregated over my entire user base, and as much as I tried so far I couldn't get much money out of it.

I'm currently getting about $100 monthly on Patreon for support plans and a few donations here and there but that's nothing compared to the effort I put in it and the value it creates.

Foss desktop software is so hard to monetize. At least with servers you can charge for cloud features (though then the user has given up some control in that scenario).

Industry associations seem to help, like the Linux foundation, where company stakeholders come together to fund the development and get a say in its direction - eg, if the different cloud providers banded together to fork mongo and/or redis in this way (to the unfortunate and severe detriment of the founders)

Possibly purism is pioneering a hardware driven angle too?

The incentives if you sell support is to make your software harder to use, design it poorly so that it breaks and people need you to rescue them when something bad happens, or simply deliver security patches timely. The first two and are against my principles and the latter simply doesn't apply unless you're a behemoth like RedHat or likely insecure or mission-critical so if breaches do happen it's a very big deal.

My particular project is designed to run in AWS and help reduce my users' bills. I spent a lot of time and effort to make it as easy to install as possible and to minimize friction, runtime costs and security risks for my users (it's entirely serverless based on Lambda and can be installed in minutes).

The side effects of these decisions are that it's so stable,secure and easy to use that pretty much nobody really needs any help with it, and that it is quite unlikely to break in the future by itself(although I see it break from time to time because AWS often changes some things that I depend on but I usually address these quickly as well), so getting a support plan doesn't make so much sense.

I mainly get these support plans sold to a handful of very enthusiastic users who would otherwise donate much smaller amounts.

I tried to bundle these with a guarantee that the supported code is thoroughly tested while the trunk is best effort, but that doesn't seem to work yet.

I think that this is in large part due to hurdles of paying for software easily.

For example

https://play.google.com/store/apps/details?id=com.iiordanov....

and

https://play.google.com/store/apps/details?id=com.iiordanov....

are the same GPL licensed software either gratis or for $5. Just buying it via the store is straightforward instead of figuring out where the homepage is, finding a donate button, entering credit card details... .

Having more non-gratis but free software would be a good thing

https://www.gnu.org/philosophy/selling.en.html

That's actually a great idea, thanks for sharing it!

I'll try to make it paid from the mobile phone.

As in autospotting.org? That’s a pretty cool concept, but I wonder how you make that work with VPCs?

Can you get an EC2 instance that is deeply embedded in a VPC that is not reachable from anywhere else but a private network on a different VPC, and still replace that with a spot instance with all the same functionality?

Do you have to create an AMI so that you can relaunch an instance with a newer and less expensive one?

What about post-install configuration management that might need to be done?

Regarding the VPC part of the question, yes. The replacement spot instance will get the same VPC/Subnet/AZ and all the relevant settings from the instance it's supposed to replace.

Regarding the AMI/post-instal part of the question, this is already covered by AutoScaling. Remember, it works against AutoScaling groups, where all instances start with the same AMI and runan userdata script at boot. All this is preserved for the spot instances.

I don't understand what the offer suggests companies do instead?

Service based models (with training, support or integration) also can have perverse incentives on the open source software. To make those services valuable, you need the product to be worse than it otherwise could be.

Additionally, the characterization that open core companies stop improving the open source software and only improve the proprietary software might be true at some firms but is the extreme.

I have a theory that open source which mostly targets business use could be funded by providing binary releases in the form of an apt/etc repo.

Small/Medium businesses increasingly seem to prefer to just pay for the solution (rather than say paying a staff member to compile, test, and distribute something open source).

That's pretty much what I also tried to do with AutoSpotting but very few people bothered to pay for it.

I suspect the problem is that the people who're using the software are techies who would rather enjoy spending some time compiling it and setting it up themselves, maybe learning some things in the process, instead of paying for it.

This kind of software would have to be sold to CEO/CTO folks who then ask the developers to set it up afterwards.

Right, I think it helps if it provides primarily a business function rather than provides something developers might interact with directly.