With regards to WordPress, it’s the lack of policing on the OSS-ness of a plug-in — as you mention — helps create a viable market, but many of the most successf

With regards to WordPress, it’s the lack of policing on the OSS-ness of a plug-in — as you mention — helps create a viable market, but many of the most successful plugin devs sell a premium version tied to a service in some way. Whether the service is necessary is often beside the point, the SaaS aspect can be used as a shield to obfuscate the open source code. I also think with WordPress in particular, the target customer doesn’t know how to compile the plugin source if they find it. It’s easier to pay than to figure out how to get it for free. Now, whole rings of people sharing premium themes and plugins exist, but the malware often added to those items can turn people off of that method. It’s easier to just buy it. Honestly, support seems to be the most long lasting option — see RHEL and Canonical and Oracle with their Linux distros. You can use centos instead of RHEL (and could before red hat took it over, for that matter), but you’d need to deal with the the problems yourself or have a person on staff to deal with them. Especially as stuff is more cloud-based,it’s easier to just have a support contract. The problem with this model for the indie developer, of course, is that the act of offering support has a cost too. Time, extra staff, logistics — and that can be harder to do than the closed-source perpetual license model, where you offer support but it’s understood the transaction is primarily for the software. And just speaking for myself, if I buy a piece of software, I’m not necessarily going to bug the dev every time something breaks b/c I was really buying the ability that use the software that would otherwise not be available to me. But if I am explicitly paying for support, I’m going to be more entitled, even if it’s for an OSS product. Because if I don’t get support and it’s OSS, why didn’t I just compile it myself and save money?