Don't fork the ecosystem  ## Metadata - Author: [[Gordon Brander]] - Full Title: Don't fork the ecosystem - Category: #articles - Document Note: --- tags: [#wordpress, #ecosystem, #opensource, #newsletter, #squishy] - #wordpress - #ecosystem - #opensource Author: Squishy Newsletter Team Source: Squishy Computer Newsletter Reference: https://newsletter.squishy.computer/p/dont-fork-the-ecosystem?__readwiseLocation= date created: {{date:2025-03-01}} {{time:15:45}} --- # Title: Don't Fork the Ecosystem ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - Squishy Computer Newsletter. "Don't Fork the Ecosystem." [Read the article](https://newsletter.squishy.computer/p/dont-fork-the-ecosystem?__readwiseLocation=). ## 📝 Summary: This article, "Don't Fork the Ecosystem," argues against the practice of forking open-source projects in ways that fragment communities and weaken the collective ecosystem. It emphasizes the importance of collaboration, sustainability, and cohesive development practices within the WordPress and broader open-source communities. The piece discusses trends in web development, the risks of unnecessary forks, and the need for community-led innovation over divisive fragmentation. ## 📖 Main Content: The article explores the ramifications of splitting an established ecosystem through forking. It asserts that while innovation is vital, creating fragmented versions of a project can dilute resources, hinder collaborative progress, and confuse users. The discussion covers: - **Ecosystem Integrity:** The author stresses that the strength of an open-source project lies in its unified community and shared vision. Forks can divert resources and create incompatible versions, ultimately weakening the overall project. - **Collaboration vs. Fragmentation:** Emphasizes that collaborative improvement is preferable to creating separate, siloed codebases. The article provides examples of successful community collaborations and contrasts them with instances where forks have led to competitive and isolated development. - **Sustainability and Long-Term Impact:** The narrative highlights that sustainable growth in open source relies on transparency, community engagement, and shared responsibility. It warns that forking for short-term gains can jeopardize long-term viability. - **Industry Trends and Future Outlook:** The report reflects on how modern web development practices are evolving and how maintaining ecosystem unity is key to adapting to technological advancements without unnecessary disruption. ### 🗒️ Notes: - **Ecosystem Integrity:** - Emphasizes unity over fragmentation. - Notes the risk of diluting community resources. - Timestamp [00:30](#) illustrates a key point on collaborative growth. - **Collaboration vs. Fragmentation:** - Highlights successful examples of community-led development. - Cites a discussion at [03:15](#) comparing forking outcomes. - Warns against the confusion caused by parallel, divergent projects. - **Sustainability and Long-Term Impact:** - Argues that sustainability is best achieved through shared responsibility. - Points to [05:45](#) as a call to preserve open-source integrity. - **Industry Trends and Future Outlook:** - Links current trends with future predictions. - References [07:20](#) for insights on evolving web development practices. ## 📖 References: - Squishy Computer Newsletter article: "Don't Fork the Ecosystem." [Read here](https://newsletter.squishy.computer/p/dont-fork-the-ecosystem?__readwiseLocation=). - Additional open-source and WordPress community insights as referenced within the article. ## 🗣️ Paraphrase: 1. **Paragraph One Paraphrase:** - Original: "The practice of forking, while sometimes necessary for innovation, often leads to the fragmentation of a unified community, thereby weakening the collective strength of an open-source ecosystem." - Paraphrase: "Although forking can drive innovation, it frequently results in a split community that undermines the overall power and unity of the open-source project." 2. **Paragraph Two Paraphrase:** - Original: "Rather than creating isolated versions that compete against each other, the true value lies in collaborative development, where every contribution reinforces the entire system and drives sustainable growth." - Paraphrase: "The real benefit comes from working together in a unified manner, as collective contributions bolster the whole system and ensure long-term, sustainable progress, instead of creating competing, isolated versions." ## 📰 Newsletter: Welcome to our latest WordPress update! In our upcoming issue, we spotlight the thought-provoking article "Don't Fork the Ecosystem" by Squishy Computer Newsletter. Discover why maintaining a unified, collaborative open-source community is more vital than ever. Learn about the pitfalls of unnecessary forks that can fragment resources and dilute innovation. We'll cover new trends in web development, key community initiatives, and exciting updates on plugins and themes. Stay informed with actionable insights to help you navigate the evolving WordPress landscape. Dive into the full story [here](https://newsletter.squishy.computer/p/dont-fork-the-ecosystem?__readwiseLocation=) and join the conversation! ## ✅ Action Items: - **Align with Open-Source Advocacy:** - Analyze how the article underscores the value of community unity and sustainable practices, which align with my role as a Developer Advocate at GoDaddy. - **Contributor Engagement:** - Use key points from the article to onboard new contributors and encourage collaborative projects within the WordPress ecosystem. - **Educational Outreach:** - Create a workshop or webinar that explores the benefits of collaborative development versus forking, linking to examples and timestamps from the article. - **Professional Development:** - Leverage insights from the article to further my goal of becoming an OSPO director by emphasizing transparency, inclusivity, and sustainable funding. - **Content Integration:** - Develop a blog post or newsletter feature that highlights the importance of maintaining a unified open-source community, referencing the article’s key arguments and timestamps. ## 🧪 Hypotheses: - The adoption of collaborative development practices will lead to more sustainable growth in the WordPress ecosystem. - Avoiding unnecessary forks can reduce fragmentation and improve overall user satisfaction. - Community-driven projects yield higher quality contributions and faster innovation compared to isolated forks. ### 📊 Methodology: - **Data Sources:** - Analyze contribution metrics from major open-source projects. - Gather user feedback and satisfaction surveys from WordPress community forums. - **Research Design:** - Conduct comparative case studies of projects that have experienced significant forks versus those that remained unified. - Use qualitative interviews with community leaders and developers. - **Analysis Techniques:** - Perform statistical analysis on contribution rates and bug resolution times. - Use thematic analysis on interview transcripts to identify recurring benefits of collaboration. ### ❓ Questions: - How does the fragmentation caused by forks impact overall community engagement? - What are the long-term effects of collaborative versus isolated development on project sustainability? - Can unified development practices lead to measurable improvements in performance and security in WordPress? ### 🔮 Future Research: - Investigate the correlation between community collaboration and innova - Document Tags: [[ecosystem]] [[fork]] [[open source]] - Summary: Software can be rebuilt, because software is a machine. But a software ecosystem is not a machine. It is a living system. - URL: https://newsletter.squishy.computer/p/dont-fork-the-ecosystem [](https://newsletter.squishy.computer/) ### [Squishy Computer](https://newsletter.squishy.computer/) > WE MUST BUILD ON A CLEAR SITE. The city of to-day is dying because it is not constructed geometrically. To build on a clear site is to replace the 'accidental' layout of the ground, the only one that exists today, by a formal layout. Otherwise nothing can save us. > *(Le Corbusier, 1929, "The City of Tomorrow")* > > [Why did the web centralize](https://newsletter.squishy.computer/i/65395829/redecentralizing-the-web)? [Why is it slow](https://www.stubbornella.org/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/)? [Why can’t CPython be parallelized](https://wiki.python.org/moin/GlobalInterpreterLock)? [Why is null both an object and not an object](https://2ality.com/2013/10/typeof-null.html)? [Why is null at all](https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/)? Most of our software has been shaped by chance decisions made in haste by people who could not have predicted how the system would end up being used today. Some chance decisions become structural problems. They constrain the system, make it inefficient, hacky, slow. If we could start over, and rebuild the system, knowing what we know now? We could fix these mistakes, swap out the security model, alter that layout algorithm, make the object threadsafe, avoid the billion dollar mistake. It would be fast, beautiful, elegant. Except… ##### You can’t rebuild an ecosystem You *can* rebuild software. Software is just a machine. [Swapping out modules](https://newsletter.squishy.computer/i/52021619/what-is-modularity) and replacing code is no problem. We do it all the time. The impulse, then, is to use this engineering toolkit to fix the ecosystem. We could scrape away the old system, the old city, with its layers of ugly history and compromised infrastructure, and replace it with clean geometric lines and rational choices. The city will continue, of course, just as before, only better, more efficient. People will come and go, work, sleep, shop, except these people will be happier, healthier, more beautiful. Like in this architectural model we made. See the little plastic people walking around the plaza? [](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb959212b-6efc-459b-bdbd-b824539601e4_805x604.jpeg)“A house is a machine for living in.” [Le Corbusier’s Paris Plan](https://en.wikipedia.org/wiki/Plan_Voisin) (1925) to level a large part of central Paris and replace it with a grid of high-rise apartment blocks. [Somehow this fantasy never quite works out](https://newsletter.squishy.computer/p/soulbinding-like-a-state), in cities or in software ecosystems. Software can be rebuilt, because software is a machine. But a software *ecosystem* is not a machine. It is a living system. When we attempt to rebuild the *ecosystem*, we’re making a category error. We’re confusing the software for the ecological process unfolding around it. [](https://unurth.com/Ersilia-Berlin)Artists: a [collaboration](https://unurth.com/Ersilia-Berlin) between [Delavega](https://franciscodelavega-franciscodelavega.blogspot.com/), [Ephemera](https://sehrephemer.blogspot.com/), [Lascarr](https://lascarr.blogspot.com/). Berlin, Germany. > In Ersilia, to establish the relationships that sustain the city's life, the inhabitants stretch strings from the corners of the houses, white or black or gray or black-and-white according to whether they mark a relationship of blood, of trade, authority, agency. When the strings become so numerous that you can no longer pass among them, the inhabitants leave: the houses are dismantled; only the strings and their supports remain. From a mountainside, camping with their household goods, Ersilia's refugees look at the labyrinth of taut strings and poles that rise in the plain. That is the city of Ersilia still, and they are nothing. > *(Italo Calvino, 1972, Invisible Cities)* > > You can’t rebuild an ecosystem, just like you can’t rebuild the Amazon rainforest. You can only grow with it, or bulldoze it and start over from zero. ##### Forking Like a State And that’s exactly what happens when you try to rebuild an ecosystem. Fixing structural issues means breaking changes. Breaking changes mean forking, and forking has costs: *When you fork an ecosystem, you kill the existing ecosystem's momentum, and start from zero on a new ecosystem.* This doesn’t stop us from trying. Software history is littered with attempts to fix past mistakes in our ecosystems: * **Python3** forked the ecosystem by making breaking changes to fix a number of longstanding mistakes. Strings became unicode by default, print went from being a statement to a function, functions switched from using lists to generators. Good stuff! Yet these longstanding mistakes turned out to be structural, and the fixes difficult to adopt. Keystone frameworks like [Django](https://docs.djangoproject.com/en/1.11/topics/python3/) and [NumPy](https://numpy.org/neps/nep-0014-dropping-python2.7-proposal.html) lagged several years behind in adoption. It took even longer for adoption to propagate through the long tail of the ecosystem. Many developers remained stuck on Python2 due to dependency lock-in. Things remained bifurcated until Python2 was EOL’d in 2020, forcing a migration. The ecosystem finally caught up [12 years after Python3 was released](https://stackoverflow.blog/2019/11/14/why-is-the-migration-to-python-3-taking-so-long/#h2-a4811b5655860). * **JavaScript** forked the ecosystem by introducing a syntax-breaking module system, [ES modules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules) (import/export). ES modules made significant improvements on Node’s grassroots module system, [CommonJS modules](https://en.wikipedia.org/wiki/CommonJS) (require()). Bindings in the new module system became static, making [tree shaking](https://developer.mozilla.org/en-US/docs/Glossary/Tree_shaking) possible. The breaking syntax change was also [used as a wedge to upgrade the language in other ways](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode#strict_mode_for_modules). Nevertheless, it took years for browsers to widely support ES module syntax. Node.js took even longer. Build tooling became necessary for shipping code to the browser. Keystone NPM packages continue to use CommonJS, creating practical difficulties with code re-use. ES Modules are widely supported in browsers today, and Node has patched up [most of the compatibility issues](https://nodejs.org/en/blog/release/v23.0.0#requireesm-is-now-enabled-by-default), but has taken about 10 years, and build tools have become entrenched as a permanent feature of using the language. * **Deno** forked the ecosystem by ditching node\_modules and package.json. Deno aimed to simplify by shedding Node’s increasingly complex legacy baggage. They ditched build tooling and config by supporting TypeScript, ES Modules, [URL-based imports](https://deno.com/blog/http-imports), web standard APIs, and a sandboxed runtime. However, the lack of support for Node’s massive [NPM ecosystem](https://www.npmjs.com/) hindered adoption. Then [Bun](https://bun.sh/) launched with full NPM compatibility, and focused on selling performance. [It rapidly gained traction](https://star-history.com/#nodejs/node&denoland/deno&oven-sh/bun&Timeline). Now Deno finds itself playing catch-up. Deno 2 [introduced full NPM compatibility](https://deno.com/blog/v2.0). It also [launched JSR](https://deno.com/blog/http-imports), a new [open source and decentralizable module registry](https://deno.com/blog/jsr_open_beta#help-us-level-up-the-javascript-ecosystem). This is wonderful, but it forks Deno’s ecosystem yet again, since developers now face a choice between NPM and JSR. I’ve also attempted to fork, and for sillier reasons! * **[Subtext](https://github.com/subconsciousnetwork/subtext)** rationalized Markdown as a simple block-based syntax, side-stepping syntax ambiguities, and making it easier to parse into useful data structures. Then, a few months later, ChatGPT happened, and Markdown was their lingua franca. Rationalizing Markdown became a pointless exercise. LLMs are trained on and will generate Markdown for eternity. It’s immortal. I should have just gone with Markdown. What can we learn from all this? Python, ES Modules, Deno, JSR all feel like justified forks to me. They attempt to move the status quo forward in significant ways. And yet every fork is justified. They all happen for good reasons. This doesn’t change the fact that the costs of forking are high, very high. It seems to take about a decade for an ecosystem to recover from a fork. Even so, a lot of shrapnel remains. When the ecosystem finally pieces itself back together, it seldom looks the way we envisioned. These examples are comparative successes. More often, our schemes to fix ecosystems simply fail. [Forks turn ecosystem tailwinds into headwinds](https://newsletter.squishy.computer/i/145470133/draft-off-of-ecosystem-tailwinds). You find yourself pushing against the ecosystem, trying to halt its natural momentum so you can point it in a new direction. Even if you you succeed in slowing it down, you’ll have to keep pushing to get it going again. [We may rationalize the ecosystem, and kill it in the process](https://newsletter.squishy.computer/p/soulbinding-like-a-state). ##### Living systems layer So, if not fix the ecosystem, then what? Add more layers! * Layer stuff on top * Let things live side-by-side * Allow opt-in Rich Hickey has a nice bit about this: “Don’t be afraid of `foo2()`”. `foo2()`?! Preposterous! But then again… is it? `foo2()` means `foo()` doesn’t have to break. They can live side-by-side. You can opt-in. We have to resist the urge to remove the legacy `foo()`. Carrying forward old baggage offends our sense of aesthetics, but hey, that’s how evolved systems work. [Chickens still carry around the gene for dinosaur teeth](https://www.npr.org/2006/02/23/5230538/study-of-chicken-teeth-sheds-light-on-evolution). This is because living systems have to be viable at every evolutionary stage. They can never pause, reset, or make breaking changes. [The path of evolution is always through the adjacent possible](https://newsletter.squishy.computer/p/evolution-adjacent-possible). [](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fd92d5e08-48cd-4092-9b67-7be84c84a8cf_591x452.png) Maintaining viability is another reason that systems tend to evolve into [pace layers](https://newsletter.squishy.computer/i/53901934/layering-allows-evolution-to-proceed-at-multiple-speeds). Newer layers can be stacked on top of older ones without breaking them. Promises on top of callbacks, async/await on top of promises. Older, slow-moving code can remain in its layer, unbothered. Lizard brain, limbic system, neocortex. Layer on layer. For a long time I worked on browsers—Firefox and Chrome—and people who work on these kinds of things have a saying: **[Don’t Break The Web](https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Web_standards/The_web_standards_model#web_standards_key_principles:~:text=They-,don%27t%20break%20the%20web,-.)**. Don’t Break The Web is the reason we have `<marquee>` and [quirks mode](https://en.wikipedia.org/wiki/Quirks_mode). It is also why you can visit [spacejam.com/1996](https://www.spacejam.com/1996/), and it still works today. [](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F217f4122-a254-4931-a49b-564136ffcdd8_600x554.jpeg)Earthball. Don’t let it fall! [New Games](http://www.fogbanking.com/the-new-games-movement/). We’ve been playing Don’t Break The Web for 30 years. We based it on another game called Don’t Break The Internet, which has been going on even longer. Don’t Break is an [infinite game](https://newsletter.squishy.computer/p/open-ended-tools-for-infinite-games). We win by keeping the game going, and we’re still going. [Let's build more things like that](https://newsletter.squishy.computer/p/weblike-things). ##### Don’t fork the ecosystem An ecosystem is the most valuable thing in the world. If you have an ecosystem, you have [tailwinds behind everything you do](https://newsletter.squishy.computer/i/145470133/draft-off-of-ecosystem-tailwinds). That’s because ecosystems are nonlinear systems. They refuse to fall into equilibrium. [Living systems want to spiral upwards](https://newsletter.squishy.computer/p/coevolution-creates-living-complexity). > Life improves the closed system's capacity to sustain life. Life—all life—is in the service of life. Necessary nutrients are made available to life by life in greater and greater richness as the diversity of life increases. > *(Frank Herbert, Dune)* > > Ecosystems are rare. They don’t emerge very often. Our ecosystem, the one on this planet—*life*—arose just once, [as far as we know](https://en.wikipedia.org/wiki/Last_universal_common_ancestor). > Evolution is no linear family tree, but change in the single multidimensional being that has grown to cover the entire surface of Earth. *(Lynn Margulis)* > > So, when a living ecosystem does emerge, we have to cherish it, foster it, despite shortcomings, inelegance, ugliness. All living systems are ugly and a little bit eldritch… [squishy](https://newsletter.squishy.computer/p/subconscious-is-squishy-computer). That’s how it is. ###### Subscribe to Squishy Computer Launched 4 years ago Learning to build living software By subscribing, I agree to Substack's [Terms of Use](https://substack.com/tos), and acknowledge its [Information Collection Notice](https://substack.com/ccpa#personal-data-collected) and [Privacy Policy](https://substack.com/privacy)., Don't fork the ecosystem, Gordon Brander, 01jmadsrkgx47znszzegazcfs2.