jcroy
Senior HTF Member
- Joined
- Nov 28, 2011
- Messages
- 7,944
- Real Name
- jr
The problem with forking the code base is you may lose community support and all the bug fixes and enhancements that go along with it. Or maybe the community starts a new fork and everyone begins using that to underpin their browsers, leaving Google on the outside looking in. That, to me, would be the ideal outcome.
At best all one can do in the absence of having any veto power, is to hope that the project crashes and burns and/or a fork is done.
For example if Google Chrome ends up fully implementing its anti-ad-blocking stuff, one can hope that a fork is done which the prominent developers end up defecting to. (Similar to what @theJman outlined in a previous post in this thread).
From an historical perspective, there have been precedents of an open source project being forked with many of the developers defecting to the fork. The biggest and fastest one I can think of offhand which has been documented, is the downfall of XFree86.
Make Your Open Source Software GPL-Compatible. Or Else.
This essay argues that developers of open source software / Free Software should use an existing widely-used license compatible with the General Public License (GPL). It also argues against FLOSS license proliferation.
dwheeler.com
The XFree / X.Org fork and open source governance
A short history of the XFree86 / X.org fork and some interpretations
asterisk.dynevor.org
Back in the day circa 1990s, XFree86 was essentially the de facto standard for X Windows on Linux and the *BSDs.
Due to infighting and a change of license, just about everybody largely abandoned XFree86 like a sinking ship and moved on the X Org fork. (The last time XFree86 was updated was in 2008)