Forking; the art of rebranding bit rot

Forking an open source project is one of the core rights given to every developer. If enough competence, money and vision agree to fork a project turned sour, it can rearrange the power structure for the better. One example of a successful and excellent fork is LibreOffice, which was forked from OpenOffice over various issues with how Oracle (and earlier Sun Microsystems) had neglected third party contributions.

Creating a successful fork takes competence, time, money and knowledge of the code base. In the case of LibreOffice, The Document Foundation was created as the new steering and financial organ.

LibreOffice was a grand success and is now the default office in most Linux distributions. It continues to see active development throughout and is by many considered the “better OpenOffice”. Ten years going.

This success story is very unusual. Most forks are made with lacking commitment, knowledge and time. Some forks are straight out a hazard to society, as they refuse to acknowledge security issues, insisting on keeping old and deprecated code alive under a new brand.

When a fork is made of deprecated code, it is essential to have a deep understanding of the code and to commit to fixing security issues, bugs and keeping testing up to date.

It is not okay to fork deprecated code only to let it decay without maintenance. Spending all time designing a new flashy logo, brand name and look, bumping v0.x.x version numbers to v4.0.0 does not avoid the fact it’s broken down unmaintained code being marketed as something it isn’t.

I’m writing this as an author of an open source web server library with 17 major versions released over 4 years of consistent development. I take security very seriously, as many of my customers are in the financial sector.

It frightens me how an increasing amount of people are mislead into believing they’re getting something up-to-date and taken-care-of when I know for a fact they’re being spoon fed nothing but rebranded security holes on top of crash bugs and memory issues.

One example is SocketCluster, which forked an old version of my project and removed deprecation warnings and kept its customer base using old unsafe code with no intention of maintaining it.

Another more current case I’ve been made aware of is ClusterWS, which brands itself as a complete rewrite. Of course it’s shipping the same unmaintained, insecure and buggy code I deprecated years ago and superseded with multiple major versions upstream by now.

7000 lines of unmaintained C++ code with known vulnerabilities, bugs and undefined behavior such as integer overflows, misaligned memory access and the like.

Code I deprecated for being too insane to maintain, too hacky to last, and too tightly coupled to actually test in any reproducible way.

The bit rot is so grand, SSL support has now been disabled altogether due to forker’s incapability to keep it working.

In all seriousness — forking should be left as a last resort, not as a way to stubbornly cling to old code just because you’re to lazy to update a few lines of code as required by an API change.

That API change can be a hurdle, sure, but clinging to thousands of lines of unmaintained code disguised as “brand new” is not a valid strategy.