Death of a Software Ecosystem: A Developer Relations (DevRel) Perspective  🔗 **Source:** [Death of a Software Ecosystem: A Developer Relations (DevRel) Perspective](https://doi.org/10.1145/3422392.3422445) > [!note]+ Document Notes > tags: [developer-relations, software-ecosystems, ecosystem-health, windows-phone, stack-overflow, open-source-sustainability] > author: [Daniel Massanori, Bruno B. P. Cafeo, Igor Wiese, Awdren Fontão] > source: SBES '20 / ACM > reference: https://doi.org/10.1145/3422392.3422445 > date created: 2026-08-04 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Death of a Software Ecosystem: a Developer Relations (DevRel) perspective > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [📚 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) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor Appendix](#-refactor-appendix--death-of-a-software-ecosystem-a-developer-relations-devrel-perspective) - [🧰 Template Library](#-template-library) ### 🔗 References - [DOI record](https://doi.org/10.1145/3422392.3422445) - [Open author-hosted PDF](https://igorwiese.igor.pro.br/images/papers/nier-massanori.pdf) - [Replication package](https://zenodo.org/record/3978763) ## 📝 Summary - **What happened:** The authors examine Stack Overflow activity around Windows Phone before, during, and after Microsoft discontinued the platform. They treat ecosystem “death” as a shift from a dynamic network to one whose essential activity has stopped. - **Why it matters:** Developer relations often measures attraction and engagement while a platform grows. This paper asks what teams should measure as an ecosystem contracts and what support developers need while migrating code, tools, and knowledge. - **Evidence:** The study reports 46,030 Windows Phone Stack Overflow questions from January 2008 through December 2019. It analyzes views, answers, comments, favorites, scores, answered-to-unanswered ratios, and NMF-derived topics. - **Stakeholders:** Platform owners, DevRel and developer-experience teams, maintainers, third-party developers, support communities, and users of dependent applications. - **Key findings:** Answer, favorite, and score quantities fell by more than 85% in the year before the official discontinuation. Post-discontinuation topics centered on migration, broken tools, missing libraries and services, and support for old projects. The authors offer these as possible “vital signs,” not established predictors. - **Risks and tradeoffs:** Stack Overflow captures only one public support channel; the work studies one mobile ecosystem; descriptive decline does not establish causation; and the ecological analogy can obscure business, governance, and product decisions. - **Bottom line:** DevRel should track ecosystem resilience, contributor exit, migration friction, and support obligations—not only acquisition and engagement—but this exploratory case needs replication before its metrics become forecasting rules. ## 📖 Main Content The paper frames a software ecosystem as interactions among developers around a shared platform. DevRel sits between those developers and the platform’s product, engineering, and design teams. From that position, DevRel can observe both platform decisions and developer behavior. The research asks two questions. RQ1 measures activity before, during, and after discontinuation using views, answers, comments, favorites, and scores. RQ2 uses non-negative matrix factorization (NMF) to identify the technical topics occupying developers during the platform’s final years. The quantitative results show sharp contraction. The table reports 1,038 posts in 2015, 323 in 2016, 33 in 2017, five in 2018, and one in 2019 for the measured subset. Answer, comment, favorite, and score quantities drop before the official announcement. A separate answered-to-unanswered ratio is erratic for Windows Phone, with an R² near zero, unlike the more stable Android and iOS comparisons. The topic analysis adds meaning to the decline. In 2017, questions involve Cordova and PhoneGap failures, Windows Phone-to-Android conversion, and tools such as Xamarin.Forms, Ionic, and PushSharp. In 2018, developers ask about code migration, UWP, unavailable DLLs, Bing Maps, WCF, and changed APIs. By 2019, only 45 questions remain in the topic set, focused on broken emulators, deployment, and older projects in Visual Studio. The practical contribution is a list of exploratory signals and research questions: which developers leave first, how long a platform owner should maintain support, how code and expertise move to successor or competing ecosystems, and whether the death of one platform damages trust in the owner’s other platforms. ### 🗒️ Notes - “Death” is operationalized as definitive interruption or static activity, but the paper doesn’t provide a validated threshold separating low activity from death. - The 46,030 figure is described inconsistently as questions in some passages and documents including questions, answers, and comments in the abstract. Treat the dataset unit as needing confirmation from the replication package. - RQ1 uses normalized yearly views, count summaries, an answered/unanswered ratio, and linear regression. An R² of 0.008 for Windows Phone means that reported line explains almost none of the variance. - RQ2 applies TF-IDF and NMF, then uses an author conciliation meeting to name categories. That combination mixes computational extraction with human interpretation. - The strongest empirical signal is that several engagement counts fall before the 2017 announcement. The paper calls them possible indicators; it doesn’t test forecast accuracy. - Migration questions show residual value after official discontinuation. “Dead” ecosystems can retain users, applications, documentation needs, and maintenance burdens. - Support duration is both a technical and reputational decision. Ending tools and samples too early shifts costs to developers who trusted the platform. - The ecological vocabulary is generative for questions about boundaries, resource reuse, and migration, but it remains an analogy rather than a tested causal theory. ## 📚 References - Massanori, Daniel; Cafeo, Bruno B. P.; Wiese, Igor; Fontão, Awdren. “Death of a Software Ecosystem: a Developer Relations (DevRel) perspective.” SBES ’20, pp. 399–404. [DOI](https://doi.org/10.1145/3422392.3422445). - [Open author-hosted paper](https://igorwiese.igor.pro.br/images/papers/nier-massanori.pdf). - [Study data and code on Zenodo](https://zenodo.org/record/3978763), linked by the paper. - Manikas, Konstantinos. “Revisiting software ecosystems research: A longitudinal literature study.” *Journal of Systems and Software* 117 (2016), cited for the field definition. - Manikas, Konstantinos, and Klaus Marius Hansen. “Reviewing the Health of Software Ecosystems — A Conceptual Framework Proposal” (2013), cited for ecosystem health. - Wareham, Jonathan; Fox, Paul B.; Cano Giner, Josep Lluís. “Technology Ecosystem Governance” (2014), cited for governance and sustainability. ## 🗣️ Paraphrase Developer relations helps a platform attract developers, keep them active, and support their progress. Yet even well-funded ecosystems can close. The authors argue that DevRel needs a way to recognize collapse and manage what remains afterward. They choose Windows Phone because it had substantial developer investment and far more Stack Overflow activity than Firefox OS or Symbian. Microsoft’s 2017 discontinuation creates a boundary for comparing activity before and after the announcement. The researchers collect Windows Phone questions and associated interactions, measure engagement counts, compare answered and unanswered questions with Android and iOS, and extract topics from the final years. The observed activity falls sharply, becomes less predictable, and concentrates on narrow technical problems. Developers don’t simply disappear when a platform closes. They try to reuse code, move applications to UWP or Android, and work around libraries, services, and tools that no longer support the platform. Those actions reveal both stranded investment and migration paths. The paper proposes that falling answer, favorite, and score counts may warn of trouble before an official closure. It also asks platform owners how long they owe support to the remaining community and how a shutdown affects trust in related products. ## 📰 Newsletter ### A platform can stop shipping before its ecosystem stops needing help This SBES paper looks at Windows Phone’s long goodbye through 46,030 Stack Overflow records. The useful DevRel lesson isn’t “watch one dashboard and predict death.” It’s that a platform sunset leaves developers carrying code, tooling, and trust into the next ecosystem. For WordPress, that points toward better deprecation data, migration guides, maintained samples, and explicit support windows. Read the [paper](https://igorwiese.igor.pro.br/images/papers/nier-massanori.pdf) and inspect the [replication package](https://zenodo.org/record/3978763) before turning its exploratory indicators into policy. ## ✅ Action Items #### DevRel - Track entry, sustained contribution, expert response capacity, exit, and migration friction as separate stages. - Publish sunset playbooks with support windows, successor paths, sample migrations, and ownership. - Pair repository metrics with interviews so quiet channels and private support aren’t mistaken for absence. #### OSPO - Add ecosystem-dependency, maintainer concentration, and upstream-exit risks to portfolio reviews. - Require migration, security, licensing, and archive plans before ending support for shared components. - Fund maintenance and knowledge transfer for projects carrying users through a sunset. #### Community - Identify unanswered-question clusters and recruit knowledgeable maintainers before expertise drains away. - Record exit interviews and migration stories without framing contributors as failed or disloyal. - Keep searchable support archives available after active development ends. #### WordPress - **Core:** define health and sunset indicators for APIs, features, and bundled components. - **Core Performance:** distinguish falling use from measurement gaps in performance telemetry. - **Core AI:** publish exit criteria and data portability plans for experimental AI services. - **Core Program Team:** add cross-team migration ownership and support windows to release planning. - **Mobile:** measure unresolved support demand when app features or platforms retire. - **Playground:** preserve reproducible environments for testing deprecated behaviors and migrations. - **Community:** equip meetups and WordCamps to collect contributor-exit and migration feedback. - **Training:** create lessons for deprecation, migration, and long-term maintenance decisions. - **Marketing:** avoid declaring success or decline from activity counts without context. - **Support:** monitor unanswered-topic clusters, expert attrition, and delayed resolutions. - **Design:** research how people experience deprecation notices and forced migration paths. - **Documentation:** maintain versioned migration guides, replacement tables, and end-of-support dates. - **Photos:** publish archive and export guarantees if workflows or taxonomies change. - **TV:** preserve captions, metadata, and durable links when platforms or formats change. - **Polyglots:** translate high-impact sunset notices and migration guides before deadlines. - **Accessibility:** test replacement paths so deprecation doesn’t strand users of assistive technology. - **Meta:** expose longitudinal contributor and support metrics with clear definitions and privacy limits. - **CLI:** provide diagnostics and migration commands for deprecated APIs and scaffolds. - **Hosting:** coordinate end-of-support dates and migration checks across hosting environments. - **Tide:** document what happens to historical scores when scanning rules or services retire. - **Openverse:** plan continuity for ingestion partners, APIs, and rights metadata. - **Themes:** give authors tested paths from retired theme features and abandoned themes. - **Plugins:** surface abandonment, ownership transfer, compatibility, and successor guidance. #### The WPOCC - Fund maintainers who preserve migration paths and essential support during project transitions. - Use sunset clauses, public milestones, and handoff requirements in grants. ### FAIR - Treat exportability, signatures, local metadata, and operator independence as ecosystem-survival controls. - Add transparent sunset and anti-capture terms to governance agreements. ## 🧪 Hypotheses - H1: A sustained decline in answer, favorite, and score counts predicts platform discontinuation better than raw question volume alone. - H2: Expert-answerer attrition precedes broad contributor attrition in a contracting software ecosystem. - H3: Published migration samples reduce unresolved questions after a platform sunset. - H4: Abrupt support withdrawal lowers developer trust in the owner’s successor platforms. - H5: Cross-platform frameworks reduce code-loss costs but increase exposure to secondary support withdrawal. ### 📊 Methodology - **For H1:** Build a multi-platform longitudinal panel; define discontinuation events in advance; compare rolling indicators with baselines; report precision, recall, calibration, and false alarms. - **For H2:** Construct contributor cohorts by expertise and response history; use survival analysis to compare exit timing while controlling for platform-wide activity. - **For H3:** Compare migration outcomes across deprecated APIs or platforms with and without official samples; measure unresolved issues, completion time, and developer-reported effort. - **For H4:** Survey developers before and after sunsets, then compare adoption of related platforms against matched organizations without a recent shutdown. - **For H5:** Trace dependencies and support changes across native and cross-platform toolchains; combine repository events with developer interviews. ### ❓ Questions - What observable threshold separates a small but living ecosystem from a dead one? - Which metric reflects missing experts rather than lower user demand? - How much of the decline began before Microsoft’s public announcement, and what other product decisions explain it? - Do migration guides move developers toward an owner’s successor platform or merely lower the cost of leaving? - What support obligation remains when security, accessibility, or public-interest applications depend on a retired platform? - How should open-source ecosystems define death when forks and local deployments continue? ### 🔮 Future Research - Replicate the study across proprietary, open-source, mobile, package, and cloud ecosystems. - Validate the dataset unit and rerun the published code with documented collection queries. - Add GitHub, package downloads, forums, issue trackers, app stores, social channels, and surveys. - Model platform announcements, release cadence, layoffs, tooling changes, and competitor growth as separate events. - Study maintainers, answerers, application developers, and end users as distinct populations. - Test whether migration support protects trust and reduces economic loss. ### 💡 Implications - **Practice:** DevRel dashboards need leading, lagging, and migration indicators, backed by qualitative research. - **Policy:** Platform owners should publish end-of-support dates, data export paths, security commitments, and successor guidance. - **Security:** Unsupported tooling and libraries can persist after community activity falls; sunset plans need vulnerability handling. - **Education:** Training should cover migration, archival research, and maintenance of legacy systems. - **Funding:** Transition funding can preserve essential support and documentation while usage contracts. - **WordPress:** Contributor counts alone can’t establish ecosystem health; support response, maintainer concentration, dependency continuity, and migration capacity matter too. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Approximately college level, based on sentence density, specialized vocabulary, and the paper’s academic structure; a formal Flesch score wasn’t calculated from the PDF extraction. #### 👀 Visual learners - Present: violin plots, a time-series chart, and metric/topic tables. - Improve: add an ecosystem lifecycle diagram, annotated axes, and a migration-flow map. #### 🔊 Aural learners - Present: Not applicable; the paper has no audio version in the captured source. - Improve: record a short explanation of the two research questions and findings. #### 🗣️ Verbal learners - Present: definitions, named research questions, and an ecological analogy. - Improve: add a glossary for SECO, NMF, TF-IDF, UWP, and validity terms. #### 🧩 Kinesthetic learners - Present: a replication package is linked. - Improve: provide commands, environment versions, expected outputs, and a small sample dataset. #### 🧠 Logical learners - Present: questions, metrics, procedures, tables, and explicit threats to validity. - Improve: diagram the inference chain from observations to proposed warning indicators. #### 🧑‍🤝‍🧑 Social learners - Present: author conciliation meetings inform topic labels. - Improve: add discussion prompts and an independent coding exercise. #### 🧘 Solitary learners - Present: the short paper and replication materials support self-paced review. - Improve: add a results checklist and self-test questions. #### 🌿 Naturalistic learners - Present: ecological concepts organize the analysis. - Improve: state exactly where the natural-ecosystem analogy holds and where it breaks. ### 📊 Accessibility Assessment #### Screen reader semantics - The PDF has visible headings and tables, but extraction order and table structure are unreliable. Provide tagged headings and table headers under WCAG 1.3.1 and 2.4.6. #### Keyboard navigation - DOI and PDF access depend on the hosting interface. Verify keyboard access and visible focus under WCAG 2.1.1 and 2.4.7. #### Contrast and readability - The paper uses dense two-column text and small labels. Check contrast and spacing under WCAG 1.4.3 and 1.4.12. #### Text resizing and reflow - Fixed-page PDF layout can require horizontal or repeated zoom. Offer a reflowable HTML version under WCAG 1.4.4 and 1.4.10. #### Media and captions - Not applicable; the source contains no time-based media. Figures still need text alternatives under WCAG 1.1.1. #### Forms and interactions - Not applicable to the paper body; any DOI or repository controls should have accessible names and error feedback under WCAG 4.1.2 and 3.3.1. #### Standards reference - Primary mapping: WCAG 2.2 AA, especially 1.1.1, 1.3.1, 1.4.3, 1.4.4, 1.4.10, 1.4.12, 2.1.1, 2.4.6, 2.4.7, and 4.1.2. ### 🌍 DEIB Assessment #### Cultural breadth - Present: Brazilian authors and a globally used developer platform broaden the setting beyond North American industry writing. - Improve: compare regions, languages, device economics, and local support channels before generalizing. #### Inclusive language - Present: the paper discusses developers collectively and avoids identity-based stereotypes. - Improve: replace death/body metaphors where they may distract, define jargon, and use cleaner plain language. #### Neurodiversity support - Present: numbered research questions and insight lists create predictable structure. - Improve: shorten sentences, reduce dense columns, add summaries, and label inference versus result. #### Representation - Present: author affiliations and developer roles are named, but participant demographics aren’t measured. - Improve: include who could access Windows Phone development and whose behavior Stack Overflow misses. #### Psychological safety - Present: the paper treats migration as a system response rather than blaming individual developers. - Improve: discuss the human cost of stranded work and avoid implying that departing contributors caused the ecosystem’s death. ### ✅ Logical Validity #### Strong reasoning - The authors state research questions and map each to metrics and procedures, making the exploratory design inspectable. - They separate possible pointers from cause-and-effect in the Android/iOS discussion. - They list generalization, researcher-expectation, and algorithm-choice threats rather than presenting the case as settled. #### Fallacies - **False analogy risk, throughout the ecological framing:** A software platform and a natural ecosystem share network properties, but governance decisions, ownership, and intentional migration differ. Fix: define mapped constructs and test predictions created by the analogy. - **Hasty generalization risk, conclusion:** One Windows Phone case can generate hypotheses but can’t establish general indicators of ecosystem death. Fix: validate across multiple ecosystems with preregistered thresholds. - **Post hoc/causal ambiguity, activity decline around 2017:** Timing near discontinuation doesn’t show whether the announcement, earlier product choices, competitors, or falling demand caused the decline. Fix: use event studies, controls, and qualitative evidence. - **Metric substitution risk, Stack Overflow activity:** Public Q&A activity isn’t equivalent to total developer activity or ecosystem viability. Fix: triangulate repositories, stores, private support, surveys, and dependency data. #### Tone of voice - Exploratory, academic, and metaphor-driven. Phrases such as “vital signals,” “post-mortem,” and “energy transfer” invite new questions but sometimes run ahead of measured constructs. ### 🛡️ DARVO Analysis - **Deny:** Not applicable; the paper doesn’t deny a reported harm or allegation. - **Attack:** Not applicable; it doesn’t attack accusers or undermine a critic’s credibility. - **Reverse victim/offender:** Not applicable; it doesn’t recast an accused party as a victim. - The closest rhetorical concern is diffusion of responsibility: saying Windows Phone died “also because the developers did not support the platform” risks shifting attention from platform-owner decisions. That is causal framing, not a complete DARVO pattern. ## 🎯 Conclusion The paper opens a useful DevRel research question: what should a platform owner observe and do when an ecosystem contracts? Its Windows Phone data suggests that response, favorite, and score counts may weaken before official discontinuation, while remaining developers concentrate on migration and broken tooling. Treat those results as hypothesis-generating. The next practical step is to reproduce the analysis, validate the dataset, and compare several ecosystems before defining a health or sunset scorecard for WordPress or other open-source projects. ## 🔄 Refactor Appendix — Death of a Software Ecosystem: a Developer Relations (DevRel) perspective ### 📚 Literature Atoms (H3) ### [H1] DevRel matures participation around a platform > [!quote] ID:rw_01kz7w23m8sdpacfyb5g78ygxc > The Developer Relations (DevRel) is a strategy to attract, engage and mature developers in contributing to a platform. **Context & use**: - Abstract, page 1. - DevRel is framed as an ecosystem function, not only a communications role. **Tags**: #xref **Highlight**: [view highlight](https://read.readwise.io/read/01kz7w23m8sdpacfyb5g78ygxc) <!-- atomicity: 1 idea ✓ --> ### [H2] Engagement counts may warn before discontinuation > [!quote] ID:rw_01kz7w22pf0pmbqf7w14ppta6a > the quantity of Answer, Favorite and Score may be used a year earlier as possible indicators of "vital signs" of the SECO. **Context & use**: - Introduction and RQ1 conclusion, pages 2 and 5. - This is a proposed warning signal, not a validated forecasting rule. **Tags**: #xref #articleseed **Highlight**: [view highlight](https://read.readwise.io/read/01kz7w22pf0pmbqf7w14ppta6a) <!-- atomicity: 1 idea ✓ --> ### [H3] One shutdown can weaken adjacent-platform trust > [!quote] ID:rw_01kz7w24gvrkntj818q54pmgcz > The death of one SECO can influence disbelief on other platforms in the same ecosystem organization. **Context & use**: - RQ2 insights, page 5. - A platform sunset may create reputational spillover beyond the retired product. **Tags**: #xref #articleseed **Highlight**: [view highlight](https://read.readwise.io/read/01kz7w24gvrkntj818q54pmgcz) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Ecosystem resilience includes an exit path **Claim**: A platform’s developer experience includes the quality of its migration path when support ends. **Evidence pointer**: [[#H2]] **Scope & conditions**: Applies when developers have code, users, or dependencies tied to a platform; it doesn’t require indefinite support. **Links**: - [[Developer experience]] — because extends the lifecycle beyond adoption - [[Software ecosystem health]] — because contrasts growth metrics with contraction readiness - [[WordPress deprecation policy]] — because applies-in platform governance <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Compare the paper’s indicators with WordPress support-forum response trends — https://doi.org/10.1145/3422392.3422445 #fleeting #inbox - [F2] Inspect the Zenodo package for dataset-unit and query definitions — https://zenodo.org/record/3978763 #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Reproduce the published Windows Phone metrics — DevRel ecosystem research #things - [ ] Draft a WordPress sunset-support checklist — contributor continuity #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Death of a Software Ecosystem A Developer Relations (DevRel) Perspective.md|Death of a Software Ecosystem: A Developer Relations (DevRel) Perspective by Daniel Massanori; Bruno B. P. Cafeo; Igor Wiese; Awdren Fontão]] ## Highlights - The Developer Relations (DevRel) is a strategy to attract, engage and mature developers in contributing to a platform. ([View Highlight](https://read.readwise.io/read/01kz7w23m8sdpacfyb5g78ygxc)) - Note: Frames DevRel as a platform-ecosystem function that moves developers from attraction toward mature contribution. - Tags: software-ecosystems, developer-relations - the quantity of Answer, Favorite and Score may be used a year earlier as possible indicators of "vital signs" of the SECO. ([View Highlight](https://read.readwise.io/read/01kz7w22pf0pmbqf7w14ppta6a)) - Note: Treat this as a candidate leading indicator. The paper reports the decline but does not validate predictive accuracy across ecosystems. - Tags: ecosystem-health, developer-metrics - The death of one SECO can influence disbelief on other platforms in the same ecosystem organization. ([View Highlight](https://read.readwise.io/read/01kz7w24gvrkntj818q54pmgcz)) - Note: A sunset can create reputational spillover: migration support and honest communication may shape trust in the owner’s other platforms. - Tags: platform-governance, developer-migration