Is there a list of specific answers? I don't even know of all the ways one could organize a project. I suspect that might generally be the case for a lot of people, too. Publishing and promoting a project is a completely different skill set from developing it. It feels like the majority of developers default to thinking of "release open source" or even just "release" as meaning "publish on Github with the MIT license" plus maybe "post one link on Hacker News". That is a way, but is it actually the way that is in their best interests?
I have a library project right now that I provide dual-licensed under GPLv3 and a paid, proprietary license. It's not typical to release libraries under the GPL rather than, say, the LGPL or MIT. My reasoning is "code or coin, you gotta give something." I have no idea if it will actually work (and I'm not banking on it working, I wrote the thing for my own use first and foremost), but I am starting to think that I would rather nobody use my code than everyone if it meant I didn't get anything out of it past an 'at-a-boy.
Put another way, if I were Ryan Dahl, having gotten Node.js started off on my own, and I still had to work for a living, I'd be pretty freaking pissed. (https://groups.google.com/forum/#!topic/nodejs/hfajgpvGTLY) Maybe the actual Ryan Dahl doesn't care (and maybe he chooses to work, I don't know the exact details), but it would seriously bother me.
The basic recipe for software biz success is the same whether proprietary or libre. ~80% of revenue comes from ~20% of customers and features. Ship something into the market somehow anyhow so you can identify the critical 20%. Then you can commoditize (open) the remaining 80% of features to reduce costs and help the long tail to become self-supporting. Pricing and defending and growing the revenue features is then like any other business, i.e. strategic conflict with other mice who will come after your cheese.
"Open" is as much a state of mind and development practices as it is a license. JIRA shipped with full source code while remaining proprietary. This removed customer concerns about JIRA going out of business, no need for source escrow. Customers ended up making modifications to the source, which then influenced the Atlassian roadmap. Conversely, one can have an open-source license, but a dev culture that rejects external input, e.g. Calibre. If a vendor focuses on business goals first, then creates a culture to support those goals, license choices will become clearer.
There are useful history lessons among these links:
7) Any good book on organized crime / unregulated business. Boundary conditions inform risk management, i.e. early recognition of failure scenarios to be avoided.
I have a library project right now that I provide dual-licensed under GPLv3 and a paid, proprietary license. It's not typical to release libraries under the GPL rather than, say, the LGPL or MIT. My reasoning is "code or coin, you gotta give something." I have no idea if it will actually work (and I'm not banking on it working, I wrote the thing for my own use first and foremost), but I am starting to think that I would rather nobody use my code than everyone if it meant I didn't get anything out of it past an 'at-a-boy.
Put another way, if I were Ryan Dahl, having gotten Node.js started off on my own, and I still had to work for a living, I'd be pretty freaking pissed. (https://groups.google.com/forum/#!topic/nodejs/hfajgpvGTLY) Maybe the actual Ryan Dahl doesn't care (and maybe he chooses to work, I don't know the exact details), but it would seriously bother me.