Raise the Floor  🔗 **Source:** [Raise the Floor](https://www.jonoalderson.com/conjecture/raise-the-floor/) > [!note]+ Document Notes > tags: #open-source #platform-development #technical-seo #upstream-contribution #wordpress #performance-optimization #schema-markup > author: Jono Alderson > source: jonoalderson.com > reference: https://www.jonoalderson.com/conjecture/raise-the-floor/ > date created: 2025-01-11 19:32 > > # 🏷️ Title: Raise the floor > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Evaluate upstream contribution opportunities for current platform constraints — technical debt assessment #platform-development - [H2] Research sponsorship opportunities for accessibility improvements in WordPress — foundation investment #accessibility - [H3] Join public roadmap discussions for key platforms used in current projects — strategic influence #open-source ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Jono Alderson's Blog](https://www.jonoalderson.com/) - [WordPress Accessibility Team](https://make.wordpress.org/accessibility/) - [Chromium Issue Tracker](https://bugs.chromium.org/) - [Schema.org Community Group](https://www.w3.org/community/schemaorg/) ## 📝 Summary - **What happened**: Jono Alderson argues for contributing to upstream platforms (WordPress, browsers, Schema.org) rather than just working around their limitations - **Why it matters**: Most businesses build on platforms they didn't create, inheriting constraints that limit what websites can do, leading to technical debt through workarounds - **Key stakeholders**: SEO professionals, developers, product managers, marketing directors using platforms like WordPress, Shopify, React - **Risks and tradeoffs**: Short-term efficiency of workarounds vs. long-term stability and reduced technical debt through upstream contributions - **Bottom line**: Contributing upstream builds equity instead of debt, providing competitive advantage through improved foundations rather than hoarding fixes ## 📖 Main Content Alderson challenges the common practice of working around platform limitations through plugins, overrides, and custom solutions. Instead, he advocates for "raising the floor" by contributing to the upstream platforms that form the foundation of modern web development. The core argument centers on the difference between **local optimization** (fixing problems in your own implementation) and **upstream contribution** (improving the shared platform for everyone). While local fixes provide immediate solutions, they accumulate as technical debt requiring ongoing maintenance. **Upstream contribution** doesn't always mean coding. It includes: - **Sponsoring expertise**: Funding accessibility or documentation work - **Participating in discussions**: Joining roadmap calls, office hours, and standards debates - **Providing real-world input**: Sharing use cases that inform development priorities The author addresses the common objection that helping everyone benefits competitors, arguing that removing friction doesn't eliminate competitive advantage—it shifts competition to areas of actual differentiation like strategy, content quality, and execution. Platforms mentioned include WordPress (semantic markup), Chromium (browser behaviors), Shopify (technical SEO foundations), and Schema.org (structured data vocabulary). Each offers public participation opportunities that most businesses ignore despite relying heavily on these platforms. ## 🗒️ Notes This is an article format, so timestamped sections are not applicable. Instead, here are the key sections: #### Foundation Dependencies - Key idea: Most websites are built on platforms they didn't create, inheriting constraints and limitations - Evidence: "WordPress. Shopify. React. Stripe. Chromium. Schema.org. Just part of the soup of open source projects and SaaS products, standards and systems that quietly determine what our websites can and cannot do." #### The Negotiation Process - Key idea: Building websites becomes a negotiation between platform capabilities and business needs - Evidence: "Over time, the stack becomes less a product, and more a negotiation between what the platform does and what we need it to do." #### Systems Can Be Influenced - Key idea: Platforms are built by people with public roadmaps and issue trackers, making them influenceable - Evidence: "But these systems are not weather. They are built by people, in public, with roadmaps, issue trackers and office hours." #### Beyond Code Contributions - Key idea: Contributing upstream often means funding expertise, documentation, or participation rather than writing code - Evidence: "Sometimes it looks like sponsoring an accessibility expert so that WordPress produces better semantic markup by default." #### Strategic Participation - Key idea: Showing up to public discussions as someone shipping real experiences changes the conversation - Evidence: "Your participation, as someone shipping high-traffic or high-prestige experiences, changes the tone of that conversation. It moves the issue from theoretical to tangible." #### Local Optimization Default - Key idea: The default approach is to work around constraints rather than address root causes - Evidence: "We find the constraint and work around it. We add the performance plugin. We create the custom block. We write the middleware." #### Competitive Advantage Misconception - Key idea: Competitive advantage based on competitors being slowed by bad defaults isn't sustainable - Evidence: "If your competitive edge depends on your rivals being slowed down by bad defaults, that is not much of an edge. It is simply a tax you have learned to pay more efficiently than they have." #### Technical Debt Accumulation - Key idea: Workarounds create cognitive overhead and increase system fragility - Evidence: "Every workaround is cognitive overhead. Every patch increases fragility. Every customisation is another thing to regression-test and document." #### Improved Baselines Enable Innovation - Key idea: Better platform defaults free up time and resources for actual differentiation - Evidence: "When you are not constantly firefighting performance regressions or patching semantic holes, you can run more experiments." #### Influence as Risk Management - Key idea: Upstream participation provides strategic influence and advance knowledge of platform directions - Evidence: "When you sponsor contributors, participate in roadmap discussions, or help shape standards, you gain influence." #### Equity vs Debt Model - Key idea: Workarounds accumulate technical debt while contributions build long-term platform equity - Evidence: "But five years from now, one organisation is juggling a maze of brittle overrides, dreading the next major release." ## 📚 References - [Raise the floor - Jono Alderson](https://www.jonoalderson.com/conjecture/raise-the-floor/) - [WordPress Make Teams](https://make.wordpress.org/) - [Chromium Development](https://www.chromium.org/developers/) - [Schema.org Community](https://schema.org/) ## 🗣️ Paraphrase - Most websites depend on platforms they didn't build, creating ongoing negotiations between platform capabilities and business needs through workarounds and customizations - Contributing to upstream platforms through funding, participation, and expertise sharing builds long-term equity while local workarounds accumulate technical debt - Real competitive advantage comes from what you build on improved foundations, not from hoarding solutions to shared platform problems ## 📰 Newsletter **Upstream Contribution: Building Better WordPress Foundations** Instead of constantly patching around WordPress limitations, what if we helped improve WordPress itself? Jono Alderson's latest piece challenges the default approach of local optimization (plugins, overrides, custom solutions) in favor of upstream contribution. **Key insight**: Contributing upstream doesn't always mean coding. It can mean sponsoring accessibility work so WordPress outputs better semantic markup by default, funding documentation improvements, or simply joining public roadmap discussions to provide real-world use cases. **Practical benefit**: Organizations that invest in platform improvements spend less time on workarounds and technical debt, freeing resources for actual innovation and differentiation. **WordPress-specific opportunities**: - Join [Make WordPress](https://make.wordpress.org/) teams for Accessibility, Core, or Documentation - Sponsor contributors working on foundational improvements - Participate in feature discussions with real project requirements The long-term result? Better defaults mean faster publishing, cleaner upgrades, and more time for strategic work instead of constant platform firefighting. Resources: [Make WordPress](https://make.wordpress.org/), [WordPress Roadmap](https://wordpress.org/about/roadmap/), [Core Contributor Handbook](https://make.wordpress.org/core/handbook/) ## ✅ Action Items #### DevRel - Developer advocacy: Present upstream contribution as risk management strategy, not charity - Education: Create workshops on participating in open source roadmap discussions - Developer experience: Document current platform workarounds as candidates for upstream fixes - Developer marketing: Share success stories of upstream contributions reducing technical debt - Community management: Facilitate connections between internal teams and platform maintainers #### OSPO - Policy & Governance: Develop upstream contribution policies that align with business objectives - Strategic Alignment: Track ROI of platform contributions vs. workaround maintenance costs - Developer Support: Train teams on participating in public standards and roadmap discussions - Community Engagement: Establish sponsorship budget for critical platform improvements #### Community - Maintainers: Identify WordPress core areas where business needs align with platform roadmap - Contributors: Create pathways for non-engineers to contribute expertise and use cases - Sponsors: Develop transparent criteria for funding upstream accessibility and performance work #### WordPress - Core: Advocate for business use cases in architecture decisions and feature prioritization - Core Performance: Sponsor performance contributors working on default optimization - Accessibility: Fund accessibility expertise to improve default semantic markup - Documentation: Invest in clearer documentation to reduce platform misuse - Meta: Participate in WordPress roadmap discussions with real-world scaling requirements ## 🧪 Hypotheses - Organizations that contribute upstream experience lower technical debt accumulation than those relying solely on workarounds - Platform contributions provide advance knowledge of changes, reducing surprise regressions during updates - Businesses competing on improved foundations rather than hoarded fixes achieve more sustainable competitive advantages - Upstream participation by commercial users accelerates platform development in commercially relevant directions ### 📊 Methodology - Study design to test hypothesis 1: Track technical debt metrics (custom code volume, upgrade difficulty, maintenance overhead) across organizations with different upstream contribution levels - Data sources and analysis for hypothesis 2: Survey teams on prediction accuracy of platform changes correlated with upstream participation level - Experiments to validate hypothesis 3: Measure long-term competitive positioning of companies using upstream vs. local optimization strategies ### ❓ Questions - How do organizations measure ROI on upstream platform contributions vs. local workaround development? - What governance models allow commercial teams to participate in open source roadmaps without conflicts of interest? - How can non-technical stakeholders effectively contribute business requirements to technical platform discussions? ### 🔮 Future Research - Quantitative analysis of technical debt accumulation patterns in platform-dependent organizations - Case studies of successful commercial upstream contributions and their long-term business impact - Framework development for evaluating when upstream contribution is more cost-effective than local optimization ### 💡 Implications - **Practice**: Shift from reactive workaround development to proactive platform participation and sponsorship - **Policy**: Develop internal guidelines for when to contribute upstream vs. implement local solutions - **Security**: Upstream contributions improve security posture by reducing custom code surface area - **Education**: Train product managers and marketers to articulate business requirements in technical platform discussions - **Funding**: Budget allocation should consider upstream contribution as infrastructure investment, not charitable donation ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (sophisticated vocabulary, complex sentence structures, abstract concepts) #### 👀 Visual learners - Present: Metaphors (debt vs equity, foundation vs workarounds) that create mental models - Improve: Diagrams showing platform dependency relationships, technical debt accumulation over time #### 🔊 Aural learners - Present: Article structure supports audio reading with clear section transitions - Improve: Podcast-style discussion of upstream contribution examples and case studies #### 🗣️ Verbal learners - Present: Strong use of analogies (platforms as weather vs. built systems, negotiation metaphor) - Improve: Glossary defining technical terms like "upstream," "semantic markup," "technical debt" #### 🧩 Kinesthetic learners - Present: Concrete examples of participation (join office hours, propose schema properties) - Improve: Step-by-step guides for first upstream contributions, platform participation checklists #### 🧠 Logical learners - Present: Clear cause-effect relationships between workarounds and technical debt - Improve: Decision trees for upstream vs. local optimization, ROI calculation frameworks #### 🧑‍🤝‍🧑 Social learners - Present: Emphasis on community participation and collaborative platform improvement - Improve: Examples of successful collaboration between commercial users and platform maintainers #### 🧘‍♀️ Solitary learners - Present: Strategic framework for individual evaluation of contribution opportunities - Improve: Self-assessment tools for identifying relevant upstream contribution areas #### 🌿 Naturalistic learners - Present: Ecosystem thinking about platform interdependencies - Improve: Lifecycle analysis of platform contributions vs. workaround sustainability ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading hierarchy, descriptive section titles - Improve: Add landmark roles, ensure code examples have appropriate labels #### Keyboard navigation - Present: Standard web navigation, focus management - Improve: Skip links for long-form content, ensure all interactive elements are keyboard accessible #### Contrast and readability - Present: High contrast text, readable typography - Improve: Verify color contrast meets WCAG standards, optimize line spacing #### Text resizing and reflow - Present: Responsive design supports text scaling - Improve: Test reflow at 200% zoom, ensure no horizontal scrolling #### Media and captions - Present: Text-based content, no embedded media requiring captions - Improve: Add alt text for any diagrams or visual elements added #### Forms and interactions - Present: Standard form elements with proper labeling - Improve: Ensure error messages are associated with form fields #### Standards reference - Content structure generally follows WCAG 2.2 AA guidelines for text content ### 🌍 DEIB Assessment #### Cultural breadth - Present: Examples from global platforms (WordPress, Chromium, Schema.org) - Improve: Include examples from different cultural contexts and regional platform preferences #### Inclusive language - Present: Professional, jargon-defined terminology - Improve: Explain technical concepts in plain language, avoid industry-specific idioms #### Neurodiversity support - Present: Well-structured content with clear section breaks - Improve: Add summary boxes for key concepts, use consistent formatting patterns #### Representation - Present: Focus on organizational roles rather than individual characteristics - Improve: Include diverse examples of successful upstream contributors #### Psychological safety - Present: Encouraging tone about participation in open source communities - Improve: Address potential intimidation factors for first-time contributors ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong logical progression from platform dependency → workarounds → technical debt - Inductive strength: Good use of specific examples (WordPress, Chromium) to support general principles - Causal reasoning: Clear causal links between upstream contribution and reduced technical debt - Analogical strength: Effective analogies (debt vs equity, weather vs built systems) #### Fallacies - False dichotomy: Occasionally presents upstream vs. local as binary when hybrid approaches exist - Appeal to consequences: Some arguments focus on outcomes without fully addressing implementation challenges #### Tone of voice - Overall tone: Authoritative and persuasive, with concrete examples supporting abstract strategic concepts ### 🛡️ DARVO Analysis - Deny: No relevant denial patterns present - Attack: No attacks on accusers present - Reverse victim/offender: No victim/offender dynamics present - Emotional cues and rhetoric: Persuasive but not manipulative; uses logical arguments rather than emotional manipulation ## 🎯 Conclusion Alderson makes a compelling case for shifting from reactive platform workarounds to proactive upstream contribution. The key insight is that competitive advantage shouldn't depend on competitors being slowed by bad platform defaults, but rather on what organizations can build when foundations are solid. **Practical next steps** for WordPress-dependent organizations: - Audit current workarounds and identify candidates for upstream fixes - Evaluate sponsorship opportunities for accessibility and performance improvements - Assign team members to participate in relevant Make WordPress team discussions **Broader implications** suggest this approach becomes more critical as AI systems require cleaner, more semantic web content, making platform defaults a matter of discoverability rather than just performance. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Upstream contribution builds equity instead of technical debt > [!quote] [Raise the floor](https://www.jonoalderson.com/conjecture/raise-the-floor/) by [[Jono <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/Raise the Floor|Raise the Floor, jonoalderson.com]] ## Highlights - And when those boundaries get in the way, we adapt. We override templates. We install plugins. We write shims. We create internal conventions to paper over awkward defaults. Over time, the stack becomes less a product, and more a negotiation between what the platform does and what we need it to do. ([View Highlight](https://read.readwise.io/read/01kjqxfx42k0c458s13gbk62v2)) - Tags: 👻 ai highlighted - When you sponsor contributors, participate in roadmap discussions, or help shape standards, you gain influence. You build relationships with maintainers. You understand the direction of travel before it is announced. You can advocate for features that matter to your commercial reality. ([View Highlight](https://read.readwise.io/read/01kjqxfx58xbgvatsq5bgd6e2m)) - Tags: 👻 ai highlighted