The Butthurt Fork

In September 2025, David Heinemeier Hansson — the creator of Ruby on Rails and one of tech's most polarizing figures — published a blog post titled "As I remember London" that many readers interpreted as xenophobic commentary on the city's changing demographics. This was not DHH's first controversy by a long shot, but it proved to be the straw that broke the camel's back for a significant chunk of the Rails community.

A group of Rails developers published an open letter under the name "Plan Vert" — a reference to a French WWII sabotage group that targeted railway infrastructure (get it? Rails?). The letter cited the London post and another questioning Gender and Sexuality Alliance programs in primary schools — a position more aligned with mainstream Scandinavian policy than the letter's characterization of it as "transphobic" suggested. The letter called for three things: cutting ties with DHH, hard-forking Rails under a new name, and adopting a modern Code of Conduct with proper community governance.

The letter gathered roughly 300 signatures, including some notable Ruby community members like Thomas Fuchs (former Rails Core). But the initiative ran headlong into a brutal reality: Rails is enormous. It likely costs over $10 million per year to maintain, and every member of the Rails Core team was hand-selected by DHH. You don't just fork that over a weekend.

DHH responded dismissively, noting that "every few years the same contingent of Ruby malcontents tries to cancel me from Rails," pointing out that the previous attempt in 2022 resulted in RailsConf dying while his Rails World conference thrived. Critics of Plan Vert, including developer Joel Drapper, argued that a fork without critical mass would simply die on the vine.

No actual fork was ever created. The GitHub organization has no public members, and the open letter repository went quiet. Plan Vert remains a fascinating case study in how even widespread discontent can't overcome the gravitational pull of a massive, complex framework when the controversial figure controls all the levers.

Plan Vert's lasting impact is more cultural than technical. It exposed the fundamental power asymmetry in Rails governance — DHH selects the entire Core team, controls the conference circuit, and effectively owns the project's direction. The letter made visible what many had quietly grumbled about for years.

However, the failure to produce an actual fork also demonstrated that outrage alone cannot sustain a project of Rails' scale. The episode may have accelerated some companies' drift toward other frameworks, but Rails itself continues largely unaffected.

Puppet, the venerable configuration management tool that helped define the DevOps era, had been slowly declining under corporate ownership. After Perforce acquired Puppet in 2022, the writing was on the wall — but the community held on, hoping for the best. That hope evaporated in late 2024 when Perforce made several devastating moves: they discontinued public packaging infrastructure, moved all further development to internal forks, and began requiring commercial licenses for deployments beyond 25 nodes.

The Vox Pupuli community — a collective of Puppet module maintainers who had been keeping the ecosystem alive with nearly 200 community modules — decided enough was enough. In late 2024, Overlook InfraTech began mirroring Puppet and providing community packages. By January 21, 2025, the first official release of OpenVox landed, functionally equivalent to Puppet 8.11 but free of Perforce's restrictions.

The situation deteriorated further in May 2025 when Perforce introduced a new EULA for core developers that the Vox Pupuli community found unacceptable. The restrictions prevented effective testing and distribution of modules and exposed contributors to potential legal challenges. Perforce had explicitly refused to allow the use of the Puppet name, so the community settled on "OpenVox" after briefly considering "OpenPuppetProject."

A Puppet Standards Steering Committee was established to guide the project's direction, and Perforce was even invited to participate — a diplomatic olive branch that speaks to the community's professionalism. By mid-2025, OpenVox had shipped 8 releases across both v7 and v8 branches, and organizations like NC State's Linux Community began documenting transition plans.

OpenVox represents the classic scenario of a corporate owner strangling the golden goose. Perforce took a thriving open-source community and systematically removed every reason to stay, practically gift-wrapping the justification for a fork.

OpenVox saved a critical piece of infrastructure automation tooling from corporate lock-in. While Puppet's market share had been declining in favor of Ansible and Terraform, thousands of organizations still depend on it for configuration management. The fork ensures continuity for those users without requiring expensive Perforce licenses.

The project also demonstrated the power of pre-existing community infrastructure. Vox Pupuli's years of maintaining community modules gave them the credibility and technical depth to execute the fork successfully, unlike many forks that start from scratch.

In late September 2024, the Godot game engine community experienced what can only be described as a spectacular social media meltdown. It started when Godot's community manager posted what many interpreted as a politically charged tweet from the official account, injecting identity politics into what users expected to be a neutral game development tool. The exact content matters less than what happened next: the moderation response was, to put it mildly, scorched earth.

Users who criticized the post or questioned the direction were banned en masse from Godot's official Discord server and blocked on the project's X/Twitter account. The community dubbed the controversy "#Wokot," and the Godot Foundation's board issued a September 29 statement that acknowledged the bans but defended them as "necessary moderation" — conspicuously without an apology. This poured gasoline on an already raging fire.

Enter Redot Engine, created in September 2024 by Andrew Martin (host of the Citizen Coder Podcast) along with co-founders William, Nicholai, and Red Otter. The fork positioned itself as a community-driven, apolitical alternative that would focus purely on game development merit. Being a fork of an MIT-licensed engine, the technical barrier was relatively low — they could take the entire Godot codebase and run with it.

Redot has maintained active development with regular releases, emphasizing stability and compatibility with existing Godot projects. The project aims to contribute improvements back to the shared codebase, positioning itself less as a hostile fork and more as an alternative governance model for the same technology.

The irony is thick: Godot itself was born from frustration with proprietary engines, championing openness and community. That its own community management drove users away is a cautionary tale about how open-source projects can lose the plot by forgetting that "community" means everyone, not just the people who agree with you.

Redot created a viable alternative for developers uncomfortable with Godot's community management direction, though Godot itself remains the dominant project by a wide margin. The controversy highlighted how social media management and community moderation can become existential issues for open-source projects.

More broadly, the Godot/Redot split became a flashpoint in the larger culture wars playing out across open-source communities, with different camps viewing the same events through completely different lenses. It raised important questions about whether open-source projects should take political stances and how to handle dissent.

Maxim Dounin is not just any Nginx contributor — he and one other developer (Roman) account for roughly 99% of Nginx's ongoing development. So when Dounin announced in February 2024 that he was forking the project, the web server community sat up and paid very close attention.

The backstory is a slow-motion corporate tragedy. Nginx was created by Igor Sysoev in 2004 and grew to become the world's most popular web server. Nginx, Inc. was acquired by F5 Networks in 2019 for $670 million. F5 closed its Moscow office in 2022 (amid geopolitical tensions), and Dounin — who had been one of the earliest employees — was left without a formal role. He continued maintaining Nginx as a volunteer under an informal agreement with F5.

That arrangement worked until F5's "new non-technical management" decided to override the project's longstanding security policy. Specifically, F5 forced a security release for bugs in experimental HTTP/3 code that, under existing policy, should have been treated as ordinary bugs. The developers unanimously disagreed. F5 ignored them. Dounin saw the writing on the wall: he could no longer control what changes went into Nginx, and he no longer considered it a "free and open source project developed for the public good."

Freenginx launched with its first release (1.25.4) under the same BSD license as Nginx. Dounin set up a read-only Mercurial repository and made clear this would be a developer-run project, free from corporate interference. The move was especially significant because Dounin possesses irreplaceable institutional knowledge of the Nginx codebase.

The fork underscores a recurring pattern: companies acquire open-source projects, install non-technical management, and then act surprised when the people who actually write the code walk out the door.

Freenginx's impact is outsized relative to its modest profile because of who is behind it. With Maxim Dounin carrying virtually all the institutional knowledge of Nginx's internals, the fork represents a credible alternative that many Linux distributions and infrastructure projects may adopt over time.

The fork also sent a clear message to the industry about the risks of acquiring open-source projects and then overriding technical decisions with corporate mandates. When your entire development capacity walks out the door and starts a competitor, the acquisition's value evaporates rapidly.

When Redis switched from BSD to SSPL/RSALv2 in March 2024, two very different forks emerged with two very different philosophies. Redict, announced almost immediately by Drew DeVault, represents the ideological, copyleft response — a fork driven by principle rather than corporate backing.

Drew DeVault — founder of SourceHut, creator of the Hare programming language, and one of open source's most opinionated voices — wasted no time. He called Redis's license change "a betrayal of the free software community" and announced Redict as an independent, copyleft fork licensed under LGPL-3.0-only. The choice of LGPL over GPL was deliberate: it avoided concerns about "virality" that might scare away users integrating with Redis modules or Lua plugins, while still ensuring the core remained free.

Redict forked from Redis OSS 7.2.4, the last BSD-licensed version, and released version 7.3.0 in April 2024 with mostly renaming and groundwork changes. DeVault was joined by Haelwenn Monnier (creator of the BadWolf browser and the Pleroma platform). The project deliberately chose Codeberg over GitHub as its home, running CI on SourceHut — eating its own dogfood in the most Drew DeVault way possible.

The project takes a consciously conservative approach to development, focusing on stability and long-term reliability rather than feature races. There are no Contributor License Agreements; copyright is held collectively by all contributors, making future license changes effectively impossible without unanimous consent.

Redict exists in deliberate contrast to Valkey, the corporate-backed Linux Foundation fork. While Valkey has AWS and Google money behind it, Redict represents the grassroots, "free software as a political act" tradition. It's smaller and scrappier, but it serves an important role for users who care deeply about software freedom.

Redict occupies an important niche as the copyleft alternative in the Redis fork landscape. While Valkey captured the corporate market, Redict serves users and organizations that prefer strong copyleft licensing and genuinely independent governance. It's a smaller project, but it upholds the free software tradition in a way that corporate-backed forks cannot.

The project also demonstrated that not every fork needs venture capital and a Linux Foundation umbrella to be viable. Sometimes a few dedicated developers with strong convictions and existing infrastructure (SourceHut, Codeberg) can sustain a meaningful alternative.

When Redis CEO Rowan Trollope announced in March 2024 that Redis would abandon its BSD license for SSPL/RSALv2, he framed it as necessary to prevent cloud providers from "commoditizing Redis's investments." What he got instead was the fastest and most consequential open-source fork in recent memory.

Within a week of the announcement, the Linux Foundation launched Valkey with backing from AWS, Google Cloud, Oracle, Ericsson, and Snap. This wasn't a ragtag community effort — it was a coordinated response by the exact cloud providers Redis was trying to squeeze. The founding team included six engineers from six companies, with Madelyn Olson from Amazon and Ping Xie from Google Cloud serving as co-maintainers.

Valkey forked from Redis 7.2.4 (the last BSD-licensed version) and immediately set an aggressive development pace. Valkey 8.0 delivered a complete overhaul of the I/O threading system, enabling concurrent operation between main and I/O threads. The result: up to 1.2 million queries per second on AWS r7g instances, compared to Redis's previous 380K QPS. By the time Valkey 9.0 shipped, throughput had improved another 40%, with a cluster capable of handling over 1 billion requests per second.

AWS made Valkey the default for new ElastiCache and MemoryDB instances in 2024, essentially redirecting its massive customer base away from Redis. Google Cloud and Oracle followed suit. Within a year, Redis had lost the majority of its external contributors.

The irony was complete in May 2025 when Redis itself switched to AGPLv3 with Redis 8 — effectively admitting the SSPL gambit had backfired. But by then, Valkey had nearly 20,000 GitHub stars, 50 contributing companies, and a performance lead that Redis would struggle to close. The horse had not only left the barn; it had won the Kentucky Derby.

Valkey is arguably the most successful open-source fork of the 2020s. It didn't just replicate Redis — it surpassed it technically while capturing the institutional backing of every major cloud provider. The project proved that when cloud giants unite behind a fork, the original project faces an existential threat.

Redis's subsequent retreat to AGPLv3 is a direct consequence of Valkey's success and may serve as a permanent deterrent to other companies considering similar license switches. The message is clear: if you change your license to squeeze cloud providers, they will fork your project, outspend you, and outship you.

On August 10, 2023, HashiCorp dropped a bomb on the infrastructure-as-code world: Terraform, the de facto standard for cloud provisioning used by millions of developers, was switching from the permissive Mozilla Public License (MPL v2.0) to the restrictive Business Source License (BSL 1.1). The community learned about it with little advance notice and zero opportunity for input.

The response was swift and organized. Within two weeks, a manifesto appeared calling for an open-source fork, eventually gathering over 1,000 individual pledges and more than 100 corporate signatures. Companies including env0, Gruntwork, Spacelift, Scalr, and Harness — many of whom had built their entire businesses on Terraform — pledged developers and resources. By August 25, the fork was public. By September, it was under the Linux Foundation and renamed from OpenTF to OpenTofu.

OpenTofu forked from Terraform 1.5.6 and quickly began differentiating itself. The project added state encryption (a feature the community had been requesting from HashiCorp for years) and attracted over 160 contributors. The project's momentum was so strong that HashiCorp got nervous — and in April 2024, sent a cease-and-desist letter accusing OpenTofu of copying BSL-licensed code for a "removed block" feature.

OpenTofu's response was devastating. They published a detailed analysis showing that the contested code predated HashiCorp's BSL version and had been copied from the original MPL-licensed codebase. Even Matt Asay of MongoDB, who had initially sided with HashiCorp, publicly recanted. CNCF CTO Chris Aniszczyk called HashiCorp's accusations "embarrassing."

In April 2025, the CNCF accepted OpenTofu, cementing its position in the cloud-native ecosystem. The project had proven that when a critical infrastructure tool goes proprietary, the community can not only fork it but improve upon it — if the organizational and financial backing is there.

OpenTofu is one of the most significant open-source forks of the decade. It demonstrated that the BSL licensing strategy — designed to protect vendor revenue from cloud providers — can spectacularly backfire when the affected community is well-organized and well-funded. HashiCorp's subsequent acquisition by IBM in 2024 for $5.4 billion suggests the company's open-source credibility was already priced as damaged goods.

The project also established a template for future license-change forks: publish a manifesto, rally corporate sponsors, join a foundation, and maintain MPL/Apache licensing. OpenSearch, Valkey, and OpenBao all followed variations of this playbook.

OpenBao is the quieter, scrappier sibling of OpenTofu — born from the same HashiCorp BSL license change in August 2023, but with far fewer resources and a more grassroots development model. While OpenTofu had multiple companies pledging full-time developers from day one, OpenBao emerged in December 2023 as a more organic community effort, primarily initiated by IBM engineers Nathan Phelps and Joe Pearson.

The genesis was straightforward: HashiCorp Vault, the industry-standard secrets management tool, was caught in the same BSL switch as Terraform. Organizations that had built their security infrastructure around Vault suddenly faced licensing uncertainty. IBM engineers took the lead, forking the last MPL-licensed version and bringing it under the Linux Foundation umbrella.

Despite IBM's involvement, the company maintained a curious arm's-length relationship — hosting a forwarding link to the project but never officially endorsing it. This lack of corporate heavyweight sponsorship meant OpenBao had to grow more organically. The project built its Technical Steering Committee, published governing documents, and shipped 8 releases including two major versions and six bug fixes.

GitLab became a crucial ally, joining the project officially in July 2024 and achieving voting status by October. GitLab architected a native integration of OpenBao for CI/CD pipelines, providing practical enterprise validation that the fork could serve as a real Vault replacement. The collaboration was showcased at FOSDEM 2025.

OpenBao's slower, community-driven pace is both its challenge and its strength. It lacks the corporate firepower of OpenTofu, but it also demonstrates that meaningful open-source alternatives can emerge from genuine community need rather than corporate strategy.

OpenBao proved that even without massive corporate sponsorship, a fork of critical infrastructure software can gain traction through steady, community-driven development. GitLab's integration gave the project enterprise credibility, and the growing contributor base suggests sustainable momentum.

The project also highlighted that HashiCorp's BSL switch created vulnerabilities across their entire product portfolio, not just Terraform. Organizations evaluating Vault alternatives now have a genuine open-source option, which was precisely what HashiCorp hoped to prevent.

Atom was the text editor that changed everything — and then got killed by its own sibling. When GitHub launched Atom in 2014, the "hackable text editor" pioneered the Electron framework and showed the world that web technologies could power desktop applications. It was beloved by developers who valued customization above all else. Then Microsoft acquired GitHub in 2018, and the writing was on the wall: Microsoft already had VS Code, also built on Electron, and maintaining two competing editors made no business sense.

