> Why not dual license MIT/BSD plus a commercial version with more features?

So, what you are advocating here is combining a permissive license (eg. MIT/BSD/Apache 2/etc.) with an Open Core approach.

This can work, but it is difficult. The decisions around which features go into the core, and which are in the commercial version become higher risk. Keep too much proprietary, and the odds of someone in your community duplicating the proprietary features goes up (as it normally would for GPL+commercial), chewing up your commercial moat. But keep too little proprietary and the odds of a commercial competitor duplicating those remaining features and competing with you on price goes up instead. Even the case where they develop a different set of commercial enhancements to target another market (or another pricing model) will probably mess up your commercialization roadmap.

And I'm not sure there is ever a "just right" point between too much and too little, the middle ground will probably have you contending with some of both types of competitive pressure, and may not actually be less overall.

At which point you have to fall back to trademarks and brand recognition, as well as maintaining an edge of expertise by employing the main contributors and/or subject matter/domain experts.

This is a very customer-focused model with practically no lock-in, and can work, but leveling the playing field in that way will make attracting investment harder. Investors want to know what your unfair advantage is, and your licensing choice effectively lowers the barrier to entry instead of raising it.

The idea with dual licensing with GPL is that the user has to either open-source their code, which most corporations will not want to do, or use the paid licensing scheme.

That's part of it (and it's probably dominant when the software is infrastructural and typically has other software built on top of it), but not quite the whole story.

The other part is for software that is more of an application than a component: when your commercial version has additional features aimed at deep-pocketed customers (typically "enterprise" features like SSO, or various forms of compliance). Since these features aren't released as open source, you are the sole source of those capabilities. Someone else could duplicate those features and release them as GPL, competing against you with a completely open source offering, and nuke your profit margin, but what they can't do is duplicate the features and keep them proprietary as you are doing. So anything they release like that is now effectively free, and they don't really get any of the attractive profit margins you had, making it harder for them to recoup the sunk cost of duplicating those features.

IOW, they can fill in your moat, but then can't really dig their own.

This gets back to why big companies release software as open source: Sometimes they aren't just trying to commoditize their own complements, they are trying to commoditize someone else's core to blow their business model up (or more accurately, cause their competitor's market to evolve faster than they are prepared for). Open Source isn't the only possible play here though. A free or freemium offering as well as other tactics can have a similar effect.

I know some companies have had their software nabbed by other companies..... did they not use GPL?

I guess I’m thinking of elasticsearch but surely other companies have been turned into services by big companies?

This is totally OK with the (A)GPL which is why certain companies has tried to come up with new licenses, none of which are compatible with OSI Open Source.

(I specify OSI Open Source here since someone took the time to dig out enough references to convince me (and probably others) that the term open source was used more or less for the same idea well before OSI started using it.)

[1] https://www.gnu.org/licenses/why-affero-gpl.en.html

[2] https://stackoverflow.com/a/2127313/1470607