DHH & Open Source 🔗 **Source:** [DHH & Open Source](https://ma.tt/2025/12/dhh-open-source/) > [!note]+ Document Notes > ```markdown > > --- > tags: [open-source, licensing, wordpress] > author: Matt Mullenweg > source: ma.tt > reference: [https://ma.tt/2025/12/dhh-open-source/] > date created: 2025-12-09 12:00 > > --- > > # 🏷️ Title: DHH & Open Source > <!-- deep-read:sections start --> ## 🧭 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) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - Matt criticizes David Heinemeier Hansson (DHH) and 37signals for calling Fizzy’s “O’Saasy” proprietary license “open source.” - It matters because it confuses users, weakens the open‑source brand, and undermines long‑standing community definitions like the OSI’s. - Stakeholders: 37signals, DHH, open‑source communities, SaaS builders, end‑users. - Risks: term dilution, user lock‑in disguised as freedom, bad precedent for license “greenwashing.” - Bottom line: O’Saasy grants some freedoms but fails core Open Source criteria, so branding it “open source” is misleading. ## 📖 Main Content - Matt opens with a jab about wanting “the confidence of DHH claiming his proprietary license is Open Source,” framing the post as both critique and defense of real open source. - He praises Fizzy as a product but argues its marketing is overshadowed by DHH’s insistence on labeling it open source despite meaningful restrictions. - He notes O’Saasy lets users download, run, modify code, and access bug trackers and history—real benefits—but likens this to authoritarian regimes granting limited rights (e.g., recently allowing women to drive) without genuine freedom. - Core claim: freedoms at the licensor’s whim are not equivalent to rights grounded in a stable, shared definition such as the Open Source Initiative (OSI) definition. - He points out O’Saasy’s non‑compete clause forbidding licensees from offering competing SaaS products based on the software. This, he argues, violates OSI’s rule that licenses must not discriminate against persons or groups. - Matt connects this to propaganda tactics: states like North Korea call themselves “democratic” despite being authoritarian. Similarly, calling O’Saasy “open source” is rhetorically convenient but substantively false. - He frames this as “open‑source greenwashing”: appropriating the language of openness while retaining unilateral power and discriminatory terms. - The post defends the importance of community‑developed definitions (like OSI’s) and warns that ignoring them harms trust and clarity in software ecosystems. ### 🗒️ Notes - Matt’s “new prayer” line sets a satirical tone, highlighting perceived overconfidence in redefining “open source” by fiat. - He explicitly credits 37signals/Basecamp and Fizzy as “great” and “innovative,” separating product quality from licensing criticism. - DHH is portrayed as using rapid, confident rhetoric (“how fast he talks and confident he sounds”) to push a narrative that clashes with established norms. - Matt aligns himself with “Actually Open Source” leaders, emphasizing a shared, historically grounded philosophy and the OSI definition as a common standard. - Analogy 1: authoritarian vs democratic regimes - Proprietary licenses that grant some freedoms are likened to authoritarian states that selectively grant rights while retaining total control. - The central question: who ultimately holds power—users/citizens or the leader/licensor? - He stresses that freedoms that can be revoked or constrained by unilateral business decisions are not equivalent to rights backed by a constitution‑like framework (here, community standards and OSI criteria). - He quotes O’Saasy’s clause banning downstream competition as the key defect: it discriminates against a class of users whose “offense” is building a competing service. - This is mapped to the OSI principle that licenses must not discriminate against people or fields of endeavor; non‑compete SaaS clauses are incompatible with that. - Analogy 2: North Korea’s “Democratic People’s Republic” - Shows how loaded terms like “democracy” or “open source” can be co‑opted, while underlying power structures remain authoritarian. - Matt describes the O’Saasy labeling as “false advertising,” especially disappointing from a company known for opinionated, high‑integrity practices. - Implicitly, he calls for honesty in labeling: if it’s source‑available or business‑source, say so; don’t conflate it with OSI‑compliant open source. ## 📚 References - Open Source Initiative – Open Source Definition: https://opensource.org/osd - 37signals / Basecamp – Fizzy product page and O’Saasy license (when available) - DHH blog / 37signals posts on “open source” business licenses - Background on “source‑available” and “business source” licenses (e.g., Elastic, SSPL, BSL) ## 🗣️ Paraphrase - The author argues that while Fizzy’s O’Saasy license provides meaningful access to code and some practical freedoms, it includes anti‑competitive restrictions that violate the OSI’s non‑discrimination principle. Calling it “open source” therefore misleads users and damages the shared meaning of the term. - Using analogies to authoritarian regimes and propaganda labels, he contends that co‑opting respected language (“open source,” “democratic”) for systems that centralize power is a form of greenwashing and false advertising, especially disappointing from companies that trade on integrity. ## 📰 Newsletter A new post from Matt Mullenweg dives into Fizzy, 37signals’ clever new product—and, more importantly, its controversial “O’Saasy” license. While the code is visible and hackable, Matt argues the license’s anti‑competition clauses mean it simply isn’t open source in the OSI sense. For WordPress builders, this is a timely reminder to read licenses closely and protect the integrity of “open source” as a term. If you’re shipping SaaS on top of WordPress or contributing to GPL‑licensed plugins and themes, take a moment to compare your stack’s licenses against the OSI definition and the GPL. Want to go deeper? - Learn more about the [Open Source Definition](https://opensource.org/osd). - Review the [WordPress GPL primer](https://wordpress.org/about/license/). - Audit one of your project’s dependencies this week and confirm whether it’s truly open source or just source‑available. ## ✅ Action Items #### DevRel - Clarify open‑source vs source‑available in talks, docs, and examples. - Prepare a short workshop or office hours on reading licenses for plugin/theme and SaaS builders. - Add examples and quickstarts that highlight GPL/OSI‑compatible patterns for WordPress integrations. - Publish a blog or video series explaining why license accuracy matters for developers and users. - Survey community understanding of “open source” and adjust educational content accordingly. #### OSPO - Document an internal policy that treats OSI’s definition as the canonical “open source” reference. - Classify internal and third‑party licenses (open source, source‑available, proprietary) and maintain an inventory. - Build or adopt scanning tools to flag non‑OSI‑compliant licenses in critical stacks. - Offer consultation hours for teams designing new licenses or business models. - Create guidance for marketing/legal to prevent “open source” misuse in product messaging. - Develop criteria and processes for funding or contributing upstream only to truly open‑source dependencies. #### Community - Host discussions or meetups on license literacy and ethical product marketing. - Provide maintainers with governance templates that clearly state license type and rationale. - Offer newcomers “first issues” around documentation and license clarity. - Encourage sponsors to ask projects for transparent licensing and governance before funding. - Coordinate with related ecosystems for joint statements on preserving open‑source definitions. #### WordPress - Core: keep GPL as a clear anchor for “freedom,” and highlight license implications in contributor docs. - Core Performance: ensure performance tooling and dependencies remain OSI‑compliant where feasible. - Core AI: define responsible AI and licensing guardrails for models, datasets, and integrations. - **Core Program Team:** surface license or dependency concerns early in release planning. - Mobile: review embedded SDKs and libraries for restrictive or misleading licenses. - Playground: use it to demonstrate license‑safe experiments, dependency audits, and reproducible setups. - Community: include license education in meetup kits and WordCamp content tracks. - Training: add modules on GPL, OSI definition, and common “open source adjacent” licenses. - Marketing: avoid “open source” ambiguity in campaigns; highlight WordPress’s GPL foundation. - Support: maintain KB entries explaining licensing basics for end‑users and implementers. - Design: create visual cues or icons to distinguish GPL/OSI‑compliant resources from others. - Documentation: clarify licensing in DevHub/HelpHub articles for APIs, patterns, and code samples. - Photos: ensure media licensing and attribution guidance is explicit and beginner‑friendly. - TV: encourage sessions on open‑source governance, licensing, and business models. - Polyglots: localize licensing explanations and glossary terms so freedom concepts translate well. - Accessibility: ensure learning resources on licensing are accessible (captions, readable text, etc.). - Meta: keep .org infrastructure backed by licenses aligned with community values. - CLI: clearly document license status of scaffolds and generated boilerplate. - Hosting: help hosts understand GPL distribution responsibilities and user freedoms. - Tide: surface license metadata alongside quality scores where possible. - Openverse: keep license detection, labeling, and education accurate and user‑friendly. - Themes: reinforce license checks in theme reviews and mentoring processes. - Plugins: continue strict review around GPL compatibility and disclosure of additional license terms. #### The WPOCC - Design fellowships and microgrants for maintainers who champion license clarity and governance. - Run documentation sprints focused on licensing and contributor rights. - Pilot funding experiments that reward transparent, OSI‑compatible projects and infrastructures. ### FAIR - Encourage technical independence via transparent metadata on license type and provenance. - Promote funding and governance policies that prevent capture by closed or source‑available dependencies. - Develop reusable governance artifacts (charters, MoUs) that encode license and freedom expectations. ## 🧪 Hypotheses - H1: Mislabeling source‑available software as “open source” measurably reduces developers’ understanding of real open‑source freedoms. - H2: Non‑compete clauses in licenses deter high‑quality third‑party ecosystems from forming around a product. - H3: Communities with strong, shared license definitions (e.g., OSI, GPL) enjoy higher long‑term trust and contribution rates. - H4: Clear, honest labeling of “source‑available” vs “open source” does not significantly harm commercial adoption. ### 📊 Methodology - Survey developers across multiple ecosystems about their understanding of “open source” vs “source‑available,” correlate with exposure to misbranded licenses. - Compare ecosystem metrics (contributors, forks, plugin ecosystems) between projects with OSI‑compliant licenses and those with non‑compete clauses. - Run A/B tests on product pages: “open source” vs “source‑available” wording, measure signups, satisfaction, and support load. - Qualitative interviews with maintainers and companies that changed licenses (open→source‑available or vice versa) to understand impact. ### ❓ Questions - How far can license terms deviate from the OSI definition before the “open source” label becomes meaningless? - What enforcement mechanisms (social, market, legal) are most effective against license greenwashing? - Can standardized labels (“open source,” “source‑available,” “proprietary+source”) be widely adopted? - How should communities respond when respected leaders promote non‑standard definitions? ### 🔮 Future Research - Longitudinal tracking of ecosystems built on business‑source or non‑compete licenses vs GPL/Apache/MIT. - Case studies on user harm or lock‑in resulting from misunderstood license freedoms. - Tools and UX patterns that make license implications more visible in package managers and app stores. - Governance models that balance sustainable revenue with genuine software freedom. ### 💡 Implications - Practice: developers must read and understand licenses rather than relying on marketing claims. - Policy: organizations may need internal standards to restrict use of misbranded or discriminatory licenses. - Security: more transparent licensing can improve supply‑chain trust and reduce surprise restrictions mid‑lifecycle. - Education: curricula for developers and decision‑makers should include license literacy. - Funding: funders and sponsors might prioritize projects with transparent, OSI‑compliant governance. ### 🧠 Learning Styles Assessment - Reading level estimate: roughly high‑school to undergrad level; a tool like Flesch–Kincaid would likely place it around grade 10–12 due to analogies and some legal terms. #### 👀 Visual learners - Present: text‑only explanation and analogies; minimal visual scaffolding. - Improve: add diagrams contrasting “open source,” “source‑available,” and “proprietary,” plus flowcharts of rights vs restrictions. #### 🔊 Aural learners - Present: no built‑in audio. - Improve: short audio reading or podcast‑style discussion summarizing the argument. #### 🗣️ Verbal learners - Present: strong prose, analogies (“authoritarian vs democratic regimes,” “North Korea” example). - Improve: a small glossary of key license terms and OSI principles. #### 🧩 Kinesthetic learners - Present: no interactive exercises. - Improve: step‑by‑step task to check the license of a dependency and classify it. #### 🧠 Logical learners - Present: structured argument, reference to OSI rule 5, causal reasoning about effects of discrimination clauses. - Improve: explicit comparison tables of license features and whether they pass OSI criteria. #### 🧑‍🤝‍🧑 Social learners - Present: topic well‑suited to community debate. - Improve: guided discussion prompts or comment questions about where to draw lines on “open source.” #### 🧘‍♀️ Solitary learners - Present: standalone essay suitable for quiet reflection. - Improve: a short reflection checklist (“What licenses do I use? Do they match my values?”). #### 🌿 Naturalistic learners - Present: no direct environmental analogies. - Improve: analogies to ecosystems and commons (e.g., overgrazing the “open source” commons through term dilution). ### 📊 Accessibility Assessment *(Assuming a typical ma.tt blog layout; adjust if inspecting actual HTML)* #### Screen reader semantics - Present: likely proper headings and basic HTML structure. - Improve: ensure descriptive alt text and language attributes are set correctly. #### Keyboard navigation - Present: standard blog layout should be keyboard‑navigable. - Improve: verify visible focus states and provide skip‑to‑content links. #### Contrast and readability - Present: generally good contrast and readable typography. - Improve: confirm contrast ratios for all text, especially links and metadata; maintain adequate line height. #### Text resizing and reflow - Present: responsive design should support zooming reasonably. - Improve: verify at 200%+ zoom for no clipping and respect for reduced‑motion preferences. #### Media and captions - Present: mostly text; minimal media. - Improve: if any embedded media appears, ensure captions/transcripts and no autoplay. #### Forms and interactions - Present: minimal forms (if any), e.g., comments. - Improve: ensure labels, error messaging, and target sizes meet accessibility best practices. #### Standards reference - Map identified gaps and checks against WCAG 2.2 AA, especially for color contrast, keyboard access, and reflow. ### 🌍 DEIB Assessment #### Cultural breadth - Present: references to North Korea and Middle Eastern countries; assumes some global context. - Improve: be explicit that these are analogies, and avoid oversimplifying diverse regions. #### Inclusive language - Present: generally neutral, but uses strong rhetorical contrasts (“authoritarian,” “fraud”). - Improve: add plain‑language summaries of legal/jargon terms for non‑experts. #### Neurodiversity support - Present: clear headings and short paragraphs help many readers. - Improve: more consistent sub‑headings and summary boxes for skimming. #### Representation - Present: discussion centers on a few well‑known tech leaders. - Improve: include examples from a broader range of communities and projects. #### Psychological safety - Present: firm but not personally abusive; critique is focused on behavior and labeling. - Improve: state explicitly that disagreement is welcome and clarify the goal is shared understanding, not personal attack. ### ✅ Logical Validity #### Strong reasoning - The analogy between selective freedoms in proprietary licenses and in authoritarian regimes is a strong inductive and analogical argument: both grant limited rights while retaining unilateral power. - Citing OSI rule 5 (“must not discriminate”) and comparing it to an explicit non‑compete clause is a clear deductive step: if the clause discriminates, the license is not open source by that standard. #### Fallacies - Potential risk of **slippery slope** or **poisoning the well** when comparing mislabeling to propaganda from authoritarian states; the underlying point stands but could be framed with more neutral parallels. - Fix: focus more on definitional clarity and less on emotionally charged state analogies. #### Tone of voice - Tone is assertive, sarcastic, and moralistic (“false advertising,” “greenwashing,” “Yeah, really democratic.”). - The style is conversational and opinionated, aimed at persuading peers rather than offering a neutral legal analysis. ### 🛡️ DARVO Analysis - Deny: Matt does not deny harm; he highlights it. If anything, he argues others are denying the mismatch between words and reality. - Attack: He criticizes DHH’s rhetoric (speed, confidence) and labels the marketing “false advertising,” but keeps focus on ideas and terms more than personal character. - Reverse victim/offender: He frames users and the open‑source community as potential victims of misleading labeling, not DHH/37signals. There’s no attempt to recast the powerful party as the victim. ## 🎯 Conclusion - The essay argues that Fizzy’s O’Saasy license, while granting notable freedoms, fails core OSI non‑discrimination criteria, so calling it “open source” is inaccurate and harmful. - Next steps for readers: examine licenses you rely on, distinguish open source from source‑available, and encourage honest marketing and governance that align words with real user freedoms. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] Open-source labels require OSI compliance > [!quote] [DHH & Open Source](https://ma.tt/2025/12/dhh-open-source/) by [[Matt Mullenweg]] via [[ma.tt]]. Published 2025-12-09. Accessed . > “This violates rule 5 of the OSI definition of Open Source: ‘The license must not discriminate against any person or group of persons.’” Two lines: context and use. Cite data if relevant. [view highlight](https://ma.tt/2025/12/dhh-open-source/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] Source-available is not necessarily open source > [!quote] [DHH & Open Source](https://ma.tt/2025/12/dhh-open-source/) > “Proprietary licenses may grant things that feel like freedoms… However, as a free person… you have to ask yourself: Am I still free?” Two lines: context and use. [view highlight](https://ma.tt/2025/12/dhh-open-source/#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] Open-source licenses forbid discrimination - Applies when assessing whether a license is OSI-compliant. - Pointer: OSI Open Source Definition, rule 5, and Matt’s discussion of O’Saasy. - Links: [[Open-Source-Definition]] [[Software-Freedom]] #### [Z2] Mislabeling licenses erodes community trust - Applies when products use “open source” for non-OSI licenses. - Pointer: DHH & Open Source essay and similar industry debates. - Links: [[License-Greenwashing]] [[Community-Governance]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Check key project dependencies for non-compete or discriminatory license clauses — context/https://ma.tt/2025/12/dhh-open-source/ #fleeting #inbox - [F2] Draft a short explainer distinguishing open source from source-available for my team — context/https://ma.tt/2025/12/dhh-open-source/ #fleeting #inbox - [F3] Add OSI definition reference to internal engineering guidelines — context/https://ma.tt/2025/12/dhh-open-source/ #fleeting #inbox --- <!-- deep-read:sections end -->