On June 8, 2022, GitHub officially announced Atom's sunset, with all repositories to be archived by December 15, 2022. The stated reason was the need to "prioritize technologies that enable the future of software development" — corporate-speak for "VS Code won, Atom lost, let's move on." The community, however, was not ready to move on.

The initial community response was the Atom-Community fork, but disagreements about long-term goals led to a split, and Pulsar was born as a separate effort. Version 1.0 launched on December 15, 2022 — the exact day Atom was officially archived, a deliberate act of symbolic defiance. The project positioned itself as not merely preserving Atom but modernizing it.

Under maintainers like Mauricio Szabo, Pulsar has made significant technical progress. The project updated Electron to version 30, bringing better performance, improved Wayland support for Linux users, and modern Node compatibility. Every commit to master is treated as a beta release, maintaining a rapid development cadence.

Pulsar occupies an interesting niche: it's the editor for people who loved Atom's hackability but refused to surrender to the VS Code monoculture. It's a small but dedicated community keeping the flame alive, proving that sometimes the most important forks are the ones that preserve choice itself.

Pulsar's impact is less about market share and more about preserving an alternative in an increasingly monocultural editor landscape. VS Code dominates with over 70% market share among developers, and Pulsar ensures that the Atom ecosystem — its packages, themes, and hackable philosophy — doesn't simply vanish.

The project also serves as a case study in what happens when a corporate parent kills an open-source project: if the community cares enough, the code survives. It may never rival VS Code's dominance, but that was never the point.

SQLite is one of the most deployed pieces of software in human history — it runs on literally billions of devices. It's also one of the most unusual open-source projects: the code is in the public domain, but the project accepts zero external contributions. Not "we're picky about contributions." Zero. Dr. D. Richard Hipp, SQLite's creator and benevolent dictator, has maintained this policy for over two decades, running the project through his company Hwaci with a small team of developers.

Glauber Costa, founder and CEO of Turso, saw this as both an incredible foundation and a frustrating limitation. In October 2022, he published the libSQL manifesto, arguing that SQLite needed to evolve for modern cloud and edge computing use cases — distributed databases, asynchronous I/O via io_uring, eBPF optimization, user-defined functions in WebAssembly — but that SQLite's closed contribution model made this evolution impossible.

libSQL launched with no code changes: just a manifesto, a Code of Conduct, an MIT license, and a list of ambitious directions. The audacity of forking one of the most successful and stable pieces of software ever written raised eyebrows. But Costa's team backed it up with substance, adding server mode, replication capabilities, and the features that SQLite's strict scope had always excluded.

The project maintained a conciliatory tone throughout, explicitly stating that "if and when SQLite changes its policy to accept contributions, we will gladly merge our work back into the core product." This wasn't a hostile fork — it was more like a parallel universe where SQLite had an open contribution policy.

libSQL has since become the foundation of Turso's database-as-a-service platform, gaining significant traction in the edge computing space. It demonstrates that even the most successful open-source projects can be limited by governance choices, and that "open source, not open contribution" leaves a gap that others will fill.

libSQL carved out a new category: distributed, server-capable SQLite. By adding the features that Hipp's strict scope excluded — replication, server mode, extensibility — libSQL made SQLite viable for use cases its creator never intended to support. Turso's commercial success on top of libSQL validated the approach.

More philosophically, libSQL challenged the assumption that a project's creator always knows best about its scope. SQLite's "open source, not open contribution" model works brilliantly for an embedded database, but it also created an opportunity for a fork that embraces community input and modern architectures.

Of all the forks in open-source history, Prism Launcher might have the most dramatic origin story. On October 17, 2022, PolyMC maintainer Lenny McLennington went full supervillain, committing a change titled "reclaim polymc from the leftoids" that deleted the project's Code of Conduct, then proceeding to revoke access for every other contributor to the GitHub organization. It was a one-person hostile takeover of an open-source project, and it happened in real time.

PolyMC was a popular Minecraft launcher — a fork of MultiMC that had gained a dedicated user base. The Code of Conduct that Lenny deleted contained provisions protecting users from transphobic, homophobic, and racist abuse. The commit message made the political motivation crystal clear. Within hours, the entire development team found themselves locked out of their own project.

But here's where the story gets satisfying: the evicted developers didn't waste time arguing. Within 48 hours, they had regrouped, forked the code, established new governance, and launched Prism Launcher. The speed of the response was remarkable — they had a working project with builds, CI/CD, and community infrastructure before most people had even finished reading the drama threads.

PolyMC's development collapsed almost immediately. Without the contributors who actually wrote the code, the project stagnated into irrelevance. Meanwhile, Prism Launcher thrived, establishing itself as the go-to open-source Minecraft launcher with transparent governance, an active development community, and regular releases.

The Prism Launcher fork is a near-perfect parable about open-source governance: one person with admin access can destroy a project overnight, but they can't destroy the community. The code is free, the contributors are the real asset, and when you kick them all out, they just rebuild somewhere else — usually better.

Prism Launcher became one of the most successful "emergency forks" in open-source history, going from zero to dominant in its category within weeks. It proved that in open source, the contributors are more valuable than the repo — admin access is temporary, but community trust is everything.

The incident also became a widely-cited example of why open-source projects need proper governance structures, multiple administrators, and clear succession plans. One person should never hold unilateral power to destroy a project.

Gitea started as a community fork of Gogs, positioning itself as the lightweight, self-hosted alternative to GitHub. It built a loyal following among self-hosting enthusiasts and organizations that wanted Git hosting without the Microsoft-owned GitHub baggage. Then, in October 2022, the community discovered something unsettling: the Gitea domains and trademarks had been quietly transferred to a for-profit company controlled by lead maintainer Lunny Xiao, without community knowledge or approval.

The stealth corporate takeover was particularly galling because Gitea had explicitly presented itself as a community project. Contributors had invested time and effort based on that understanding. When the transfer became public, contributors signed an open letter asking for the trademarks and domains to be placed under community management. The request was rejected. The fork was inevitable.

Forgejo was announced on December 15, 2022, under the auspices of Codeberg e.V., a non-profit based in Berlin, Germany. The name means "forge" in Esperanto — the international language, naturally. Codeberg, which hosts over 300,000 repositories, migrated from Gitea to Forgejo, instantly giving the fork a massive production deployment and credibility.

The project initially maintained compatibility with Gitea as a "soft fork," cherry-picking changes between the two codebases. But in early 2024, contributor Earl Warren proposed what many had been thinking: Forgejo should become a hard fork with an independent development path. The community agreed, and Forgejo began diverging from Gitea, focusing on reducing tech debt, fixing security vulnerabilities more aggressively, and using exclusively free software tooling (Weblate instead of Crowdin, Codeberg instead of GitHub).

Forgejo represents what Gitea was supposed to be: a genuinely community-governed forge. The project's governance structures are independent of Codeberg, but the non-profit holds the domains, ensuring no repeat of the trademark heist. It's the anti-corporate-takeover fork, built specifically to prevent the exact thing that caused it.

Forgejo has become the standard for community-driven, self-hosted Git forges. With Codeberg as its anchor deployment, it serves hundreds of thousands of repositories and proves that non-profit governance can sustain a major software project. The hard fork in 2024 marked the point of no return — Forgejo is now its own project with its own identity.

The fork also established an important precedent: when trademarks and domains are held by individuals or for-profit entities, the community is always one quiet transfer away from losing control. Forgejo's non-profit structure specifically addresses this vulnerability.

When Red Hat dropped the bombshell in December 2020 that CentOS 8 would be end-of-lifed by December 31, 2021 — seven years ahead of schedule — the enterprise Linux world erupted. Among the scramble of replacement projects, Navy Linux appeared on January 4, 2021, founded by the UnixLab community of Unix/Linux developers. By June 2021, they had formalized into the Navy Foundation.

Navy Linux aimed to be a bug-for-bug compatible rebuild of RHEL, just like CentOS had been. They shipped a few early releases and announced ambitious plans for long-term support through 2030. The project positioned itself alongside Rocky Linux and AlmaLinux as a CentOS successor, but unlike those two, Navy Linux never gained significant traction or community momentum.

The problem was simple: the CentOS replacement market was a winner-take-most game, and Navy Linux was third to a two-horse race. Rocky had the narrative advantage (founded by CentOS's own co-creator), AlmaLinux had the corporate backing (CloudLinux's million-dollar annual commitment), and Navy had... enthusiasm. By 2022, the project had gone largely dormant, with its GitHub repositories showing minimal activity and its website becoming a digital ghost town.

Navy Linux stands as a cautionary tale about timing and differentiation in open source. Being 'another RHEL rebuild' wasn't enough when your competitors had founder mythology and corporate sponsorship. The project quietly faded without any dramatic death announcement — it just stopped updating, which is perhaps the most common and least interesting way for open source projects to die.

Navy Linux had essentially zero lasting impact on the enterprise Linux ecosystem. Its primary contribution was demonstrating that the CentOS replacement space could only support a limited number of competitors. The vacuum left by CentOS was effectively filled by Rocky Linux and AlmaLinux, both of which had stronger backing and clearer identities.

If anything, Navy Linux serves as a data point in the broader lesson about open source fork economics: when a major project dies, the replacement market consolidates quickly, and late entrants without a clear differentiator are left behind.

The Elasticsearch saga is one of open source's most dramatic licensing wars, and it starts with a grudge. AWS launched its managed Elasticsearch service in 2015, with CTO Werner Vogels publicly declaring it a 'great partnership with Elastic.' There was one problem: Elastic CEO Shay Banon says there was no partnership, and no collaboration. AWS had simply taken the Apache 2.0-licensed code and built a service around it, using the Elasticsearch name. Elastic tried to fight on trademark grounds but found themselves outgunned — Banon later described having '1,000 lawyers thrown at us.'

In January 2021, Elastic pulled the trigger: they relicensed Elasticsearch and Kibana from Apache 2.0 to a dual-license under the Server Side Public License (SSPL) and the Elastic License. The SSPL — originally devised by MongoDB — effectively prevents cloud providers from offering the software as a managed service without open-sourcing their entire stack. It was a direct shot at AWS.

AWS responded exactly as you'd expect a company with unlimited engineering resources would: they forked the last Apache 2.0 version (Elasticsearch 7.10.2) and created OpenSearch. The fork launched in April 2021 and reached version 1.0 by July. It wasn't a scrappy community effort — it was a corporate fork backed by the world's largest cloud provider, complete with dedicated engineering teams and enterprise support.

The twist came in 2024. Elastic added AGPL as a third licensing option, technically making Elasticsearch 'open source' again. Meanwhile, AWS transferred OpenSearch governance to the Linux Foundation, establishing the OpenSearch Software Foundation. The irony is thick: Elastic's aggressive licensing move intended to hurt AWS instead created a well-funded competitor that now has independent governance. Many developers who felt burned by the original license switch have said they won't go back.

OpenSearch fundamentally changed the calculus around open source licensing in the cloud era. It proved that when a company changes licenses to protect against cloud providers, the cloud providers can simply fork and out-resource you. The existence of a well-funded, Linux Foundation-governed alternative forced Elastic to reverse course and return to an OSI-approved license — a remarkable humiliation for a company that had staked its strategy on license restrictions.

The broader ecosystem impact was seismic. OpenSearch validated the 'fork and fund' playbook that would later be repeated with Valkey (Redis fork) and OpenTofu (Terraform fork). It also demonstrated that trust, once broken with the open source community, is extremely difficult to rebuild — many developers who migrated to OpenSearch have shown no interest in returning to Elasticsearch even after the AGPL re-licensing.

When Red Hat announced in December 2020 that CentOS 8 would be killed off and replaced by the rolling-release CentOS Stream, the enterprise Linux community went into full panic mode. CentOS had been the free RHEL clone that powered countless production servers, and suddenly it was being pulled out from under them. Enter Gregory Kurtzer — co-founder of the original CentOS project back in 2004 — who announced Rocky Linux within hours of the news.

The name itself tells you everything about the project's emotional core: it honors Rocky McGaugh, Kurtzer's early CentOS co-founder and mentor who had passed away. This wasn't just a technical project; it was a personal mission. Within four days, the Rocky Linux GitHub repository was the top-trending repo on all of GitHub. The community was furious, and they had their champion.

Kurtzer moved fast. He established the Rocky Enterprise Software Foundation (RESF) as a non-profit to ensure the project could never be co-opted the way CentOS was when Red Hat acquired it in 2014. The first release candidate dropped on April 30, 2021, and Rocky Linux 8.4 'Green Obsidian' went GA on June 21, 2021 — an impressive turnaround for building an entire enterprise Linux distribution from scratch.

But Red Hat wasn't done making life difficult. In June 2023, they restricted public access to RHEL source code, forcing Rocky to find creative workarounds. Rocky's team devised an ingenious solution: spinning up RHEL cloud instances to download source packages, then shutting them down — technically making them Red Hat customers just long enough to grab the code. It was legally defensible, technically clever, and exactly the kind of hack that makes open source so resilient.

Rocky Linux has since become one of the two dominant CentOS replacements (alongside AlmaLinux), with broad enterprise adoption and a reputation for stability.

Rocky Linux filled the most critical gap in the enterprise Linux ecosystem since CentOS's original founding. Its creation proved that community-driven enterprise distributions remain viable even when upstream vendors try to restrict source access. The RESF governance model — explicitly designed to prevent another CentOS-style corporate acquisition — has become a template for how to structure an open source project to resist corporate capture.

Together with AlmaLinux, Rocky Linux ensured that the free RHEL-compatible ecosystem survived Red Hat's attempts to consolidate control. The 2023 source code restriction drama further galvanized the community and demonstrated that creative technical solutions can overcome corporate gatekeeping of open source code.

While Gregory Kurtzer was rallying the community around Rocky Linux with the power of founder mythology, CloudLinux was already doing the math. As a company that had been building RHEL-based products for years, they understood the enterprise Linux ecosystem intimately. On January 14, 2021 — barely a month after Red Hat's CentOS bombshell — CloudLinux announced Project Lenix, which would become AlmaLinux. The name comes from the Latin word for 'soul,' which is fitting for a project born from the death of CentOS.

CloudLinux's CEO Igor Seletskiy committed $1 million per year in funding and pledged to transfer governance to an independent foundation. The first beta landed on February 1, 2021, and the first stable release shipped on March 30, 2021 — beating Rocky Linux to market by nearly three months. Speed was AlmaLinux's superpower: they had the existing infrastructure and expertise from building CloudLinux OS.

True to their word, CloudLinux established the AlmaLinux OS Foundation as a 501(c)(6) non-profit and began transferring control. In September 2022, the foundation held its first community election, and Seletskiy stepped down as board chair to prove the project's independence. Benny Vasquez took over as chair, becoming the public face of AlmaLinux's community governance.

The real test came in June 2023 when Red Hat restricted public access to RHEL source code. AlmaLinux made a pragmatic pivot: instead of chasing 1:1 binary compatibility with RHEL (which was becoming legally fraught), they shifted to Application Binary Interface (ABI) compatibility. Vasquez explained that 99% of packages would still match RHEL, but they'd source code from CentOS Stream, UBI images, and upstream projects rather than RHEL source RPMs directly. It was a smart strategic move that differentiated AlmaLinux from Rocky's more confrontational approach.

AlmaLinux proved that a corporate-backed open source project can successfully transition to genuine community governance. CloudLinux's willingness to fund the project while ceding control became a model for how companies can sponsor community distributions without capturing them. The project's pivot to ABI compatibility in 2023 was influential, showing that RHEL compatibility doesn't require exact binary reproduction.

Together with Rocky Linux, AlmaLinux absorbed the majority of CentOS migrations and ensured continuity for enterprise workloads. The two projects serve slightly different audiences — AlmaLinux appeals more to organizations that value pragmatic corporate backing, while Rocky draws those who prioritize community-first governance.

