So what’s the problem? There doesn’t appear to be any risk here.
So what’s the problem? There doesn’t appear to be any risk here.
- The corp still doesn't need to take direction, nor input, nor patches from the community.
- The corp can steer the language and frameworks wherever they want. Sure, you may be able to then fork it, but is that fork going to gain any traction? Probably not.
And it definitely will not work on that corp's Official Operating System platform.
>The corp can steer the language and frameworks wherever they want. Sure, you may be able to then fork it, but is that fork going to gain any traction? Probably not.
These both apply to not-corporate projects as well.
(Or so I suspect - I haven't ever been in that position.)
Perfect example: There are 2 Plex alternatives I know of that sort of fit this mold. One is called Emby that started as open source and turned into a closed source commercial product. The other Jellyfin which is (from what I can tell) an open source fork of Emby from before it went closed. Both seem to have picked up some amount of traction.
When I started in software development in the late 90's, avoiding proprietary software was a best practice. SQL - great, open, use freely. TSQL and PL/SQL - avoid because of MS and Oracle.
If I’m concerned about spyware, then my language and compiler are low down on my list. My OS, my phone, and my network are far higher on the list.