The Glimpse project began on July 6, 2019, born from a long-simmering frustration: the GNU Image Manipulation Program's acronym, GIMP, is also a slur against disabled people and a common playground insult. For years, various community members had asked the GIMP project to consider a name change. The GIMP team's response was essentially: 'We've used this name for 20 years, it's widely known, and while the word can be offensive, that's not our intent.' End of discussion.

So Bobby Moss and a group of contributors decided to fork it. Glimpse would be GIMP, but with a professional name that wouldn't make people wince when suggesting it in corporate or educational settings. The project attracted genuine interest — there were real users who avoided GIMP specifically because of the name, and the idea of a 'corporate-safe' version had appeal.

But here's the thing about forking a massive, decades-old codebase just to change the name: it's a staggering amount of work for something that sounds simple. Every reference, every string, every build script needs updating. And you still need to keep up with upstream development. The Glimpse team released version 0.1 in November 2019 and version 0.2 in August 2020, but the contributor pool was always thin.

By May 2021, the project was effectively dead. Bobby Moss had left due to conflicts with his day job. The pandemic had scattered what few contributors remained. The Patreon was closed, the Twitter account deleted, and the website went dark. The GIMP project, with its decades of momentum and established contributor base, continued on unbothered. Glimpse proved that you can fork code easily, but you can't fork a community — especially when your primary value proposition is a name change.

Glimpse had virtually no lasting technical impact, but it did succeed in one thing: reigniting a conversation about naming in open source projects. The fork forced people to grapple with the tension between tradition and inclusivity, even if most concluded that a name change alone isn't worth the overhead of maintaining a separate fork.

The project also became a cautionary tale about the economics of 'superficial' forks. Changing a name sounds trivial, but maintaining compatibility with a fast-moving upstream while also rebranding is a full-time job that requires a community you don't yet have. It's often cited as an example of why contributing upstream (even on contentious issues) is almost always more effective than forking.

Here's a fun riddle: when is open source not open source? When it's Visual Studio Code. Microsoft's enormously popular editor is built from the 'vscode' repository on GitHub, which is MIT-licensed. But the binaries you download from code.visualstudio.com? Those are built with a proprietary Microsoft license, baked-in telemetry, and connections to Microsoft's extension marketplace. It's open source with an asterisk — and a big one.

The disconnect was first flagged in a GitHub issue back in November 2015, but it took until 2018 for someone to do something about it. The VSCodium project created a set of build scripts that clone Microsoft's vscode repository, build it without the proprietary product.json overlay, and distribute the resulting binaries under the original MIT license. No telemetry. No Microsoft branding. No proprietary license. Just the code, as the repository promises.

As a Microsoft VS Code maintainer once explained, when Microsoft builds VS Code internally, they 'lay down a customized product.json that has Microsoft specific functionality (telemetry, gallery, logo, etc.)' and produce a build under their license. When you build from the repo yourself, you get a clean build. VSCodium simply automates this clean build process and distributes the result.

VSCodium has become the go-to choice for developers who want VS Code's editing experience without Microsoft's data collection. It's available in most Linux package managers and has a dedicated following among privacy-conscious developers. The main trade-off is that some VS Code extensions are restricted to Microsoft's marketplace and won't install on VSCodium, though the project maintains its own Open VSX marketplace integration as a workaround.

VSCodium exposed a practice that has become increasingly common in open source: the 'open source core, proprietary distribution' model. By demonstrating the gap between VS Code's open source repository and its proprietary binaries, VSCodium forced a broader conversation about what 'open source' means when the binaries users actually download contain proprietary components.

The project also validated the viability of 'clean build' forks — projects that don't modify the source code but simply compile and distribute it differently. This model requires minimal maintenance compared to traditional forks, since the upstream code is used as-is. VSCodium showed that sometimes the fork isn't about the code at all; it's about the build pipeline and distribution.

Emby started life as Media Browser, an open source media server that let you organize and stream your personal media collection — think a self-hosted Netflix for your own movies, TV shows, and music. It was GPL-licensed and community-driven. Then, gradually, things started to change. Paywalls appeared for free users in the 3.x releases. Client app code started disappearing from public repositories. Server code was hidden or removed. The community noticed, and they weren't happy.

The breaking point came in late 2017 when community members discovered binary-only DLL files in the repository — proprietary blobs with no source code provided, which the project wouldn't build without. This was a textbook GPL violation. The Emby team's response was to double down: in December 2018, they announced that Emby 4.x would be fully closed-source.

Joshua Boniface and Andrew Rabert had been watching this slow-motion betrayal for months. When the closed-source announcement dropped on December 8, 2018, they moved fast. Within a day, Rabert had coined the name 'Jellyfin,' and the team began forking every repository they could legally grab. The first release shipped on December 30, 2018 — just 22 days after the fork was announced. It was one of the fastest community mobilizations in open source history.

Jellyfin has since grown into one of the most popular self-hosted media server projects, with active development, a thriving community, and support for virtually every platform. Boniface serves as Project Leader, and the project maintains a strict commitment to being fully free and open source — no premium tiers, no paywalls, no proprietary components. The contrast with Emby couldn't be starker.

Jellyfin became the definitive example of what happens when an open source project betrays its community's trust by going closed-source: the community takes the code and leaves. The project proved that for self-hosted software in particular, the community values transparency and control above all else — features and polish can come later.

Jellyfin also demonstrated that GPL-licensed projects have a built-in insurance policy against corporate capture. Because the last open source version was GPL-licensed, the community had every legal right to fork and continue development. The project's success has made 'going closed-source' a riskier proposition for any open source maintainer considering it, knowing that a Jellyfin-style fork could emerge overnight.

Node.js had already been through one dramatic fork — the io.js split of 2014 — so when Ayo.js appeared in August 2017, there was a certain 'here we go again' energy. But while io.js was about Joyent's corporate control and technical direction, Ayo.js was about something far more personal: a Code of Conduct dispute that tore the Technical Steering Committee apart.

The trigger was Rod Vagg, a TSC member and chief Node officer at NodeSource. Vagg tweeted support for an article critical of codes of conduct, which several community members found inflammatory and contrary to Node.js's own CoC. A formal vote was called to remove Vagg from the TSC. The thirteen-member committee voted: six 'no,' four 'yes,' two abstentions, one recusal. Vagg stayed.

The four who voted to remove Vagg — Anna Henningsen, Bryan Hughes, Myles Borins, and Jeremiah Senkpiel — didn't take the result well. They resigned from the TSC and, together with other community members, forked Node.js as Ayo.js (pronounced 'eye-oh,' Yoruba for 'joy,' and a nod to the io.js precedent). The name was clever; the project was not.

Unlike io.js, which had clear technical goals and experienced leadership, Ayo.js had no coherent vision beyond 'Node.js but with better community standards.' No significant technical changes were made. No releases were ever shipped. The repository was archived within a year, with zero meaningful development having occurred. The four who resigned eventually returned to the Node.js ecosystem in various capacities. Ayo.js became the textbook example of a spite fork — born from genuine frustration but without the technical purpose or community mass to sustain itself.

Ayo.js had no technical impact whatsoever, but it remains highly relevant as a case study in fork dynamics. It demonstrated that a fork needs more than legitimate grievances — it needs technical differentiation, sustained contributor energy, and a clear vision for why it should exist as a separate project. Without those elements, even justified anger dissipates quickly.

The incident did, however, contribute to ongoing discussions about governance, codes of conduct, and accountability in the Node.js community. Several of the Ayo.js participants continued to push for better community standards within Node.js itself, arguably achieving more through continued engagement than through the fork.

The Nextcloud fork is the platonic ideal of a 'founder takes the team and leaves' split. Frank Karlitschek created ownCloud in 2010 as an open source alternative to Dropbox and Google Drive — a self-hosted file sync and share platform. ownCloud Inc. was formed to commercialize it, but Karlitschek grew increasingly unhappy with how the company was managed. The tension was the classic open source conflict: the community wanted openness and sustainability, while the business side pushed for growth and revenue.

In April 2016, Karlitschek quietly resigned from ownCloud Inc. He published a blog post raising questions about the company's management, community relations, and priorities. Then, on June 2, 2016, he announced Nextcloud — a fork of ownCloud, launched with co-managing director Niels Mache. What made this devastating wasn't just Karlitschek leaving; it was that twelve core contributors left with him. When the founder of your open source project takes most of the engineering team, you don't have a project anymore.

The aftermath was spectacular. Within 12 hours of the Nextcloud announcement, ownCloud Inc.'s main US lenders cancelled their credit. The American entity was forced to shut down immediately, terminating 8 employees with no notice. Karlitschek himself tweeted: 'Wow. ownCloud Inc. collapses only 12 hours after the Nextcloud announcement. I didn't expect it to be so fragile. Sad day.' ownCloud accused Karlitschek of poaching developers, but the developers told a different story — contributor Arthur Schiwon said he left because 'not everything in the ownCloud Inc. company world evolved as I imagined.'

ownCloud GmbH (the German entity) survived by securing new investors, and ownCloud continues to exist as a product. But Nextcloud thoroughly won the market. It evolved from a file sync tool into a full collaboration platform with chat, video conferencing, document editing, and project management — essentially becoming the open source Google Workspace. Karlitschek's bet that the community and developers mattered more than the corporate shell was spectacularly validated.

Nextcloud is one of the most successful forks in open source history. It proved that when a founder leaves and takes the core team, the new project inherits the community's loyalty. Nextcloud grew to become the default self-hosted collaboration platform, deployed by the German federal government, major universities, and enterprises worldwide.

The fork also demonstrated the fragility of open source companies that fail to align their business interests with their community. ownCloud's collapse was so rapid and so complete that it became a cautionary tale in every open source business strategy discussion. The lesson was clear: in open source, you don't own the product — you steward the community. Lose the community, and the product follows.

LibreSignal started from a simple premise: Signal is great encrypted messaging software, but it depends on Google Play Services, which means it won't work on de-Googled Android phones or custom ROMs without Google's proprietary framework. For privacy-conscious users — arguably Signal's core audience — this was a maddening irony. A group of developers forked Signal-Android to create LibreSignal, replacing Google Cloud Messaging (GCM) with WebSocket-based push notifications and removing other Google dependencies.

The project seemed like a natural extension of Signal's mission. It made encrypted messaging available to the most privacy-conscious users — those who had deliberately removed Google from their phones. But Signal's creator, Moxie Marlinspike, saw it differently. In May 2016, he asked LibreSignal to stop using Signal's servers and the Signal name.

Marlinspike's reasoning was practical but controversial. He argued that supporting third-party clients was complex and expensive, and that federation — allowing different clients to connect to the same servers — had previously 'degraded the UX for our users and held us back in the development process.' He estimated they had lost '6 months to a year of progress' from their earlier federation experiment with CyanogenMod. He wanted full control over the client experience.

On May 24, 2016, the LibreSignal project posted a single word: 'abandoned.' The developers had no viable alternative — without access to Signal's servers, a messaging app is just a pretty text editor. Marlinspike did acknowledge the need, saying he'd consider a 'clean, well written, and well tested' pull request for WebSocket support in the official app. Eventually, Signal did add support for running without Google Play Services. But LibreSignal's death crystallized a fundamental tension in privacy software: does the maintainer's right to control their infrastructure trump the community's right to modify open source software?

LibreSignal's death raised fundamental questions about the limits of open source software when the code depends on centralized infrastructure. You can fork the code, but you can't fork the servers — and for networked software, the servers are everything. This tension has influenced every subsequent debate about federated vs. centralized messaging protocols.

The incident also highlighted the paradox of Signal's position: a privacy-focused project that depends on Google's proprietary push notification infrastructure. While Signal eventually addressed this by adding WebSocket support, the LibreSignal episode damaged Signal's reputation among the hardest-core privacy advocates and fueled ongoing debates about whether Signal is truly committed to software freedom or merely to a specific vision of privacy under Marlinspike's control.

In 2014, the Debian project went through one of its most divisive internal debates in decades: whether to adopt systemd as the default init system, replacing the venerable SysV init scripts that had served Unix-like systems for generations. The decision to go with systemd was technically sound by most accounts, but it split the community right down the middle between modernizers and traditionalists.

A group calling itself the 'Veteran Unix Admins' collective announced they would fork Debian into a new distribution called Devuan (pronounced 'Dev-One'). Their manifesto was heavy on Unix philosophy and light on compromise — they viewed systemd as a monolithic, creeping dependency that violated the sacred principle of 'do one thing and do it well.' Several high-profile Debian developers, including Ian Jackson and Joey Hess, quit the project entirely over the acrimony surrounding the debate.

The fork took its sweet time materializing. Despite being announced in late 2014, the first stable release (Devuan 1.0 Jessie) didn't land until May 2017 — a full three years later. The project essentially tracks Debian releases and strips out systemd, replacing it with sysvinit, OpenRC, or runit. It's a thankless job that requires constant effort to de-systemd-ify packages.

Devuan has survived longer than most predicted, reaching version 6.0 'Excalibur' in November 2025 based on Debian 13. But it remains extremely marginal — a niche within a niche. Most of the Linux world moved on and accepted systemd, while Devuan soldiers on as a principled stand that few actually need.

The init wars of 2014 were really about something deeper: the tension between Unix minimalism and modern system management complexity. Devuan is the monument to that tension — small, defiant, and perpetually relevant to a very specific subset of sysadmins who will pry SysV init from their cold, dead hands.

Devuan's direct impact on the broader Linux ecosystem has been minimal — the vast majority of distributions adopted systemd without looking back. However, its indirect impact was significant: the fork served as a pressure valve for legitimate concerns about systemd's scope and complexity, and it kept alternative init systems alive as viable options.

The Devuan project also demonstrated that forking an entire distribution is enormously difficult and resource-intensive. While it proved the anti-systemd position wasn't just internet grumbling, the project's perpetually small user base showed that most users care more about things working than about init system purity.

On April 7, 2014, the Heartbleed vulnerability (CVE-2014-0160) was publicly disclosed, revealing that a critical bug in OpenSSL's heartbeat extension had been silently exposing the private memory of roughly two-thirds of the internet's web servers for two years. It was one of the worst security vulnerabilities in internet history, and when the OpenBSD developers looked at the OpenSSL code that caused it, they were horrified by what they found.

The OpenBSD team, led by the ever-diplomatic Theo de Raadt, didn't just find Heartbleed — they found a codebase riddled with decades of cruft, dead code paths, custom memory allocators that defeated exploit mitigations, and code that supported platforms nobody had used since the 1990s. Their response was characteristically blunt: fork it and gut it. On April 22, 2014, they announced LibreSSL.

The first week was legendary. The OpenBSD developers deleted over 90,000 lines of C code — roughly half the codebase. They ripped out support for ancient platforms like VMS and OS/2, removed the custom malloc that had masked Heartbleed, eliminated the heartbeat extension entirely, and generally went on a code-deletion rampage that became the stuff of developer folklore. Bob Beck presented the progress at BSDCan in May 2014, documenting the carnage with evident satisfaction.

LibreSSL shipped its first portable release (2.0.0) in July 2014, just three months after Heartbleed. It became the default SSL library on OpenBSD and was adopted by several other BSDs and some Linux distributions. But its broader mission — replacing OpenSSL everywhere — never materialized.

The fork's greatest achievement was arguably not LibreSSL itself, but the shock it delivered to the OpenSSL project. Heartbleed plus the embarrassment of being publicly forked by the OpenBSD team led to the creation of the Core Infrastructure Initiative (CII), which funded two full-time OpenSSL developers and a comprehensive code audit. OpenSSL commits increased by 52.7% in the post-Heartbleed period. LibreSSL scared OpenSSL into becoming better.

LibreSSL's most lasting impact was catalytic rather than direct. By publicly humiliating OpenSSL's codebase and demonstrating that half of it was unnecessary dead weight, the fork forced the entire industry to take SSL/TLS library quality seriously. The CII was created, OpenSSL got its first funded developers and security audit, and the broader conversation about critical infrastructure funding began in earnest.

LibreSSL itself remains the default on OpenBSD and is used in some other contexts, but it never displaced OpenSSL in the wider ecosystem. Together with BoringSSL, it created a three-way split in the OpenSSL ecosystem that ultimately improved all three projects through competitive pressure and code sharing.

Two months after LibreSSL made headlines by aggressively pruning OpenSSL's codebase, Google quietly announced its own fork: BoringSSL. Where LibreSSL was born of righteous anger, BoringSSL was born of engineering pragmatism. Google had been maintaining over 70 patches on top of OpenSSL across multiple internal copies used in Chrome, Android, and various infrastructure — and the maintenance burden was becoming unsustainable.

Adam Langley, Google's TLS guru, announced the fork on June 20, 2014. The name was deliberately anticlimactic — 'boring' as in 'not exciting,' because the last thing you want your cryptographic library to be is exciting. Unlike LibreSSL's dramatic code purges, BoringSSL was a methodical consolidation of Google's existing patches into a single coherent library.

What makes BoringSSL unusual is that Google explicitly told everyone not to use it. It's not meant to be a general-purpose OpenSSL replacement — it has no stable API, no guaranteed backward compatibility, and Google reserves the right to change anything at any time. Despite this, BoringSSL has become enormously influential because it ships inside Chrome (used by billions) and Android (used by billions more), and has been adopted by Cloudflare and other major infrastructure providers.

The project quickly diverged from OpenSSL in meaningful ways. Google implemented features like certificate transparency, QUIC protocol support, and post-quantum cryptographic algorithms in BoringSSL before they appeared anywhere else. It became a testing ground for the future of TLS.

BoringSSL represents a different philosophy from LibreSSL: rather than trying to fix OpenSSL for everyone, Google just fixed it for Google — and the rest of the world happened to benefit from the improvements that flowed back and forth between the three forks.

BoringSSL is arguably the most successful of the three OpenSSL forks by sheer reach — it secures the TLS connections of Chrome and Android, meaning billions of devices use it daily. Its willingness to experiment with cutting-edge cryptography (post-quantum algorithms, QUIC support) has pushed the entire TLS ecosystem forward faster than any standards body could alone.

The fork also established a model that other companies would follow: instead of trying to influence a slow-moving open-source project, just fork it internally, optimize it for your needs, and let improvements flow back organically. It's corporate open source at its most honest — Google never pretended BoringSSL was for anyone but Google.

By late 2014, Node.js was in trouble. The project that had revolutionized server-side JavaScript was stagnating under Joyent's corporate stewardship. Releases were slow, V8 engine updates lagged months behind Chrome, and the community had no formal governance structure — decisions were made by whoever Joyent appointed as project lead. When TJ Fontaine was named leader in January 2014, many top contributors felt the appointment was unilateral and didn't reflect the community's wishes.

In December 2014, Fedor Indutny — a prolific Node.js core contributor — created io.js by forking Node.js on GitHub. But Indutny wasn't the leader; that was the whole point. io.js adopted an open governance model with a Technical Committee where decisions were made by consensus among active contributors. Mikeal Rogers, the NodeConf organizer, and Isaac Schlueter, the npm creator and former Node.js lead, were among the heavyweights who backed the fork.

io.js moved fast. Its first release (1.0.0) shipped in January 2015, just weeks after the fork announcement, and it immediately jumped to V8 4.1 — bringing ES6 features that Node.js users had been begging for. The message was clear: we can ship faster without corporate gatekeeping. Within months, io.js had more contributors and more momentum than Node.js itself.

But here's the twist: the fork was never meant to be permanent. Mikeal Rogers later described it as 'a giant, unifying step forward.' The goal was always to force Joyent to the negotiating table and establish proper open governance. And it worked. TJ Fontaine stepped down, the Linux Foundation brokered the creation of the Node.js Foundation, and in September 2015, io.js v3.3 and Node.js v0.12 merged into Node.js v4.0 under the new foundation's open governance model.

io.js is the textbook example of a fork as leverage — a credible threat that achieved its goals and then gracefully dissolved.

io.js is perhaps the most successful fork in open-source history precisely because it succeeded in making itself unnecessary. The open governance model it pioneered became the template for the Node.js Foundation (later the OpenJS Foundation), and the rapid release cadence it demonstrated became Node.js's permanent approach. Every Node.js release since v4.0 carries io.js's DNA.

The fork also proved that credible competition is the fastest way to reform a stagnant project. Joyent went from corporate gatekeeper to foundation member in less than a year, entirely because io.js demonstrated that the community could — and would — route around corporate obstruction.

During the Christmas holidays of 2013, a Swedish developer named Torkel Odegaard was tinkering with Kibana 3, Elasticsearch's open-source dashboard frontend. He loved how easy Kibana made it to build dashboards, but he was frustrated by a fundamental limitation: Kibana only talked to Elasticsearch. If your metrics were in Graphite (as many were at the time), you were out of luck. The Kibana team had explicitly decided that supporting other data sources wasn't their mission.

So Torkel forked Kibana 3's codebase and started building what he initially called 'Grafana' — a portmanteau whose exact etymology he's been coy about (Graf + ana? Graphite + Kibana?). The first commit hit GitHub on December 5, 2013, and the project was publicly released in January 2014. From day one, the key differentiator was multi-data-source support: Grafana could visualize time-series data from Graphite, InfluxDB, OpenTSDB, and eventually dozens of other backends.

What started as a holiday side project turned into one of the most consequential forks in software history. Grafana quickly became the de facto standard for infrastructure monitoring dashboards, beloved by DevOps teams worldwide. In 2015, Torkel met Raj Dutt and Anthony Woods in New York, and together they founded Raintank (later rebranded to Grafana Labs in 2017).

The company's growth trajectory has been remarkable. From a Series A of $24 million in 2019, Grafana Labs raised progressively larger rounds, reaching a $6 billion valuation in August 2024 after a $270 million Series D extension. The open-source project itself now has thousands of contributors and supports virtually every data source imaginable.

Grafana is proof that sometimes a fork doesn't need drama or conflict — just a developer who sees a gap the original project won't fill, and has the skill and tenacity to fill it.

Grafana became the universal dashboard layer for infrastructure monitoring, effectively democratizing observability. Before Grafana, monitoring dashboards were tightly coupled to specific data stores; after Grafana, any backend could be visualized through a single, beautiful interface. It spawned an entire ecosystem — Grafana Loki for logs, Grafana Tempo for traces, Grafana Mimir for metrics — that competes with the full Elastic stack.

The fork also illustrates how a simple architectural decision (multi-source support vs. single-source loyalty) can be the foundation of a multi-billion-dollar company. Kibana remained tied to Elasticsearch and became a component of the Elastic stack; Grafana became a platform that transcends any single data source.

The FFmpeg/Libav split is one of the nastiest governance disputes in open-source history — a saga of personality conflicts, competing visions of code quality, and a 'merge everything' strategy that ultimately won through sheer persistence. At its center was Michael Niedermayer, FFmpeg's top contributor and self-appointed benevolent dictator, whose leadership style was as productive as it was controversial.

On March 13, 2011, a group of prominent FFmpeg developers — many with commit access — announced they were forking the project as Libav. Their grievances centered on Niedermayer's governance: he had final say on technical decisions largely because he out-contributed everyone else, the code review process was inconsistent, and there were ongoing disputes about code quality standards and commit policies. The Libav developers wanted rigorous peer review for every commit, clean code, and collective decision-making with no single leader.

What followed was a confusing, politically charged period. Libav initially had significant momentum — they controlled the ffmpeg.org domain for a time, and major distributions including Debian and Ubuntu switched to Libav. The Libav team genuinely believed they were the legitimate continuation and FFmpeg was the fork. Meanwhile, Niedermayer kept FFmpeg alive and played a masterstroke: he systematically merged every Libav commit back into FFmpeg, ensuring FFmpeg remained a strict superset of Libav's features. This infuriated Libav developers, who hadn't consented to having their work merged, but it was devastatingly effective.

By 2014, Debian switched back to FFmpeg. Ubuntu followed in 2015. The distributions recognized that FFmpeg was simply more complete — it had everything Libav had plus more. In June 2015, Niedermayer himself stepped down as FFmpeg leader amid renewed governance tensions, but by then FFmpeg had won the fork war decisively.

Libav's last release was in 2018, and it was effectively abandoned by 2020. The fork had better governance principles but couldn't match FFmpeg's raw output and the pragmatic 'merge everything' approach that kept FFmpeg's feature set unbeatable.

The FFmpeg/Libav split caused years of confusion for package maintainers and users, but it ultimately had a clarifying effect. FFmpeg emerged as the undisputed leader in open-source multimedia processing, while the fork's emphasis on code quality did push FFmpeg to improve its review processes. The Libav codebase contributions, merged back by Niedermayer, enriched FFmpeg significantly.

The fork also became a case study in fork strategy: Libav had the better governance model but FFmpeg had the better merge strategy. By staying a superset of Libav, FFmpeg made the fork technically unnecessary, regardless of the governance arguments.

Hudson was born in 2004 as a side project by Kohsuke Kawaguchi, a developer at Sun Microsystems who was tired of breaking builds. It grew into the most popular continuous integration server in the Java world, with a thriving ecosystem of plugins and an active community of contributors. Then Oracle bought Sun in 2010, and everything went sideways.

The trouble started when Oracle began asserting control over the Hudson trademark, applying for a registered trademark in December 2010 without consulting the community. The Hudson developers tried to negotiate — they offered to place the trademark under a neutral third party like the Software Freedom Conservancy — but Oracle wasn't interested in sharing control. The community saw this as Oracle trying to leverage trademark ownership to control the project's direction and potentially commercialize it.

On January 11, 2011, Kawaguchi proposed renaming the project from Hudson to Jenkins. The community vote was devastating for Oracle: 214 in favor, 14 against. On January 29, the rename was approved, and the Jenkins project was born. Oracle responded by declaring that Hudson would continue under their stewardship and that Jenkins was 'the fork' — a characterization the Jenkins community vehemently rejected, since they represented the overwhelming majority of contributors.

The developer exodus was swift and nearly total. Approximately 85% of developers immediately migrated to Jenkins. Of the top 25 plugins, 21 moved to Jenkins; the other four simply had no active commits. Oracle tried to salvage Hudson by donating it to the Eclipse Foundation in May 2011, but it was too late — the community had spoken with their feet.

Hudson limped along at Eclipse for several years before being declared obsolete in February 2017. Jenkins, meanwhile, became the dominant CI/CD platform worldwide, spawning companies like CloudBees and serving as the backbone of software delivery pipelines across the industry.

Jenkins became the undisputed king of CI/CD, with tens of thousands of installations worldwide and over 1,800 plugins. It essentially defined the modern continuous integration workflow and spawned an entire ecosystem of companies, tools, and practices. CloudBees built a venture-backed business around Jenkins, and the project influenced every CI/CD tool that came after it.

The fork also became Oracle's most embarrassing open-source moment (in a field of stiff competition). It demonstrated that trademarks are meaningless when the entire community walks out the door — you can own the name, but you can't own the people, the plugins, or the momentum.

When GNOME 3.0 launched on April 6, 2011, it was one of the most radical redesigns in desktop Linux history. Gone was the familiar panel-based desktop with its taskbar, system tray, and application menu. In its place was GNOME Shell — a sleek, minimalist interface built around activities, workspaces, and full-screen application launchers. The GNOME team believed they were building the future of desktop computing. A very vocal portion of their user base believed they were committing UI suicide.

German Perugorria, an Argentine Arch Linux user known as 'Perberos,' decided to do something about it. On June 18, 2011, he posted on the Arch Linux forums announcing that he had forked GNOME 2 and was calling the project MATE (named after the yerba mate plant, a staple South American beverage). The initial work was unglamorous but essential: renaming every GNOME 2 component to avoid conflicts with GNOME 3 packages, so both could be installed on the same system.

Perberos was soon joined by Stefano Karapetsas, who helped with development, and critically by Clement Lefebvre of Linux Mint, who packaged MATE for Debian-based distributions. Linux Mint 12 (November 2011) shipped with MATE as an option alongside GNOME 3, giving the fledgling project instant exposure to one of the most popular Linux distributions.

The project steadily matured. MATE didn't just freeze GNOME 2 in amber — it continued active development, porting components to GTK3, adding new features, and improving hardware support. It became an official desktop environment in the Debian, Fedora, Ubuntu, and Arch repositories, achieving a legitimacy that many early observers doubted it would reach.

MATE proved that there was a genuine, sustained demand for the traditional desktop metaphor that GNOME 3 had abandoned — not just nostalgia, but a preference for a workflow that many users found more productive.

MATE validated the idea that users should have a choice in desktop paradigms rather than being forced into whatever vision the upstream project dictates. Together with Cinnamon, it demonstrated that the GNOME 3 transition — while technically sound — had left a significant portion of users behind, and that those users represented a market worth serving.

The project also showed that 'keeping the old version alive' can be a viable long-term strategy, not just a temporary stopgap. MATE is now a mature, actively developed desktop environment in its own right, not just a GNOME 2 museum piece.

While MATE took the approach of preserving GNOME 2 wholesale, the Linux Mint team tried a different strategy: could they tame GNOME 3's new technology into a traditional desktop experience? The answer, after several frustrating attempts, was Cinnamon.

The journey started in April 2011, when GNOME 3 launched and Linux Mint's founder Clement Lefebvre faced a dilemma. Mint was one of the most popular Linux distributions, and its users overwhelmingly preferred a traditional desktop layout. Lefebvre initially tried to work within the GNOME 3 framework, creating 'Mint GNOME Shell Extensions' (MGSE) — a set of extensions that bolted familiar elements like a taskbar and application menu onto GNOME Shell. Linux Mint 12 (November 2011) shipped with MGSE alongside MATE.

But MGSE was a bandage, not a solution. GNOME Shell's extension API was unstable, extensions broke with every GNOME update, and the fundamental architecture made it difficult to achieve the traditional desktop experience Mint users wanted. In January 2012, Lefebvre took the plunge and forked GNOME Shell itself, creating 'Project Cinnamon.'

The first Cinnamon releases were still heavily dependent on GNOME 3 components, but Lefebvre and the Mint team steadily replaced one dependency after another. By October 2013, Cinnamon 2.0 achieved full independence — it was no longer a GNOME Shell frontend but a completely self-contained desktop environment. The team built their own file manager (Nemo), text editor (Xed), and system tools, creating a complete desktop stack.

Cinnamon became Linux Mint's flagship desktop environment, and Mint's consistent ranking as one of the most popular Linux distributions gave Cinnamon a massive user base. Lefebvre's design philosophy — that a desktop should be immediately familiar and productive, not a vehicle for UX experimentation — resonated with millions of users who wanted Linux without a learning curve.

Cinnamon proved that you can take modern technology and wrap it in a traditional interface without compromise. It became the gateway desktop for millions of Linux newcomers through Linux Mint, which consistently ranks among the top Linux distributions. The 'familiar by default' philosophy influenced how other projects think about UX transitions.

Together with MATE, Cinnamon represents the two possible responses to a radical upstream redesign: preserve the old (MATE) or build the new on modern foundations (Cinnamon). Both found their audiences, and both demonstrated that the GNOME team's assumption that everyone would follow them to GNOME Shell was optimistic at best.

Nexuiz started in 2002 as a passion project — an open-source, fast-paced arena first-person shooter built on the DarkPlaces engine (itself a heavily modified Quake engine). Founded by Lee Vermeulen and Forest 'LordHavoc' Hale, it attracted a dedicated community of developers, artists, and players over the following years. The first release came in 2005, and by 2010 it had a small but loyal following in the open-source gaming world. Then Lee Vermeulen blew it all up.

In early 2010, Vermeulen quietly struck a deal with IllFonic, a commercial game studio, to create a proprietary console remake of Nexuiz for Xbox 360. The deal gave IllFonic control of the Nexuiz name and the nexuiz.com domain. The community — the dozens of developers, artists, and mappers who had contributed code and content under the GPL for years — were not consulted. Most learned about the deal from news articles rather than from their own project lead.

The community was furious, and for good reason. The GPL-licensed code contained contributions from over 30 developers who had never consented to having their work used in a proprietary product. IllFonic's plan to use GPL code in a closed-source Xbox game raised serious legal questions. Beyond the licensing issues, there was a fundamental betrayal of trust: the founders had sold the community's collective work for private profit.

On March 22, 2010, over 30 core developers and contributors announced Xonotic as a community-driven fork. They took the GPL codebase, the community infrastructure, and most of the active developers, and started fresh with a commitment to genuine community governance.

The IllFonic Nexuiz launched on XBLA in 2012 and was a commercial failure — it was poorly reviewed and quickly forgotten. Xonotic, meanwhile, continued as a niche but actively maintained open-source arena shooter, releasing regular updates and maintaining a small but dedicated player community.

Xonotic's impact on the broader gaming industry was minimal — it remained a niche open-source game. But its impact on open-source governance was significant. The fork became a cautionary tale about what happens when project founders treat community contributions as personal property. The fact that Vermeulen could sell rights to a project built largely by volunteers highlighted the importance of formal contributor agreements and clear governance structures.

The IllFonic debacle also reinforced the power of the GPL in protecting community interests — while the trademark could be sold, the code itself couldn't be relicensed without every contributor's consent, which made the proprietary remake legally precarious.

The LibreOffice fork is the textbook example of what happens when a corporation acquires an open source project and proceeds to treat its community like an inconvenience. When Oracle swallowed Sun Microsystems in 2010, the OpenOffice.org community braced for impact. They were right to worry.

On September 28, 2010, a group of long-time OpenOffice.org contributors — including Thorsten Behrens, Italo Vignoli, and others — announced The Document Foundation (TDF) and launched LibreOffice. They even invited Oracle to join and donate the OpenOffice.org brand. Oracle's response? They demanded that every Community Council member involved with TDF resign immediately, leaving the Council staffed entirely by Oracle employees. Subtle.

The exodus was swift and devastating. Within months, virtually every major Linux distribution switched from OpenOffice to LibreOffice. Oracle, apparently realizing they were holding a bag of nothing, laid off the remaining OpenOffice developers in April 2011 and donated the carcass to the Apache Software Foundation in June 2011. Apache OpenOffice lingered on life support for years, occasionally releasing updates that were mostly just security patches.

LibreOffice, meanwhile, thrived spectacularly. With a proper community governance model, regular releases, and contributions from companies like Red Hat, Collabora, and SUSE, it became the de facto open source office suite. The project attracted hundreds of developers and established itself as a genuine alternative to Microsoft Office.

The OpenOffice.org saga became the canonical example cited whenever someone asks 'what could go wrong if a corporation mishandles an open source community?' The answer: everything. Everything could go wrong.

LibreOffice became the standard open source office suite worldwide, shipping as the default in every major Linux distribution. It effectively killed OpenOffice.org, which limps along under Apache with minimal development activity and increasingly infrequent releases.

More broadly, the fork demonstrated that a well-organized community can successfully wrest control of a major software project from a hostile corporate steward. It became the template for future governance-driven forks and proved that brand recognition means nothing if the developers have already left the building.

OpenSolaris was Sun Microsystems' bold experiment in open-sourcing one of the most sophisticated operating systems ever built. Solaris had legendary technologies — ZFS, DTrace, Zones — and when Sun opened the source code in 2005 under the CDDL license, it was a genuine gift to the systems programming world. Then Oracle bought Sun in 2010, and the gift shop closed permanently.

Oracle killed OpenSolaris with ruthless efficiency. They stopped publishing source code, shut down community infrastructure, and made it clear that Solaris was going back behind the corporate curtain. The memo leaked to the community was blunt: OpenSolaris was done. But the code was already out there, and a group of engineers led by Garrett D'Amore at Nexenta decided that this technology was too important to let die.

The challenge was formidable: while most of Solaris had been open-sourced, critical components — parts of libc, the NFS lock manager, crypto modules, and device drivers — remained proprietary. D'Amore, along with Rich Lowe, Jason King, and others, spent the summer of 2010 writing replacements from scratch or porting them from BSD. By August 3, 2010, an entirely open system was booting, and illumos was born (the name comes from 'illuminare,' Latin for illuminate).

Bryan Cantrill of Joyent became one of illumos's most vocal champions, delivering his legendary 'Fork Yeah!' talk at LISA 2011 that became a cult classic in systems programming circles. The illumos kernel became the foundation for several distributions: SmartOS (Joyent/Samsung), OmniOS, and OpenIndiana, keeping the Solaris lineage alive in production environments.

While illumos never achieved mainstream adoption — Linux had already won that war — it preserved technologies like ZFS and DTrace that influenced the entire industry. Oracle eventually abandoned Solaris development too, proving that the community's fears were entirely justified.

illumos preserved groundbreaking technologies — ZFS, DTrace, Zones, and Crossbow — that might otherwise have been locked behind Oracle's proprietary walls. ZFS was later ported to Linux (via OpenZFS) and FreeBSD, becoming one of the most important filesystems in the storage industry. DTrace inspired similar tracing tools across operating systems.

While illumos itself remained niche, SmartOS powered significant cloud infrastructure at Joyent (later Samsung), and OmniOS served enterprise users who needed Solaris-grade reliability without Oracle licensing. The fork proved that even an operating system as complex as Solaris could survive corporate abandonment through determined community effort.

CyanogenMod started as the ultimate power-user dream: take Android, strip out the bloatware, add the features Google wouldn't, and give it to the people. What began in 2009 as one developer's custom ROM for the HTC Dream became the most popular alternative Android distribution in history, running on over 50 million devices at its peak. And then capitalism happened.

Stefanie Jane (known online as Cyanogen, formerly Steve Kondik) was a Samsung software engineer who started enhancing JesusFreke's custom firmware in 2009. Google quickly noticed and sent a cease-and-desist letter over the inclusion of proprietary Google apps. After negotiations, CyanogenMod continued without bundling Google's apps directly, and the project exploded in popularity. It offered features like per-app permissions, theme engines, and performance tweaks that stock Android wouldn't get for years.

In 2013, Kondik co-founded Cyanogen Inc. with Kirt McMaster to commercialize the project. McMaster, a brash CEO type, famously declared they were going to 'put a bullet through Google's head' — which is exactly the kind of thing that sounds great in a pitch meeting and terrible everywhere else. The company raised $110 million in venture capital and signed deals with phone manufacturers, most notably OnePlus. That partnership collapsed spectacularly when Cyanogen Inc. signed an exclusive deal with Micromax for the Indian market, blindsiding OnePlus.

The corporate drama accelerated. McMaster's aggressive strategy alienated the open source community that had built CyanogenMod. Kondik was eventually forced out, McMaster stepped down in October 2016, and two days before Christmas 2016, Cyanogen Inc. shut down entirely. In a final act that was either generous or desperate, Kondik urged the development community to fork the work so it wouldn't go to waste. On Christmas Eve 2016, LineageOS appeared on XDA forums, rising from the ashes like a phoenix that had learned a valuable lesson about venture capital.

CyanogenMod proved that there was massive demand for an Android that respected user autonomy — features like granular permissions, built-in ad blocking, and root access attracted millions of technically-inclined users. Many features pioneered by CyanogenMod were later adopted by stock Android.

The project's commercialization and collapse became a cautionary tale about the tension between open source communities and venture capital. LineageOS, its spiritual successor, continues with a deliberately community-first approach, supporting hundreds of devices and maintaining the largest active custom ROM community. The CyanogenMod saga demonstrated that an open source community can survive even the death of its corporate steward — as long as someone forks the code in time.

CyanogenMod started as a hobby project by Steve Kondik (online handle 'Cyanogen') — a custom Android ROM that gave users features, performance, and customization that stock Android couldn't match. By its peak, CyanogenMod was installed on millions of devices and had become synonymous with Android modding culture. It was community-driven, volunteer-powered, and beloved.

Then came Cyanogen Inc. In 2012, Kondik co-founded the company with Kirt McMaster to commercialize the project. McMaster was the business guy with big ambitions — he once boasted about wanting to 'put a bullet through Google's head.' The company raised over $100 million in venture capital, struck partnerships with Microsoft and OnePlus, and tried to turn a community ROM into a mobile operating system platform. The community watched nervously.

The wheels came off in 2016. In July, about a fifth of the staff were fired, the Seattle offices were gutted, and McMaster stepped down as CEO. Kondik left shortly after, publicly blaming McMaster for the company's failure. The business had burned through its funding on enterprise pivots and platform deals that never materialized, while the community project that made it all possible was neglected.

Two days before Christmas 2016, Cyanogen Inc. announced it would shut down all services and discontinue CyanogenMod nightlies by December 31. The community didn't even pause for eggnog. On Christmas Eve, a group of developers announced LineageOS on the XDA forums. By January 22, 2017, the first official builds were available. By March 2017, LineageOS had one million users. The community had saved itself, again proving that the code belongs to whoever cares enough to maintain it.

LineageOS kept the custom Android ROM ecosystem alive after the catastrophic failure of Cyanogen Inc.'s commercialization attempt. It remains the most popular custom Android ROM, providing privacy features, extended device support (keeping old phones usable long after manufacturers abandon them), and customization options that stock Android lacks.

The CyanogenMod-to-LineageOS transition is frequently cited as a warning about what happens when a community project is commercialized by people who don't understand or respect the community. McMaster's hubris — claiming he'd kill Google — and the company's ultimate collapse became a parable about the gap between venture capital ambition and open source reality.

Pale Moon is the browser equivalent of that one person at the party who insists vinyl sounds better — they're not entirely wrong, but the world has moved on and they haven't noticed. Created by M.C. Straver (known online as Moonchild) in 2009, Pale Moon started as an optimized rebuild of Firefox 3.5.2 with tweaked compiler settings for Windows. It was a performance project, not a philosophical one. That changed when Mozilla started redesigning Firefox.

The real divergence came with Mozilla's Australis redesign in Firefox 29 (2014), which replaced the classic Firefox interface with a Chrome-like design. Many longtime Firefox users hated it. Pale Moon doubled down on preserving the classic pre-Australis UI and continued supporting XUL/XPCOM extensions — the entire extension ecosystem that Firefox would kill off in 2017 with Firefox 57 (Quantum). This made Pale Moon a refuge for users who had built their browsing workflow around legacy extensions.

In 2017, Pale Moon moved to its own platform called UXP (Unified XUL Platform), forked from Firefox 52 ESR, with the Goanna rendering engine (forked from Gecko). This was the point of no return — Pale Moon was now maintaining its own browser engine, a Herculean task for what is essentially a one-developer project with some community help.

The security implications have been a persistent concern. Maintaining a browser engine fork with minimal resources means security patches from Mozilla don't automatically flow downstream. In 2019, this was dramatized when Pale Moon's archive server was hacked, with older installers infected with malware for months before discovery. While current releases weren't affected, it highlighted the fragility of the project's infrastructure.

Pale Moon remains a niche browser with a dedicated but small user base, essentially frozen in amber as a monument to what Firefox used to be. In 2021, the project announced a change of direction toward becoming more of its own thing rather than just 'old Firefox,' but the fundamental challenge remains: maintaining a browser engine is a billion-dollar endeavor, and Pale Moon does it on donations.

Pale Moon preserved a browser paradigm that Mozilla actively chose to destroy — the classic Firefox interface and XUL extension ecosystem. For a small but passionate user base, it remained the only way to use browser workflows they'd built over a decade. Some legacy enterprise applications that depended on XUL-based browser plugins found Pale Moon to be their only option short of running ancient Firefox versions.

However, Pale Moon also became a cautionary tale about the limits of preservation-oriented forks. Maintaining a browser engine with minimal resources inevitably leads to security concerns, and the project has faced criticism from the security community. It demonstrates that sometimes the original project's direction (in this case, Firefox moving to WebExtensions and multi-process architecture) was driven by genuine technical necessity, not just whim.

The MariaDB story is deeply personal. Michael 'Monty' Widenius didn't just create MySQL — he named it after his eldest daughter, My. When he created the fork, he named it after his youngest daughter, Maria. This is a man who names databases after his children, and he watched helplessly as his firstborn was sold to a company he fundamentally didn't trust.

The chain of events started in 2008 when Sun Microsystems bought MySQL AB for $1 billion. Monty, who had already left MySQL AB, wasn't thrilled but tolerated Sun. Then in 2009, Oracle — the world's largest proprietary database company — moved to acquire Sun. Monty went full alarm mode. He launched a 'Save MySQL' campaign, gathered 50,000 signatures on a petition to the European Commission to block the deal, and publicly warned that Oracle would slowly strangle MySQL to protect its own database business. The EC approved the deal anyway in January 2010, with Oracle making vague promises about MySQL's continued development.

Monty didn't wait around to see if Oracle would keep those promises. He had already started MariaDB in 2009, working through his company Monty Program Ab. MariaDB was designed as a drop-in replacement for MySQL — same APIs, same protocols, same feel — but with a commitment to staying truly open source. The fork attracted key MySQL developers and quickly gained features that MySQL lacked.

The adoption was dramatic. One by one, the major Linux distributions switched their default database from MySQL to MariaDB: Fedora, openSUSE, Arch, Slackware, and most significantly, Red Hat Enterprise Linux. Wikipedia migrated to MariaDB in 2013. Google switched its internal MySQL instances to MariaDB. The MariaDB Foundation was established in 2012 to ensure the project remained community-governed.

MariaDB's corporate story has had its own turbulence — MariaDB Corporation (the commercial entity, separate from the Foundation) went public via SPAC in 2022 and nearly went bankrupt in 2024 — but the open source project itself remains healthy and widely deployed. Meanwhile, Oracle has maintained MySQL as a viable product, somewhat proving the pessimists wrong about total abandonment, though many of Monty's concerns about open-source commitment have proven prescient.

MariaDB fundamentally altered the database landscape. By positioning itself as a drop-in MySQL replacement with better features and genuine open source governance, it forced a reckoning across the industry. Major Linux distributions, Wikipedia, Google, and countless enterprises migrated, proving that even a database as entrenched as MySQL could be successfully forked.

The fork also established a template for 'protective forks' — forks created not because the original is technically inadequate, but because the community fears what a new corporate owner might do. This playbook was later followed by LibreOffice, and variations of it echoed in Valkey (Redis) and OpenTofu (Terraform). Monty proved that the original creator of a project carries enormous moral authority when calling for a fork.

Nagios was the undisputed king of open source monitoring for a decade. Built by Ethan Galstad starting in 1999, it became the default way to monitor servers, networks, and services across the IT industry. But Galstad ran Nagios like a personal fiefdom, and by the late 2000s, the kingdom was rotting from within.

The core problem was simple: Nagios development was a one-man show. Galstad controlled all commits, and community-submitted patches piled up for months — sometimes years — without being reviewed or merged. There was a two-year gap between Nagios Core releases. Community developers who had written significant improvements found their work gathering dust in a bug tracker that felt more like a black hole. Meanwhile, Galstad was increasingly focused on Nagios Enterprises, the commercial arm, while the open source project stagnated.

In May 2009, a group of prominent Nagios community developers and addon creators said enough. They forked Nagios as Icinga (the Zulu word for 'it searches' or 'it examines') and announced their intention to build a truly community-led monitoring project. The fork started as a straightforward improvement of the Nagios Core codebase, adding the database flexibility and modern web interface that the community had been begging for.

Galstad's response was disappointment rather than anger — he admitted to the development bottleneck but was hurt that the Icinga team hadn't approached him first. The Nagios community split along predictable lines, with addon developers and system administrators taking sides in what Free Software Magazine called 'one of the most heated forks in free software.'

The real vindication for Icinga came with Icinga 2, released in 2014 as a complete ground-up rewrite. Rather than continuing to polish the Nagios codebase, the team built a modern monitoring system with a distributed architecture, a proper API, native cluster support, and a configuration language that didn't make sysadmins weep. It was the product that Nagios should have become if it had accepted community input.

Icinga demonstrated that a benevolent dictator model only works if the dictator is actually benevolent and engaged. By embracing community development, Icinga eventually surpassed Nagios in features, architecture, and community vitality. Icinga 2's modern architecture — with native clustering, API-first design, and proper configuration management — represented the monitoring tool that Nagios Core never became.

The fork also reshaped the monitoring landscape. While both projects continue to exist, Icinga's success (along with the rise of Prometheus, Grafana, and other modern tools) eroded Nagios's once-dominant market position. Nagios Enterprises pivoted hard toward commercial products, while Icinga maintained its open source ethos with commercial support from NETWAYS.

Drizzle was the cool kid's MySQL — a radical reimagining of what a relational database should be in the cloud era. Started in mid-2008 by Brian Aker, a senior MySQL architect at Sun Microsystems, Drizzle's thesis was that MySQL had become bloated and enterprise-focused when the future was lightweight, cloud-native microservices. Strip out the stored procedures, the views, the triggers, the ACL system, and half the other enterprise features, and what you'd have left would be a lean, mean, web-scale machine.

The timing seemed perfect. Cloud computing was exploding, and the idea of a 'micro-kernel database' with a plugin architecture resonated with developers building the next generation of web applications. The project attracted an absurdly impressive roster of corporate sponsors: Google, Sun/Oracle, Rackspace, Intel, Hewlett-Packard, Red Hat, Canonical, Percona, and others. If blue-chip sponsor lists were a currency, Drizzle would have been a unicorn.

But sponsor logos on a website don't write code. Despite the corporate backing, Drizzle struggled with consistent contributor commitment. Many sponsors contributed developers part-time or for specific features, but the sustained, dedicated development effort a database engine requires never fully materialized. The first GA release didn't arrive until March 2011 — nearly three years after the project started — and by then the landscape had shifted.

NoSQL databases like MongoDB and Redis had captured the 'cloud-native' mindset that Drizzle was targeting. MariaDB had absorbed the 'better MySQL' narrative. And MySQL itself, under Oracle's stewardship, had actually improved significantly with MySQL 5.6 and 5.7. Drizzle was squeezed from every direction.

Development wound down around 2013-2014, and in July 2016, the maintainers officially pulled the plug, stating simply that 'none of us have any time to dedicate to Drizzle anymore.' It was a quiet death for a project that had once promised to revolutionize databases. The patron list had been impressive; the contributor list, less so.

Drizzle's most lasting impact was as a cautionary tale. It proved that having a brilliant vision and an all-star sponsor list means nothing without sustained contributor commitment. The 'strip MySQL down to its essentials' philosophy was ahead of its time in some ways — the microservices database concept would later be partially realized by projects like CockroachDB, TiDB, and Vitess — but Drizzle itself never reached the critical mass needed to sustain an independent database engine.

Several ideas from Drizzle — particularly its plugin architecture and its emphasis on removing legacy cruft — influenced thinking in the broader MySQL ecosystem. Some Drizzle contributors went on to do significant work on MariaDB and Percona Server. The project's real legacy is intellectual rather than code-based.

Plex is the rare fork that doesn't just survive — it becomes a massively successful commercial product that eclipses its parent project in every measurable way. It's also a fork that the open source community has complicated feelings about, because it took community-built code and turned it into a proprietary empire.

It started in late 2007 when Elan Feingold, a developer who wanted a media center for his Mac, began porting XBMC (Xbox Media Center) to Mac OS X. XBMC was an open source media player originally built for the original Xbox, and it had a passionate community but was primarily Linux-focused. Around the same time, Cayce Ullman and Scott Olechowski — software executives fresh from selling their company to Cisco — noticed Feingold's work in the XBMC forums and reached out. In January 2008, the three-person team formed.

They collaborated with the XBMC project until May 21, 2008, when divergent goals forced a split. The XBMC team was focused on building the best local media player; Feingold and company wanted to build a client-server architecture that could stream media across devices and networks. They forked the code, named it Plex in July 2008, and Plex, Inc. was incorporated in December 2009.

The pivot that made Plex was the client-server model. Rather than being a standalone media player like XBMC (later renamed Kodi), Plex split into a server component that transcodes and serves media and lightweight clients on every platform imaginable — phones, tablets, smart TVs, game consoles, streaming sticks. Your media library became accessible anywhere, and Plex handled the messy work of transcoding video to match each device's capabilities.

Plex grew into a legitimate business, raising venture funding and eventually adding an ad-supported free streaming service, live TV integration, and music streaming. The open source roots became increasingly distant as the server component went proprietary. Kodi (XBMC) and Plex now occupy completely different niches: Kodi is the open source purist's local media player, while Plex is the polished commercial product your non-technical friends actually use.

Plex is arguably the most commercially successful open source fork ever created. It defined the personal media server category and brought media streaming to mainstream users who would never touch Kodi or a Linux box. The client-server architecture it pioneered influenced how the entire industry thinks about personal media libraries.

For the open source community, however, Plex represents an uncomfortable reality: the most successful outcome of an open source fork was to become a proprietary product. The XBMC/Kodi community watched their code become the foundation of a venture-funded company that eventually closed its source. Whether this is a success story or a cautionary tale depends entirely on your perspective on open source philosophy.

The Funpidgin fork is the fruit fly of open source drama: tiny, short-lived, and yet perfectly illustrative of a much larger principle. It started with a text box. Specifically, the text input field in Pidgin version 2.4, released in 2008, which could no longer be manually resized.

Pidgin (formerly Gaim) was the dominant open source multi-protocol instant messaging client, supporting AIM, MSN, Yahoo, ICQ, IRC, and dozens of other protocols through a single interface. When version 2.4 landed, it replaced the manually resizable text input area with an auto-resizing one that grew and shrank based on how much text you typed. Sounds minor? Users didn't think so.

The community erupted. Bug reports flooded in. Users who had customized their chat layouts were furious. The input field was sometimes rendered nearly invisible, and the auto-resize behavior felt unpredictable. Users asked for a simple preference toggle — let people choose between auto-resize and manual resize. The Pidgin developers refused, closed the bug as WONTFIX, and were, by many accounts, combative bordering on hostile in their responses. It became a textbook example of 'developer knows best' syndrome.

A fork called Funpidgin appeared, restoring the resizable text input and adding other user-requested features the Pidgin team had rejected. It was later renamed to Carrier. The fork attracted some attention and press coverage (Jeff Atwood wrote about it on Coding Horror), but it never achieved critical mass. The reality is that forking a chat client over a UI preference is hard to sustain — you need continuous protocol updates, security patches, and community energy, and a text box grievance doesn't generate that kind of long-term motivation.

Funpidgin/Carrier quietly died, and Pidgin itself faded into irrelevance as instant messaging moved to proprietary platforms (Facebook Messenger, WhatsApp, Slack) that multi-protocol clients couldn't support anyway. The text box that launched a fork became a footnote in a story about a dying software category.

Funpidgin/Carrier had virtually zero lasting technical impact — it died quietly and Pidgin itself became increasingly irrelevant. But the fork's cultural impact was outsized. It became the canonical example cited in discussions about developer-user relations, the 'WONTFIX' problem, and the arrogance that can infect open source maintainers.

The incident demonstrated that even trivial-seeming UX decisions can become existential when developers refuse to engage with user feedback. It's taught in open source governance discussions as a perfect illustration of how to alienate your community. The lesson isn't about text boxes — it's about whether you listen to the people who use your software.

In the mid-2000s, CodeIgniter was the PHP framework that people actually used. In a landscape of overwrought Java-inspired frameworks and spaghetti-code WordPress plugins, CodeIgniter was refreshingly simple: small footprint, clear documentation, and it just worked. But it was also controlled by EllisLab, a company that moved at its own pace and didn't take kindly to community demands for modern PHP features.

On May 31, 2007, a group of CodeIgniter community members started a fork called BlueFlame, quickly renamed to Kohana (Sioux for 'swift'). Their grievance was governance: EllisLab made all the decisions about CodeIgniter's direction, PHP version requirements, and feature additions. The community wanted strict PHP 5 support (CodeIgniter still supported PHP 4), proper OOP patterns, and a more transparent development process.

Kohana 1.0 shipped in July 2007, and version 2.0 followed in November, built purely on PHP 5 with a modern OOP framework. The project attracted enthusiastic developers and built a reputation for clean, well-designed code. Kohana embraced conventions that CodeIgniter resisted: autoloading, cascading filesystem, and proper namespacing.

Then came Kohana 3.0 in September 2009, and this is where things went sideways. The new version was a complete rewrite with incompatible changes to classes, folder structure, and syntax — and no migration path or adequate documentation. The community fractured. Developers who had built projects on Kohana 2 felt abandoned, and the documentation gap meant newcomers couldn't figure out how to use the framework.

The final nail was Laravel. When Taylor Otwell released Laravel 3 in 2011 and Laravel 4 in 2013, it captured exactly the audience Kohana was targeting: developers who wanted a modern, elegant PHP framework with excellent documentation. Laravel's documentation was world-class; Kohana's was famously sparse. The choice was obvious. Kohana was officially deprecated on July 1, 2017, a victim not of CodeIgniter but of a newer, shinier competitor that simply executed better.

Kohana pushed the PHP framework ecosystem toward modernity. By demanding PHP 5, proper OOP, and community governance, it validated the frustrations that many developers had with CodeIgniter and helped shift expectations for what a PHP framework should look like. Several patterns Kohana pioneered — cascading filesystem, HMVC architecture — influenced the broader PHP ecosystem.

But Kohana's ultimate impact was indirect: it demonstrated the market demand that Laravel would later satisfy. The lesson for PHP framework history is that being first to identify the right problems doesn't guarantee you'll be the one to solve them. CodeIgniter survived (and was eventually open-sourced to the community). Kohana didn't. Laravel won. The PHP framework wars were brutal.

The Beryl fork is one of the few fork stories with a happy ending: the combatants realized they were being ridiculous, made up, and merged back together. If only all open source disputes ended this way.

In 2006, Linux desktop compositing was the hottest thing in the open source world. Compiz, written by David Reveman at Novell, brought wobbly windows, rotating desktop cubes, and transparency effects to Linux — making it, for a brief shining moment, look cooler than both Windows Vista and Mac OS X. The community went wild. Developers started contributing plugins and enhancements at a frantic pace.

The problem was that Reveman and the Novell team weren't particularly interested in merging community contributions. Quinn Storm, a community developer who had been maintaining a popular branch of Compiz with community patches (the 'quinnstorm branch'), grew frustrated. Patches weren't being accepted upstream, communication between Novell's internal team and the community mailing list was poor, and the development process was opaque. On September 19, 2006, Storm and the community developers forked Compiz as Beryl.

Beryl quickly became the more feature-rich and community-friendly option. It had its own window decorator (Emerald), dropped GNOME dependencies in favor of a flat-file configuration backend, and iterated rapidly on visual effects. Both projects continued in parallel for about six months, which is approximately how long it takes for everyone to realize that maintaining two competing implementations of wobbly windows is a waste of human potential.

On March 30, 2007, cooler heads prevailed. The Beryl and Compiz communities agreed to merge into Compiz Fusion: Compiz would handle the core compositing engine and base plugins, while the community (formerly Beryl) would maintain the extended plugins, decorators, and configuration tools. Compiz Fusion 0.6.0 shipped in October 2007 as the reunified project.

The reconciliation was a rare moment of maturity in open source politics. Unfortunately, the entire compositing window manager category was eventually rendered moot when GNOME moved to Mutter and KDE built its own compositor, but for one brief year, the Beryl/Compiz drama was the most entertaining thing on the Linux desktop.

The Beryl/Compiz story is significant not for the fork itself but for the re-merge. It remains one of the very few examples of an open source fork being successfully reunified, and it demonstrated that forks don't have to be permanent. The key was that neither side had irreconcilable differences — the dispute was about process, not vision.

The broader impact was on the Linux desktop experience. Compiz (and Beryl) made Linux visually competitive with proprietary operating systems at a time when that mattered enormously for adoption. The wobbly windows and desktop cube became iconic demonstrations at Linux install fests worldwide. Even though the technology was eventually superseded, it played an important role in proving that the Linux desktop could be polished and visually appealing.

XFree86 had been the dominant X Window System implementation for Linux and BSD systems since the early 1990s, but by the early 2000s, its governance was becoming a problem. The project was controlled by a small 'Core Team' of 16 people, 7 of whom also sat on the board of directors. Development happened behind closed doors—the CVS repository and mailing lists were not publicly accessible. It was open source in license but cathedral in practice.

The drama escalated in 2003 when Keith Packard, one of the most prolific X developers, committed his XFIXES extension just before a feature freeze without prior review. The Core Team stripped his commit access and eventually expelled him entirely, claiming he was secretly plotting a fork. Packard responded by creating xwin.org as a gathering point for disaffected developers. The first fork attempt, Xouvert, launched in August 2003 but fizzled quickly.

Then David Dawes, XFree86's president, dropped the real bombshell. In January 2004, he announced XFree86 License 1.1, adding a credit clause requiring all binary distributions to acknowledge the XFree86 Project in their documentation. The Free Software Foundation declared it GPL-incompatible. Richard Stallman and Theo de Raadt both condemned the move. It was the licensing equivalent of setting your own house on fire.

The X.Org Foundation formed rapidly, forking from XFree86 4.4 RC2 (before the license change took effect) and merging in X11R6.6 changes. By April 2004, X11R6.7 was released, and Linux distributions raced to switch. Fedora, Debian, OpenBSD—everyone jumped ship. Keith Packard found a new home, and X.Org introduced modular development that made the codebase far more maintainable.

XFree86 made its last commit in 2009. It's one of the cleanest fork victories in open source history: bad governance plus bad licensing equals total project death.

X.Org became the universal X Window System implementation, shipping on virtually every Linux distribution and BSD system. The fork also catalyzed a modernization of X development: the modular build system made contributions easier, and the project eventually became the foundation for work on Wayland, its eventual successor.

The XFree86 debacle became a cautionary tale about licensing changes in established open source projects. It proved that even a dominant, decades-old project can die in months if it loses community trust.

Xouvert was the fork that tried and failed, the warm-up act before X.Org stole the show. By 2003, frustration with XFree86's insular governance had reached a boiling point. The project was run by a small clique, development happened behind closed doors, and the expulsion of Keith Packard made it clear that dissent would not be tolerated.

In August 2003, a group of developers announced Xouvert (a play on the French word 'ouvert,' meaning open) as a community-governed fork of XFree86. The idea was appealing: take the XFree86 codebase and run it with transparent governance and open development. The project got a Slashdot bump and some early enthusiasm.

But Xouvert had a fatal problem: it didn't have the heavyweight developers. Keith Packard and the other major XFree86 contributors weren't involved. Xouvert managed a single source release in December 2003 before the energy dissipated. When the XFree86 license controversy erupted in January 2004 and the X.Org Foundation formed with proper institutional backing and the key developers, Xouvert became instantly irrelevant.

Xouvert is a textbook example of why forks need more than grievances—they need the people who actually write the code. The governance complaints were legitimate (X.Org's success proved that), but Xouvert couldn't attract the critical mass of talent needed to sustain a project of that complexity.

Xouvert's direct impact was minimal—it shipped one release and disappeared. But its existence served as an early warning signal that XFree86's governance was unsustainable. It demonstrated the level of community frustration and arguably primed the ecosystem for the rapid adoption of X.Org when it launched months later.

Xouvert is primarily remembered as the fork that lost the XFree86 fork race, a reminder that being first to fork doesn't mean being first to succeed.

By the mid-1990s, GCC was the most important compiler in the free software world—and one of the most frustrating to contribute to. The GNU Compiler Collection was maintained under Richard Stallman's FSF with a philosophy that prioritized stability and the GNU project's needs above all else. Experimental work piled up in external forks: Cygnus Solutions maintained their own patches, the Linux kernel developers had optimizations that couldn't get merged, the pgcc (Pentium GCC) project had Intel-specific improvements, and the Fortran community had their own fork. Everyone was doing great work. None of it was making it into mainline GCC.

On August 15, 1997, developers from Cygnus, the Linux community, and several other factions announced EGCS (Experimental/Enhanced GNU Compiler System, pronounced 'eggs'). The announcement came from D.V. Henkel-Wallace at Cygnus. The premise was simple: merge the scattered forks, accept contributions more readily, and develop more aggressively. Jeff Law coordinated the effort, handling releases, merging patches, and keeping the project on track.

The results were dramatic. EGCS development outpaced GCC development almost immediately. While FSF's GCC languished, EGCS shipped better optimization, added new architecture support, and attracted the developer energy that had been frustrated by GCC's slow pace. Linux distributions started shipping EGCS instead of GCC.

By April 1999, the FSF acknowledged reality: they halted GCC 2.x development, blessed EGCS as the official GCC, and appointed the EGCS team as the new GCC maintainers. The EGCS Steering Committee renamed itself the GCC Steering Committee. GCC 2.95, released in July 1999, was the reunification release. It was a hostile takeover disguised as a merge—and everyone was better off for it.

The EGCS fork fundamentally changed how GCC was governed, replacing the FSF's centralized gatekeeping with a community steering committee model that persists to this day.

EGCS is the rare fork that didn't just succeed—it consumed the original. The fork-then-merge pattern it established became a template for other projects, most notably when the community fork proves more vigorous than the official version. The GCC Steering Committee model that emerged from EGCS still governs GCC today.

The fork also demonstrated that even the FSF's flagship projects weren't immune to community pressure. It shifted power from a single organization to a broader community of stakeholders, establishing a governance precedent that influenced numerous subsequent projects.

In the early 2000s, Apple had a browser problem. Safari was shipping with the aging Internet Explorer for Mac as the default, and Apple needed a modern rendering engine. Their engineers evaluated two candidates: Mozilla's Gecko and KDE's KHTML. Gecko was more feature-complete but massive and complex. KHTML was small (under 140,000 lines), cleanly designed, and standards-compliant. Apple chose KHTML.

On June 25, 2001, Lisa Melton at Apple started the internal WebKit project, forking KHTML and its JavaScript engine KJS. Apple developed it behind closed doors for nearly two years before Steve Jobs unveiled Safari at Macworld in January 2003. When Apple finally announced they were using KHTML, the KDE community had mixed feelings—flattered that Apple chose their engine, but concerned about how the relationship would work.

Those concerns proved justified. Apple's development style clashed violently with KDE's open process. Apple would send back changes as enormous, poorly documented 'code drops'—massive patches containing dozens of interdependent changes that were nearly impossible to integrate back into KHTML. KDE developers described the code as 'hugely inconsistent' with 'basically no way of merging in one change without bringing a whole bunch of others in.' When KDE developers tried to contribute patches to WebKit, they sat unreviewed for months, with some rejected over whitespace formatting. One KDE developer called the relationship a 'bitter failure.'

Apple eventually open-sourced WebKit in June 2005, releasing the full source under a BSD license. This helped somewhat, but the codebases had diverged so significantly that meaningful re-convergence never happened. KDE eventually adopted WebKit for their Konqueror browser in 2007, essentially acknowledging that the fork had overtaken the original.

WebKit went on to power Safari, early Android browsers, and briefly Google Chrome—until Google forked WebKit into Blink in 2013, creating yet another generation of the KHTML family tree.

WebKit is one of the most consequential forks in software history. It powers Safari on every Apple device, meaning hundreds of millions of people use KHTML's descendant daily without knowing it. The WebKit/Blink family tree (KHTML -> WebKit -> Blink) now powers the overwhelming majority of web browsers worldwide.

The fork also became a case study in corporate open source dynamics. Apple took a small community project, built something world-changing on top of it, but handled the upstream relationship poorly enough to generate lasting resentment. The lesson was absorbed by later corporate open source participants.

On April 3, 2013, Google dropped a bombshell on the web development world: after years of contributing to WebKit alongside Apple, they were forking the rendering engine into a new project called Blink. The announcement was polite and professional, but the underlying message was unmistakable — Google and Apple's visions for the web's rendering engine had become irreconcilable.

The core conflict was architectural. Chrome used a multi-process architecture where each tab ran in its own sandboxed process — a design fundamental to Chrome's security and stability. WebKit, as maintained primarily by Apple, used a different multi-process model (WebKit2) that was optimized for Apple's ecosystem. Supporting both architectures in one codebase had become a source of mounting complexity. According to Apple, they had directly asked Google if they would contribute their multi-process support back to WebKit, and Google said no.

Beyond the multi-process question, the two companies simply wanted different things. Google wanted to experiment rapidly with new web platform features, iterating fast and breaking things if necessary. Apple prioritized stability, backward compatibility, and tight integration with iOS and macOS. These are both reasonable positions, but they're fundamentally incompatible when you're sharing a codebase.

Google's first act was dramatic: they identified 7,000 files and 4.5 million lines of code in WebKit that Chrome didn't need and planned to remove them. The split allowed both projects to move faster — WebKit could optimize for Apple's priorities without worrying about Chrome's needs, and Blink could experiment freely.

The aftermath reshaped the browser landscape entirely. Opera, which had already announced it was dropping its own Presto engine, adopted Blink. Microsoft abandoned EdgeHTML and switched Edge to Chromium/Blink in 2019. By 2025, Blink powers approximately 81% of global web traffic, making it the most dominant rendering engine in history — a level of monoculture that has raised serious concerns about web standards and competition.

Blink's fork from WebKit is one of the most consequential forks in computing history. It enabled Chrome to move faster, adopt new web standards more quickly, and maintain its dominant market position. But it also created a browser engine monoculture that many web standards advocates find deeply troubling — when one engine controls 81% of the web, the line between 'implementing standards' and 'defining them' gets dangerously blurry.

The fork also triggered a cascade of engine consolidation: Opera abandoned Presto, Microsoft abandoned EdgeHTML, and the browser engine landscape collapsed from five viable engines to essentially three (Blink, WebKit, Gecko) — with Blink dominating to an extent that the others are increasingly marginalized.

Sodipodi was a vector graphics editor created in 1999 by Estonian developer Lauris Kaplinski, built on top of Raph Levien's Gill (GNOME Illustration Application). It was functional but idiosyncratic—Kaplinski had a clear vision for a general-purpose vector editor that didn't necessarily align with strict standards compliance or conventional UI design. He also maintained tight control over the project's direction.

By 2003, a group of four developers—Ted Gould, Bryce Harrington, Nathan Hurst, and MenTaLguY—had grown frustrated with the project's trajectory. They wanted full SVG standard compliance, a more accessible user interface, and a more open development process that welcomed third-party contributions. Initially, they tried to create a separate branch within Sodipodi, but the differences in vision were too fundamental for a branch to contain.

The four forked Sodipodi into Inkscape in November 2003. The name was a portmanteau of 'ink' and 'landscape.' The new team immediately made significant technical changes: they migrated the codebase from C to C++, adopted the gtkmm toolkit bindings, and completely redesigned the user interface. Most importantly, they committed to full SVG compliance—Inkscape would be an SVG editor first, with the file format driving the feature set rather than the other way around.

Sodipodi continued under Kaplinski's stewardship for a while but gradually faded as Inkscape absorbed the community's energy and attracted new contributors. Inkscape grew into the de facto open source vector graphics editor, often described as 'the GIMP of vector graphics.' It remains actively developed with a substantial user base.

Inkscape became the standard open source tool for vector graphics editing, used by millions of designers, illustrators, and hobbyists. It filled a critical gap in the open source creative software ecosystem alongside GIMP and Blender, proving that community-driven development could produce professional-quality creative tools.

The fork validated the importance of standards compliance as a guiding principle. By committing to SVG rather than inventing a proprietary format, Inkscape ensured interoperability with the broader graphics ecosystem and attracted users who needed reliable SVG editing.

Mandriva Linux (formerly Mandrake Linux) was once one of the most popular Linux distributions, known for its user-friendliness and strong European following. But the company behind it, Mandriva S.A., was a slow-motion train wreck of financial mismanagement that made its community watch in horror for years before they finally pulled the emergency brake.

The killing blow came in September 2010. Edge-IT, a key Mandriva subsidiary, was placed into liquidation by a Paris commercial court on September 2nd. By September 17th, all assets were liquidated and employees were let go. Most of the core developers who actually built the distribution found themselves suddenly unemployed, watching a company they'd poured years into dissolve in a French courtroom.

Just one day after the liquidation, on September 18, 2010, the Mageia project was announced. The speed wasn't coincidence — the community had been preparing for this eventuality as Mandriva lurched from crisis to crisis. Former employees and long-time contributors came together to fork the distribution under a not-for-profit model, explicitly designed to prevent the corporate instability that had plagued Mandriva.

Mageia 1 arrived in June 2011, with over 100 contributors organized into more than 10 teams. The project established proper community governance with elected leadership, transparent decision-making, and independence from any single corporate sponsor. It was everything Mandriva should have been but never was.

However, Mageia's story is bittersweet. While the fork succeeded in technical terms, the Linux distribution landscape had shifted dramatically. Ubuntu had captured the mindshare Mandriva once held, and Mageia settled into a niche existence — respected by its users but never recapturing the mainstream relevance of its ancestor. Mandriva S.A. itself finally died in 2015, and its other fork (OpenMandriva) carries on with similarly modest adoption.

Mageia demonstrated that a community can rescue a distribution from corporate collapse and sustain it through volunteer effort and proper governance. The not-for-profit model it adopted has served as a template for other community-driven distributions.

However, the fork also illustrates a harsh reality: technical competence and good governance aren't enough to guarantee mainstream success. The Linux distribution market had moved on, and Mageia was forking a project whose peak popularity had already passed. It survives as a quality niche distribution, beloved by its community but without the momentum to challenge Ubuntu, Fedora, or Arch.

Mambo started life in 2000 as a product of Australian company Miro Construct Pty Ltd, headed by CEO Peter Lamont. It grew into one of the most popular open source content management systems of the early 2000s, winning multiple awards and building a vibrant community of developers and designers. But there was always a tension at its core: the software was open source, but Miro held the reins.

The powder keg ignited on August 8, 2005, when Lamont incorporated the Mambo Foundation without consulting the development team. He appointed himself President of the Board, bypassing the two developer representatives—Andrew Eddie and Brian Teeman—who had been elected to the Mambo Steering Committee. The Foundation's charter included provisions the developers felt contradicted previous agreements and violated core open source principles. It was governance theater: the appearance of community control with none of the substance.

Nine days later, on August 17, 2005, the entire 20-person core development team walked out. With help from the Software Freedom Law Center, they formed Open Source Matters, a proper non-profit. Lamont fired back with a public rebuttal titled 'The Mambo Open Source Controversy—20 Questions With Miro,' but it was too late. The community had already voted with their feet.

The team announced the name 'Joomla'—a phonetic spelling of the Swahili word 'jumla' meaning 'all together'—on September 1, and shipped Joomla 1.0 just fifteen days later. It was one of the fastest fork-to-release turnarounds in open source history.

Joomla went on to become one of the three dominant CMSes alongside WordPress and Drupal, powering millions of websites. Mambo, stripped of its entire development team, limped along until 2008 before going dormant. Ironically, even some of the Joomla founders—Eddie, Teeman, and Mitch Pirtle—eventually departed Joomla within its first two years, suggesting governance tensions are a recurring virus in CMS communities.

Joomla became one of the 'big three' open source CMSes, powering tens of millions of websites and spawning a massive ecosystem of extensions and templates. It demonstrated that when a corporate sponsor alienates its entire developer community, the community can walk away and take the project's momentum with them.

The fork also established a template for CMS governance disputes and influenced how other projects structured their foundations. The formation of Open Source Matters as a non-profit set a standard for community-governed open source projects.

Theo de Raadt was a founding member of the NetBSD project, one of the original free BSD operating systems that emerged from the UC Berkeley codebase in the early 1990s. He was also, by most accounts, extraordinarily difficult to work with. Peter Wayner wrote that de Raadt 'began to rub some people the wrong way,' and Linus Torvalds once described him simply as 'difficult.' But difficult people sometimes produce extraordinary things.

In December 1994, the NetBSD core team asked de Raadt to resign, citing personality conflicts and disagreements over development practices. When he refused, they revoked his CVS access—effectively expelling him from the project he'd helped found. The specifics remain somewhat murky, but the pattern is clear: a brilliant, abrasive developer whose interpersonal style became incompatible with the project's culture.

Rather than slinking away, de Raadt forked NetBSD 1.0 in October 1995 and created OpenBSD with a singular obsession: security. While other operating systems treated security as one concern among many, de Raadt made it the organizing principle. OpenBSD pioneered proactive code auditing—systematically reviewing the entire codebase for vulnerabilities rather than waiting for them to be discovered in the wild.

The results speak for themselves. OpenBSD has had only two remote holes in the default install in its entire history. The project produced OpenSSH, which became the de facto standard for secure remote access across virtually every operating system on Earth. It also produced OpenBGPD, OpenNTPD, LibreSSL, and other security-critical infrastructure that's used far beyond OpenBSD itself.

By 2024, the project had diverged so completely from its origins that every single file from the original NetBSD fork had been either modified or removed. The expulsion of one difficult developer resulted in some of the most important security infrastructure in computing history.

OpenBSD's impact on computing security is almost impossible to overstate. OpenSSH is installed on billions of devices and is the backbone of secure remote administration worldwide. The project's code audit practices influenced security thinking across the entire software industry, and its motto ('Only two remote holes in the default install') set a standard that few other operating systems can match.

Beyond direct contributions, OpenBSD demonstrated that a fork driven by a strong (even abrasive) technical vision can produce results that benefit the entire computing ecosystem. The NetBSD team may have had valid interpersonal complaints about de Raadt, but the world got OpenSSH out of the deal.

Matt Dillon was not your average FreeBSD contributor. An Amiga developer in the late 1980s and a FreeBSD committer since 1994, he had strong opinions about operating system design—particularly about how to handle symmetric multiprocessing (SMP). When FreeBSD 5.x adopted a fine-grained locking approach inspired by traditional Unix SMP designs, Dillon was convinced it was the wrong path: too complex, too fragile, and destined to create maintenance nightmares.

Dillon tried to push his alternative vision within FreeBSD, advocating for a message-passing architecture that would make SMP more manageable. The disagreements grew heated. Other FreeBSD developers weren't buying what he was selling, and eventually his commit access was revoked. It wasn't a personality clash so much as a fundamental architectural disagreement—two irreconcilable visions of how a kernel should handle modern hardware.

In June 2003, Dillon forked FreeBSD 4.8 and announced DragonFly BSD on the FreeBSD mailing lists on July 16. He initially described it as 'the logical continuation of the FreeBSD 4.x series,' positioning it as the road not taken. The project attracted a small but dedicated community of developers who shared his vision.

DragonFly's most significant technical achievement is the HAMMER filesystem, a 64-bit filesystem featuring infinite snapshots, master-slave replication, checksumming, and fsck-less mounting. HAMMER was declared production-ready in 2009, and its successor HAMMER2 became stable in 2018. These innovations proved that Dillon's instincts about OS design, while unconventional, produced genuinely novel results.

Notably, despite the acrimonious split, DragonFly BSD and FreeBSD maintain a cooperative relationship, sharing bug fixes, driver updates, and improvements. It's one of the more civil post-fork relationships in the BSD world.

DragonFly BSD remains a niche operating system, but its technical contributions have been significant. The HAMMER filesystem influenced thinking about filesystem design, and Dillon's message-passing approach to SMP provided a useful counterpoint to the dominant fine-grained locking paradigm. Some of FreeBSD 5.x's SMP issues validated Dillon's concerns, even if the project eventually worked through them.

The fork also demonstrated that BSDs can coexist and collaborate even after splitting. The BSD ecosystem's culture of sharing code across projects meant that DragonFly's innovations could benefit the broader community.

Presto was born inside Facebook in 2012, created by Martin Traverso, Dain Sundstrom, David Phillips, and Eric Hwang to solve Facebook's need for fast interactive queries over their massive Hadoop data warehouse. It was a genuine engineering triumph — a distributed SQL query engine that could query petabytes of data in seconds. Facebook open-sourced it, and the wider data engineering community loved it.

Then Facebook decided it wanted tighter control. In 2018, Facebook management began granting commit rights to internal developers who had no prior Presto experience, bypassing the meritocratic process the founders had established. It was a classic corporate override of open source governance: the company that hosted the project decided its employees should have more power over it, regardless of contribution history.

The three co-founders — Traverso, Sundstrom, and Phillips — didn't stick around to argue. They left Facebook in late 2018, founded Starburst Data as a commercial entity, and forked the project as PrestoSQL. The Presto Software Foundation was created in January 2019 to provide independent governance. But Facebook wasn't done: in September 2019, they established the Presto Foundation at the Linux Foundation and promptly began enforcing a trademark on the 'Presto' name.

This forced the final rebrand. On December 27, 2020, PrestoSQL became Trino — a clean break with a new identity. The name change freed the project from Facebook's trademark claims and marked the point of no return. Since then, Trino has become the de facto successor, with significantly more active development, faster feature advancement, and broader adoption than Facebook's PrestoDB. The creators took their project, their community, and their vision — and won.

Trino demonstrated that in open source, the creators and community matter more than corporate sponsorship. Despite Facebook retaining the 'Presto' name and the Linux Foundation affiliation, Trino became the more actively developed and widely adopted project. Starburst, the company built around Trino, raised over $400 million in venture capital, proving the commercial viability of the fork.

The Presto/Trino split also served as a warning to companies that host open source projects: if you alienate the original creators by overriding meritocratic governance, they can simply leave and take the project's soul with them. The code stays, but the talent, vision, and community follow the people who built it.

SugarCRM had been one of the poster children of the open-core business model: a commercial CRM platform with a free Community Edition that served as both a loss leader and an ecosystem builder. For years, an active community of consultants, integrators, and developers built businesses around SugarCRM CE. SalesAgility, a Scottish company, was one of the most active SugarCRM Community Edition consultancies in the world.

In early 2013, the writing was on the wall. SugarCRM began distancing itself from the Community Edition, and in February 2014 they made it official: no more open-source releases, only bug fixes for the existing CE. The message was clear — SugarCRM was going fully proprietary. For companies like SalesAgility whose entire business model depended on an open-source CRM, this was an existential threat.

SalesAgility had read the tea leaves early. On October 21, 2013, they released SuiteCRM 7.0, forked from the last open-source SugarCRM Community Edition. But SuiteCRM wasn't just a continuation — it was an upgrade. SalesAgility added features that had previously been locked behind SugarCRM's commercial paywall: workflow management, a customer portal, quotes, products, contracts, reporting, and mobile support. Everything SugarCRM charged for, SuiteCRM gave away.

The fork grew steadily. By its 10th anniversary in 2023, SuiteCRM had built a community of over 88,000 people, achieved more than 800,000 downloads, and served an estimated 4 million users worldwide. SalesAgility joined the Open Source Initiative as a corporate sponsor, cementing the project's commitment to remaining genuinely open source.

SuiteCRM is a textbook case of what happens when a company pulls the rug out from under its open-source community: the community simply takes the last open version and keeps going, often building something better than what the original company kept for itself.

SuiteCRM became the world's most popular open-source CRM, filling the void left by SugarCRM's retreat from open source. It demonstrated that the open-core model carries a fundamental risk: if you build a community around free software and then take it away, that community has both the motivation and the means to replace you.

The fork also provided a cautionary tale for other open-core companies considering similar moves. SugarCRM's commercial product continued to operate, but it lost the community goodwill and ecosystem that had been one of its key competitive advantages against Salesforce.

NCSA HTTPd was the web server that helped build the early World Wide Web. Written by Rob McCool at the National Center for Supercomputing Applications (the same NCSA that gave us Mosaic), it was the most popular web server software by 1994. Then McCool left NCSA in mid-1994, and development ground to a halt. The most important piece of web infrastructure in the world was suddenly unmaintained.

The web didn't wait. System administrators who depended on NCSA HTTPd started writing their own patches—bug fixes, security patches, feature additions—and sharing them via email. In February 1995, eight of these patch-swapping sysadmins decided to formalize their collaboration. Brian Behlendorf, Roy Fielding, Rob Hartill, David Robinson, Cliff Skolnick, Randy Terbush, Robert Thau, and Andrew Wilson formed the Apache Group, coordinating via a private mailing list hosted by HotWired.

Using NCSA HTTPd 1.3 as their base, they merged all the accumulated patches, tested the result, and released Apache 0.6.2 in April 1995. The name's origin became the subject of cheerful mythology: the official story involves the Apache Native American people, but the beloved alternative etymology—'a patchy server,' because it was built from patches—persisted on the project's own FAQ from 1996 to 2001.

Apache's rise was meteoric. By December 1995, version 1.0 was released. Within a year, it had surpassed NCSA HTTPd as the most popular web server on the internet—a position it would hold for nearly two decades. The Apache Group evolved into the Apache Software Foundation in 1999, which went on to become the institutional home for dozens of other open source projects including Hadoop, Kafka, and Spark.

It's arguably the most successful fork in open source history, not because of drama, but because of its absence. Eight pragmatic engineers saw abandoned software that the world needed, picked it up, and changed the internet.

Apache HTTP Server was the dominant web server for nearly two decades, powering the majority of the internet at its peak. But the fork's most lasting impact may be institutional: the Apache Software Foundation became the model for how open source projects organize at scale, providing governance, legal protection, and infrastructure for over 350 projects.

Roy Fielding, one of the original eight, went on to define REST (Representational State Transfer) in his doctoral dissertation, partly informed by his work on Apache. The fork didn't just build a web server—it helped shape the architecture of the modern web itself.

ImageMagick was (and is) one of the most widely used image processing libraries in the world, a command-line Swiss Army knife for converting, editing, and compositing images. But by 2002, its development model was causing problems. The lead developer, John Cristy, had a vision for ImageMagick that involved constant evolution—new features, new formats, refactored APIs. The problem was that this constant churn broke things. Tens of thousands of users and applications depended on stable APIs and predictable command-line behavior, and every major release risked breaking their workflows.

Bob Friesenhahn, who had been contributing to ImageMagick since 1997, led a faction that wanted to freeze the API and command-line interface, prioritizing stability and reliability over feature velocity. The disagreement was irreconcilable: you can't simultaneously have a stable API and one that's constantly being redesigned. In November 2002, Friesenhahn and the stability-minded developers forked ImageMagick 5.5.2 to create GraphicsMagick.

GraphicsMagick adopted a conservative development philosophy from day one. The project emphasized API and ABI stability, predictable behavior, lower memory usage, and a more cautious approach to adding features. It was implemented in C (while ImageMagick later moved toward C++) and used a more conservative memory management strategy.

The fork produced an interesting long-term dynamic: ImageMagick continued to evolve rapidly, adding support for new formats like WebP and AVIF, while GraphicsMagick remained the choice for environments where stability and predictability mattered most. Bob Friesenhahn maintained GraphicsMagick for over two decades, making it one of the longest single-maintainer stewardship runs in open source history.

GraphicsMagick carved out a stable niche in environments where predictability matters—production image processing pipelines, embedded systems, and applications that can't afford API breakage between releases. Its conservative approach influenced discussions about API stability in other projects.

The fork also highlighted a fundamental tension in software development: innovation vs. stability. Both ImageMagick and GraphicsMagick remain actively used, serving different audiences with different priorities. It's one of the few forks where both parent and child genuinely thrive in their respective niches.

Development began in December 2005 by Ioannis Sannos and members of the former Greek Mambo community. The first release, "2006.0 Zeus," launched in June 2006. Unlike Joomla, which took the bulk of the Mambo community with it, Elxis carved out a quieter, more focused path -- emphasizing multilingual capabilities (translated into 40+ languages), enhanced security, and a clean architecture.

Elxis went through its own rebranding journey with version-year naming (2006.0, 2008.1, etc.) and eventually settled into a more conventional versioning scheme. A major rewrite came with version 4.0, which moved to a modern MVC architecture. The CMS earned a niche following, particularly in Europe and among users who needed strong multilingual support out of the box.

The last stable release was version 4.6 in August 2017. While the project website remains online and forums show sporadic activity, active development appears to have stalled. It's the CMS equivalent of a small-town diner that somehow stays open despite never seeming to have any customers.

Minor but persistent. Elxis found a genuine niche in multilingual CMS needs and proved that even small forks can sustain themselves for over a decade.

By 2008, Mambo was already a shadow of its former self -- Joomla had taken the lion's share of developers and users three years earlier. But the remaining Mambo faithful still had grievances. In April 2008, four core developers -- Chad Auld, Ozgur Cem Sen, Richard Ong, and Al Warren -- decided they'd had enough of the Mambo Foundation's policies and processes, which they felt were actively harming both the code and the community.

They forked Mambo 4.6.3 and named their creation MiaCMS. Development moved fast: MiaCMS 4.6.4 shipped in May 2008, followed by 4.6.5 in June and a service pack in September. Mambo core developer Neil Thompson joined the team in September 2008, lending additional credibility.

But momentum is hard to sustain when you're forking a project that was already losing relevance. By July 2009, the MiaCMS team decided to merge their efforts with Martin Brampton's Aliro project, recognizing that two small teams working on similar problems were weaker apart than together. The merger was pragmatic but effectively marked the end of MiaCMS as an independent project.

Minimal. MiaCMS was a fork of a fork's leftovers. But the merger with Aliro was a rare example of two small open-source projects recognizing strength in numbers.

Martin Brampton wasn't just any Mambo developer -- he led the Mambo development team during a critical period. After the Joomla split and the ongoing decline of Mambo, Brampton concluded that the entire Mambo/Joomla architecture needed fundamental rethinking, not just incremental patches. Around 2008, he launched Aliro with a focus on modern PHP5 practices, proper role-based access control (RBAC), and a flexible object caching system.

Brampton even wrote a book about the project: "PHP 5 CMS Framework Development" (Packt Publishing), which went to a second edition. The book documented his architectural decisions and served as both documentation and manifesto. In July 2009, the MiaCMS team merged into Aliro, bringing additional developers and validation to the project.

Despite its technical ambitions and Brampton's deep CMS expertise, Aliro never achieved the escape velocity needed to build a sustainable community. The CMS market was consolidating around WordPress, Joomla, and Drupal, and there simply wasn't room for another PHP CMS, no matter how well-architected. The code lives on in a git repository as a testament to what might have been.

Negligible in adoption, but intellectually influential. Brampton identified architectural problems (poor access control, no proper caching) that Joomla would struggle with for years afterward.

Joostina emerged from the Russian Joomla community around 2007, driven by developers who wanted a CMS that better served Russian-speaking users. The project maintained backward compatibility with Joomla 1.0 components and modules, making it relatively easy for existing Joomla users in Russia to migrate.

The fork included a WYSIWYG editor, RSS/XML support, and various customizations aimed at the Russian market. Development continued through at least November 2011, when version 1.3.0.5 was released. The project had its own community at joostina.ru and later established a presence on GitHub.

Like many regional CMS forks, Joostina struggled to maintain momentum once the original project (Joomla) improved its own internationalization support. The project appears to have been abandoned by the mid-2010s, with its GitHub repository showing no meaningful recent activity. It remains a curious artifact of the era when localizing software sometimes meant forking the entire project.

Minimal. Served a niche Russian-speaking audience during a period when CMS localization was harder than it needed to be.

In the mid-2000s, web accessibility was a growing concern but most CMS platforms, including Joomla, still shipped with table-based layouts, popup windows, and JavaScript that was hostile to screen readers. The Accessible Joomla project (a8e.org, where "a8e" is a numeronym for "accessible") set out to fix this by modifying Joomla's core files to automatically convert sites to be W3C-compliant.

The modifications included replacing HTML table layouts with CSS-based layouts, converting popup windows and JavaScript to accessible alternatives, and generally ensuring that Joomla-powered sites could meet accessibility standards without requiring webmasters to manually rework their templates. It was a pragmatic solution to a real problem.

However, maintaining a patch set against a moving target like Joomla's core was unsustainable. As Joomla itself gradually improved its accessibility support in later versions, the need for a separate fork diminished. The project faded into obscurity, though its advocacy for web accessibility in the CMS space was ahead of its time.

Small but principled. It highlighted accessibility gaps in Joomla at a time when few people were paying attention, likely influencing Joomla's own accessibility improvements.

Jeebles CMS appeared on SourceForge in April 2006, billing itself as a content management system that combined "a low file size with lots of features" -- essentially promising to be Joomla but leaner and meaner. The developer, known as jacksonpeebles, built it using PHP and JavaScript with a SQL backend.

The project was dual-licensed under GPLv2 and LGPLv2, targeting developers, end users, and system administrators. The latest available download was an "enterprise.zip" file weighing in at 7.6 MB. The project's last update was in July 2014, and it currently records zero weekly downloads.

Jeebles is a textbook example of the "I can do this better" fork that appears regularly in open-source ecosystems. Without a clear differentiator, a compelling community story, or enough developers to sustain momentum, it joined the vast graveyard of abandoned SourceForge projects.

Essentially zero. Jeebles is the CMS equivalent of a message in a bottle that nobody ever found.

Jetstar CMS (also distributed under the name CMS2go) was registered on SourceForge in April 2007 by a developer using the handle 'webtrooper.' It positioned itself as "a full featured content management system, web portal and social networking engine" built on Joomla -- which was actually a somewhat forward-thinking concept for 2007, predating the social-everything era of web development.

The project targeted "Advanced End Users" and ran on PHP/MySQL on both Linux and Windows. Its latest release, "C2g-JetStar_20_Beta-1.zip," clocked in at 20.5 MB. The project even had its own website at jetstarcms.com (now defunct) and had a separate SourceForge files section for CMS2go releases.

Like Jeebles, Jetstar succumbed to the gravitational pull of the main Joomla project and the broader CMS market consolidation. Its last recorded activity was in March 2014, and it now has zero weekly downloads. The social networking angle was prescient but the execution never reached critical mass.

Negligible, though the social-networking-meets-CMS concept was ahead of its time. Joomla itself would later add social features through extensions like JomSocial.

In February 2014, Brazilian developer Thiago de Arruda submitted a patch to Vim adding multi-threading and asynchronous job control. It received no response — no acceptance, no rejection, no feedback. For de Arruda, this was symptomatic of a deeper problem: Vim's development was tightly controlled by its creator Bram Moolenaar, and the codebase had accumulated decades of technical debt that made it resistant to fundamental improvements.

De Arruda announced on the vim_use mailing list that he was forking Vim to "refactor code and implement new features, such as the job control patch." He launched a Bountysource campaign in March 2014 that blew past its $10,000 goal within days, ultimately raising over $33,000. The money was real, but the message was bigger: thousands of developers were hungry for a modernized Vim.

The Neovim project didn't just add features — it gutted decades of platform-specific code, ripped out the custom build system in favor of CMake, replaced the hand-rolled IPC with MessagePack-RPC, and embedded a Lua interpreter (LuaJIT) as a first-class scripting alternative to VimL. These weren't cosmetic changes; they were the architectural decisions Vim couldn't make without breaking backward compatibility.

Thiago led development for about 18 months before stepping down in late 2015. Justin M. Keyes took over as lead maintainer and has since shaped Neovim into a genuine platform — with built-in LSP support, Tree-sitter syntax parsing, and a Lua-first configuration model that spawned an explosion of community plugins. Keyes brought a product-management sensibility to the project, focusing on API stability and developer experience.

Bram Moolenaar's passing in August 2023 marked a poignant moment for both projects. Vim itself entered maintenance mode, and many of its remaining active developers acknowledged that Neovim had become the center of gravity for terminal-based editing innovation. The fork that started with an ignored patch had become the future its parent couldn't build.

Neovim single-handedly revitalized terminal-based text editing. Its Lua API and async architecture spawned an ecosystem of hundreds of high-quality plugins — from LSP configurations to AI integrations — that made terminal editors competitive with full IDEs. The MessagePack-RPC protocol enabled GUI frontends like Neovide and embedded Neovim instances in VS Code and other editors.

Perhaps more significantly, Neovim's success pressured Vim itself to modernize: Vim 8 added async job support and terminal emulation, features clearly inspired by Neovim. After Moolenaar's death, Neovim became the de facto standard for developers who prefer modal editing, with GitHub stars exceeding 80,000.