'Source available' is not open source (and that's okay) 🔗 **Source:** ['Source available' is not open source (and that's okay)](https://dri.es/source-available-is-not-open-source-and-that-is-okay) > [!note]+ Document Notes > tags: [open source, licensing, sustainability, DHH] > author: Dries Buytaert > source: dri.es > reference: [https://dri.es/source-available-is-not-open-source-and-that-is-okay] > date created: 2025-12-09 00:00 > > # 🏷️ Title: 'Source available' is not open source (and that's okay) > <!-- 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 - What happened. - David Heinemeier Hansson (DHH) released Fizzy under the O’Saasy license and called it “open source.” Critics, including Matt Mullenweg, objected because O’Saasy restricts competing SaaS offers, violating the Open Source Initiative (OSI) definition. - Why it matters. - The conflict exposes confusion over “open source” and highlights a deeper, unresolved problem: economic sustainability and “free riding” in open source ecosystems. - Key stakeholders. - DHH and the Ruby on Rails community, Matt Mullenweg and the WordPress ecosystem, Drupal and its contributors, companies monetizing open source, and open source maintainers broadly. - Risks and tradeoffs. - Diluting the meaning of “open source” risks trust and coordination; overly rigid purism risks ignoring sustainability pressures. New “source-available” licenses may protect maintainers but sacrifice some freedoms. - Bottom line. - “Open source” has a specific, community-defined meaning that must be respected, but the real work ahead is designing sustainable models—possibly including “source-available” licenses—rather than relabeling them as open source. ## 📖 Main Content - Explain the core arguments in plain language. - The article opens with the recent dispute between DHH and Matt Mullenweg. DHH calls Fizzy “open source” despite using the O’Saasy license, which forbids others from running a competing SaaS. Critics point out this conflicts with the OSI definition that requires allowing such uses. When challenged, DHH dismisses the OSI definition as “some shit people made up” and asserts, “Open source is when the source is open.” - Matt responds by insisting that “open source” is a term with a specific, long-established meaning, comparing misuse of the label to North Korea calling itself a democracy. The author agrees: thousands of people have refined the OSI definition over decades; using the label while ignoring its rules exploits community labor and reputation without honoring its governance. - The article stresses that, while the definition debate is important, the more urgent issue is sustainability: companies frequently profit from open source without contributing proportionally to its development and maintenance. This free rider problem affects WordPress (e.g., the WP Engine dispute), Ruby on Rails, and Drupal alike. - DHH can experiment with a new license because Fizzy is early-stage; WordPress, bound by GPL for over 20 years, cannot practically change licenses. That asymmetry helps explain differences in their strategies but not in their shared underlying concern: keeping major open source projects viable. - Add sourced context and define terms. - The article notes that arguing about labels while ignoring sustainability is like “firefighters arguing about hose lengths during a fire.” Definition alignment is necessary for collaboration, but it does not solve funding, staffing, or governance. - The author connects to an earlier “Makers and Takers” post, where he proposed licenses that “encourage software free riding” (broad code availability) but “discourage customer free riding” (allow maintainers to keep some commercial advantage). O’Saasy fits this pattern: code is visible and modifiable, but SaaS rights remain with DHH’s company to support a business model. - The piece argues this setup is “defensible and generous” but must be honestly labeled: it is “source available,” not open source. Clear terminology preserves trust while allowing experimentation in business models. - Note uncertainties or contested claims. - The long-term viability of “source-available” approaches like O’Saasy is uncertain; they may or may not strike a durable balance between openness and revenue. - It remains unresolved how to systematically distinguish between companies that genuinely cannot contribute and those that simply will not, and which interventions (social pressure, incentives, regulation) most effectively change behavior. - The author candidly admits not having a complete solution after two decades of work; the article is framed as a call for better questions and experiments, not a final blueprint. ### 🗒️ Notes - The article opens by situating the author’s 20 years of work on open source sustainability and framing the DHH–Mullenweg conflict as a familiar pattern of tension over definitions and funding. - DHH launches Fizzy, calls it “open source,” and uses the O’Saasy license, which prevents others from offering competing SaaS. Community members note this restriction conflicts with the OSI’s requirements for open source licensing. - When pressed, DHH dismisses the OSI’s authority, calling its definition “some shit people made up” and reducing open source to “when the source is open,” stripping the term of its governance and principles. - Matt Mullenweg publicly pushes back, arguing that you cannot simply ignore the OSI definition and likening misuse of the term to North Korea calling itself a democracy—clumsy rhetoric, but aligned with the need for shared terminology. - The author emphasizes that “open source” is not a vague marketing idea; it is an explicitly defined concept refined by thousands of contributors over decades, and using the term while discarding its constraints exploits that collective work. - The conflict is further contextualized by DHH’s recent appearance on Lex Fridman’s podcast, where he appealed to the ethics of open source while criticizing Matt’s handling of the WP Engine dispute, raising the question of which “spirit” of open source he invokes if the definition is arbitrary. - The article shifts focus from semantics to sustainability: many companies profit substantially from open source projects without sharing the burden of building and maintaining them, which creates systemic strain and resentment. - This free rider dynamic appears in multiple ecosystems: in WordPress (e.g., hosting companies benefiting disproportionately), in Ruby on Rails, and in Drupal, where large companies often do not contribute in proportion to their gains. - DHH, with a new product, can test a novel license like O’Saasy to protect SaaS revenue, whereas Matt, stewarding a long-standing GPL project, is effectively locked into that license and cannot realistically alter WordPress’s terms. - The author criticizes the spectacle of influential leaders debating definitions while the community faces urgent sustainability issues, using the metaphor of firefighters arguing over hose length as a house burns. - The piece reasserts that clear definitions matter because open source collaboration depends on shared understanding of rights and obligations, but insists that the decisive factor for long-term health is sustainable economic and governance models. - The author notes that in Drupal they have tried mechanisms like contribution credits and directing work toward supporting companies, which help somewhat but fail to fully resolve contribution imbalances. - He revisits his “Makers and Takers” proposal for licenses that allow code-level free riding but limit “customer free riding,” positioning O’Saasy as an example of such an experiment in balancing openness and business sustainability. - Fizzy is therefore more accurately labeled “source available”: users can read, run, and modify the code, but DHH’s company retains exclusive SaaS rights to support a viable business—an approach the author calls defensible and generous but explicitly not open source. - The article concludes that the solution to sustainability is not to redefine or co-opt “open source” but to ask sharper questions about corporate behavior and to explore practical mechanisms—social, economic, and regulatory—to ensure fairer participation. - It closes with explicit open questions: how to distinguish companies that cannot vs. will not contribute, and what tools (shame, self-interest, punitive measures, exclusive benefits, regulation) most effectively change behavior. ## 📚 References - Dries Buytaert – “Source available is not open source (and that’s okay)” (https://dri.es/source-available-is-not-open-source-and-that-is-okay) - Open Source Initiative – “The Open Source Definition” (https://opensource.org/osd) - O’Saasy license (canonical description, if/when published by DHH/Basecamp/37signals) - Dries Buytaert – “Makers and Takers” (https://dri.es/makers-and-takers) - Matt Mullenweg’s posts on WP Engine and open source sustainability (on ma.tt) - DHH’s post introducing Fizzy and its licensing (on world.hey.com or related blog) - Lex Fridman Podcast episode featuring DHH discussing open source and WordPress ## 🗣️ Paraphrase - Paragraph A paraphrase. - Calling Fizzy “open source” while using O’Saasy, which limits SaaS competition, conflicts with the OSI definition. Brushing off that definition ignores decades of community work that give “open source” its specific, shared meaning. - Paragraph B paraphrase. - While arguments about the label “open source” are important, the deeper issue is how to keep major projects sustainable when companies profit without contributing. Experiments like O’Saasy are understandable attempts to address that, but they should be honestly labeled as “source available,” not open source. ## 📰 Newsletter Open source is having a definition crisis—and a sustainability one. In a new post, Drupal founder Dries Buytaert unpacks the recent clash between DHH and Matt Mullenweg over what counts as “open source” when a license blocks competing SaaS offerings. The takeaway for WordPress builders: the OSI definition still matters, but so does finding viable funding models. If you rely on WordPress, Drupal, or Rails in your stack, now’s the time to audit how your organization contributes back. Are you a maker or a taker? Consider carving out budget for upstream contributions, sponsoring maintainers, or adopting contribution credits internally. It’s not enough to open the code; we have to keep the maintainers afloat too. ## ✅ Action Items #### DevRel - Developer advocacy: - Prepare a talk comparing “open source” vs “source available” using Fizzy/WordPress/Drupal as case studies, with clear OSI-aligned definitions. - Build demo repos showing licensing scenarios (GPL, MIT, source-available) and their practical implications. - Education: - Develop a workshop on open source licensing basics for engineers and PMs, with exercises categorizing licenses and their SaaS constraints. - Offer office hours to help teams choose appropriate licenses and contribution strategies. - Developer experience: - Add clear LICENSE and CONTRIBUTING guides to SDKs and starter templates; highlight what “true open source” implies. - Provide quickstart examples for contributing back (patch workflows, bug templates). - Developer marketing: - Run a content series on “Sustainable Open Source in Practice,” featuring maintainers from WordPress, Drupal, and Rails. - Track engagement with sustainability-focused content and correlate with contributor signups. - Community management: - Host moderated discussions on licensing and sustainability in forums/Slack, with a strong code of conduct. - Survey developers on free-rider pain points and perceived barriers to contribution. - Internal/external/cross-project: - Align internal goals with upstream roadmaps (WordPress core, Drupal, Rails). - Establish feedback loops to route product learnings back to upstream projects. #### OSPO - Policy & Governance: - Clarify internal policy on when “open source” can be used in product marketing (must meet OSI definition). - Publish decision rights around license selection and public messaging. - License Compliance: - Implement regular license scanning and review of SaaS offerings for compliance and terminology accuracy. - Train product/legal teams on distinguishing open source vs source-available. - Security Management: - Coordinate vulnerability disclosure with upstream projects; ensure embargo and patching processes. - Sign releases and artifacts, and document provenance where possible. - Software Inventory: - Maintain an SBOM for major products; track critical upstream dependencies like WordPress and Drupal. - Set freshness SLOs for dependency updates. - Developer Support: - Offer legal/OSPO consultation hours for teams considering non-standard or source-available licenses. - Provide recommended tooling for license checks and attribution. - Community Engagement: - Fund upstream maintainers or foundations (WordPress, Drupal, Rails) via sponsorships or MoUs. - Negotiate contribution targets in key vendor/operator agreements. - Strategic Alignment: - Add open source sustainability KPIs (e.g., upstream contribution hours, funded maintainers) to executive reporting. - Build a roadmap for deepening involvement in core ecosystem projects. #### Community - Maintainers: - Organize roadmap clinics to align commercial users’ needs with project priorities. - Document governance and release processes to reduce burnout and ambiguity. - Contributors: - Create onboarding paths and “first issue” rotations that explicitly welcome corporate contributors. - Pair new contributors from large companies with experienced maintainers. - Sponsors: - Publish transparent budgets and funding milestones for critical work (security, infra, maintenance). - Issue impact reports tying sponsorships to concrete outcomes. - Ecosystem: - Run cross-project incident drills involving WordPress, Drupal, and Rails operators. - Coordinate security disclosures and sustainability campaigns across ecosystems. #### WordPress - Core: - Prioritize issues that affect large hosting providers and ask for formal contribution commitments in return. - Revisit release criteria with sustainability in mind (e.g., funded maintainers for key components). - Core Performance: - Use performance dashboards to justify targeted funding from large hosts and agencies. - Pilot perf bounties funded by commercial actors. - Core AI: - Define responsible AI policies for any AI-assisted features in core or major plugins. - Publish evaluation sets and guardrails for AI-generated content. - **Core Program Team:** - Establish clear cadences for cross-team planning and retros on sustainability topics. - Track dependency on underfunded maintainers and escalate risks. - Mobile: - Gather telemetry on usage and crashes; advocate for dedicated funding of mobile-specific maintainers. - Improve offline UX with documented performance budgets. - Playground: - Use Playground for reproducible bug reports and educational labs about licensing and contributions. - Build scenarios that show the impact of different licensing models. - Community: - Update meetup and WordCamp kits with content on “makers vs takers” and how companies can contribute. - Offer speaker mentorship on sustainability topics. - Training: - Develop learning paths that include licensing, governance, and how to contribute back as a company. - Pilot lightweight certification for “WordPress Open Source Stewardship.” - Marketing: - Run campaigns that highlight companies contributing significantly to core, not just using WordPress. - Promote success stories where contribution led to better business outcomes. - Support: - Identify knowledge base gaps around licensing, GPL, and SaaS compatibility. - Define escalation paths when commercial misuse of “open source” is spotted. - Design: - Conduct UX audits focused on maintainability (simplifying contributor workflows, admin clarity). - Maintain design tokens and patterns to reduce maintenance load. - Documentation: - Clarify GPL implications and acceptable SaaS patterns in DevHub/HelpHub. - Use examples-first docs for contribution workflows. - Photos: - Encourage contributions of diverse imagery under open licenses. - Maintain clear moderation guidelines and taxonomy hygiene. - TV: - Publish high-quality talks about licensing and sustainability with good captions. - Curate playlists on open source governance and economics. - Polyglots: - Organize translation sprints funded or hosted by commercial users. - Improve glossary alignment across locales for licensing terms. - Accessibility: - Integrate accessibility into performance and sustainability trade-off discussions. - Maintain a heatmap of high-impact accessibility issues. - Meta: - Ensure .org infra reliability and contributor tools get funding and staffing attention. - Publish a public .org roadmap that includes sustainability work. - CLI: - Expand commands that simplify contribution workflows and plugin/theme scaffolding. - Improve docs and smoke tests for CI environments. - Hosting: - Develop cross-host “minimum contribution” checklists (patches, tickets, sponsorship). - Share anonymized telemetry to help upstream prioritize performance and stability. - Tide: - Improve scoring transparency and establish review loops for false positives. - Proactively engage plugin authors on sustainability and security. - Openverse: - Document ingestion pipelines and funding needs for moderation and infra. - Promote Openverse as a model for sustainable commons. - Themes: - Use mentoring to increase reviewer throughput and quality. - Encourage test matrices shared by large agencies. - Plugins: - Improve security liaison processes and provenance checks. - Consider recognition or badges for plugins with strong contribution histories. #### The WPOCC - Programs: - Launch fellowship tracks for maintainers of critical WordPress components. - Offer microgrants and stipends for underfunded but essential maintainers. - Projects: - Run governance clinics to help projects formalize decision-making and funding models. - Organize documentation sprints focused on contribution economics. - Funding experiments: - Test matched grants (e.g., hosts match community donations). - Publish transparent ledgers of maintenance and security funding. ### FAIR - Technical independence: - Promote local metadata for licenses and maintainers, plus signature checks for releases. - Encourage provenance tracking for major WordPress/Drupal/Rails packages. - Policies and covenants: - Define public covenants on funding transparency for large users of open source. - Add sunset clauses and anti-capture provisions to funding and governance agreements. - Productized governance artifacts: - Create reusable charters, operator agreements, and sustainability scorecards for open source projects. - Encourage ecosystems to adopt and adapt these artifacts. ## 🧪 Hypotheses - H1: Projects that clearly distinguish “open source” from “source available” experience higher long-term contributor trust and retention. - H2: Public contribution credit systems (e.g., Drupal’s) significantly increase corporate contributions relative to similar projects without such systems. - H3: Restrictive SaaS clauses (like O’Saasy) improve maintainer revenue but reduce third-party ecosystem growth compared to OSI-compliant licenses. - H4: Social incentives (recognition, reputation) drive more sustained corporate contributions than shame or punitive measures alone. - H5: Clear internal policies on the use of the term “open source” reduce legal and reputational risk for commercial SaaS companies. ### 📊 Methodology - Study designs, data sources, and analyses to test the hypotheses. - For H1: - Compare contributor churn and surveys of trust across a matched set of projects, some of which use strict terminology and educational materials, others more ambiguous. - For H2: - Quasi-experimental before/after analysis of Drupal’s contribution credit system vs similar ecosystems lacking such mechanisms; measure corporate contributions and funded work. - For H3: - Longitudinal comparison of projects using O’Saasy-like licenses with similar OSI-licensed projects; track revenue proxies, number of third-party SaaS providers, and overall adoption. - For H4: - Randomized messaging experiments with corporate partners, varying between recognition-based, shame-based, and punitive-framing requests for contributions; measure response and sustained participation. - For H5: - Survey SaaS companies with and without explicit internal policies on “open source” terminology; correlate with incident rates (public criticism, legal disputes). ### ❓ Questions - How should communities balance strict adherence to OSI definitions with experimentation in business models? - What is the minimum viable contribution expectation for large commercial users of an open source project? - Can “source available” norms coexist peacefully with open source norms, or do they inevitably blur the brand? - Which mechanisms best distinguish between “can’t contribute” and “won’t contribute” organizations? - What governance structures help maintainers negotiate fairly with large corporate users? ### 🔮 Future Research - Comparative case studies of projects that moved from permissive to source-available licenses (or vice versa). - Economic modeling of different sustainability strategies (sponsorships, dual licensing, SaaS restrictions, foundations). - Sociological studies on how language (“open source,” “free,” “source available”) shapes contributor motivation and corporate behavior. - Experiments with new contribution accounting systems (credits, time tracking, value weighting). - Policy analyses on potential regulatory interventions for platform or infrastructure projects heavily reliant on open source. ### 💡 Implications - Practice: - Teams should label licenses precisely and avoid calling source-available software “open source,” while still exploring such models where needed for sustainability. - Policy: - Organizations may need explicit internal guidelines about how they use the term “open source” in marketing and contracts. - Security: - Underfunded maintainers pose systemic risk; sustainable funding models are also security interventions. - Education: - Curriculum for engineers and PMs should include licensing, governance, and sustainability topics alongside coding. - Funding models: - New mechanisms that respect OSI definitions while providing commercial leverage (e.g., support contracts, stewardship programs) require further experimentation. ### 🧠 Learning Styles Assessment - Reading level estimate: - Roughly Flesch-Kincaid Grade 10–12 (complex sentences, domain-specific terms like “sustainability,” “license,” “free riders”). #### 👀 Visual learners - Present: - Mostly text, clear structure but no diagrams. - Improve: - Add diagrams comparing license types, flowcharts of contribution pathways, and ecosystem maps of makers vs takers. #### 🔊 Aural learners - Present: - No audio-native content. - Improve: - Provide a 3–5 minute audio summary or podcast snippet; link to relevant podcast episodes (e.g., DHH on Lex Fridman) for deeper listening. #### 🗣️ Verbal learners - Present: - Strong narrative, clear definitions, pointed analogies (e.g., firefighters, North Korea comparison). - Improve: - Add a short glossary comparing “open source,” “free software,” and “source available.” #### 🧩 Kinesthetic learners - Present: - No interactive tasks. - Improve: - Offer checklists for auditing a product’s license and contribution posture; propose small experiments (e.g., contributing one patch, sponsoring one maintainer). #### 🧠 Logical learners - Present: - Structured argument from definitions to sustainability; cause-and-effect reasoning about free riders. - Improve: - Include decision trees for license selection and tables comparing different sustainability mechanisms. #### 🧑‍🤝‍🧑 Social learners - Present: - References to community conflicts and shared norms; implicitly invites discussion. - Improve: - Add discussion prompts for teams or meetups, plus moderated Q&A sessions. #### 🧘‍♀️ Solitary learners - Present: - Essay format conducive to solo reflection. - Improve: - Include reflection questions about one’s own or one’s company’s behavior toward open source. #### 🌿 Naturalistic learners - Present: - Limited explicit environmental framing. - Improve: - Use ecosystem metaphors for sustainability and link to environmental “commons” and stewardship analogies. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: - The blog likely uses semantic HTML headings and paragraphs. - Improve: - Ensure proper heading hierarchy, language attributes, and meaningful link text. #### Keyboard navigation - Present: - Standard blog navigation likely works with keyboard. - Improve: - Verify skip links, visible focus states, and absence of keyboard traps in any interactive elements. #### Contrast and readability - Present: - Most personal blogs maintain adequate contrast and font sizes. - Improve: - Check contrast ratios against WCAG 2.2 AA; confirm comfortable line-height and whitespace. #### Text resizing and reflow - Present: - Responsive design likely supports basic zooming. - Improve: - Test at 200% zoom and on small screens; ensure no clipping and support prefers-reduced-motion. #### Media and captions - Present: - This article is text-only. - Improve: - If embedding videos or podcasts (e.g., DHH on Lex Fridman), ensure captions and transcripts. #### Forms and interactions - Present: - Minimal or no complex forms. - Improve: - For any comments or subscription forms, ensure labels, error messages, and target sizes meet AA. #### Standards reference - Map gaps to WCAG 2.2 AA criteria. - Focus on 1.4.x (contrast), 2.1.x (keyboard), 2.4.x (navigable), and 3.3.x (input assistance). ### 🌍 DEIB Assessment #### Cultural breadth - Present: - Examples center on Western tech ecosystems (Rails, WordPress, Drupal). - Improve: - Include references to non-Western open source communities and multi-region perspectives. #### Inclusive language - Present: - Mostly neutral, professional tone; some quoted strong language from DHH. - Improve: - Provide brief context when quoting profanity; ensure definitions for specialized jargon. #### Neurodiversity support - Present: - Clear structure and chunked paragraphs; consistent narrative. - Improve: - Add more subheadings, bullet lists, and summary boxes for easier scanning. #### Representation - Present: - Focuses on high-profile male leaders; limited visible diversity. - Improve: - Highlight contributions from a broader range of maintainers and communities. #### Psychological safety - Present: - Critical but measured tone; acknowledges conflict without personal attacks. - Improve: - Link to community guidelines or codes of conduct for discussions stemming from the article. ### ✅ Logical Validity #### Strong reasoning - The article uses clear causal reasoning: misuse of the “open source” label undermines shared norms, which in turn threatens collaboration and trust. - It differentiates between necessary debates (definitions) and sufficient solutions (sustainability mechanisms), avoiding false dichotomies. #### Fallacies - The comparison to “North Korea calling itself a democracy” risks being seen as an inflammatory analogy, but the author explicitly calls it “clumsy” and focuses on the underlying point about mislabeling. - No significant fallacies dominate the core argument; claims are cautious, with explicit acknowledgement of uncertainty. #### Tone of voice - Tone: reflective, firm, and mildly critical. - It combines personal experience (“I have been wrestling with it for more than twenty years”) with balanced recognition of both DHH’s and Matt’s constraints and motives. ### 🛡️ DARVO Analysis - Deny: - DHH’s stance that OSI’s definition is “some shit people made up” functions as a denial of the community’s authority, but not in the context of abuse—rather, as deflection from established norms. - Attack: - There is pointed criticism of DHH’s dismissal and Matt’s analogy, but not in a way that attacks accusers as victims; it is critique of rhetoric and definitions. - Reverse victim/offender: - The article does not portray either DHH or Matt as victims of their critics; instead, it frames the broader open source community and maintainers as those bearing the cost of unresolved sustainability issues. - Overall, DARVO patterns are not central; the piece is more about misalignment and systemic pressures than about personal blame-shifting. ## 🎯 Conclusion The article argues that “open source” is a precisely defined, community-governed term that cannot be stretched to cover source-available licenses like O’Saasy without eroding trust. At the same time, it recognizes that maintainers face real sustainability challenges and that experiments like Fizzy’s licensing are understandable efforts to cope. The practical next step for readers is to use accurate licensing language, examine how they or their organizations benefit from open source, and actively explore ways to support the people and projects they depend on. ## 🧱 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] 5–10-word present-tense claim > [!quote] [Source available is not open source (and that’s okay)](https://dri.es/source-available-is-not-open-source-and-that-is-okay) by [[Dries Buytaert]] via [[dri.es]]. Published 2025-12-09. > “Open source only works when we agree on what the term means.” Two lines: context and use. Cite data if relevant. [view highlight](https://dri.es/source-available-is-not-open-source-and-that-is-okay#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [Source available is not open source (and that’s okay)](https://dri.es/source-available-is-not-open-source-and-that-is-okay) > “A more accurate framing would be that Fizzy is source available.” Two lines: context and use. [view highlight](https://dri.es/source-available-is-not-open-source-and-that-is-okay#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 needs shared definitions to work - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Open-Source-Governance]] [[License-Definitions]] #### [Z2] Source-available licenses trade freedom for sustainability - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Software-Licensing]] [[Open-Source-Sustainability]] --- ### ✏️ 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] Audit our product marketing for accurate “open source” vs “source available” usage/https://dri.es/source-available-is-not-open-source-and-that-is-okay #fleeting #inbox - [F2] Propose a contribution credit system modeled on Drupal’s for our key dependencies/https://dri.es/source-available-is-not-open-source-and-that-is-okay #fleeting #inbox - [F3] Draft an internal guide on choosing and naming licenses for new projects/https://dri.es/source-available-is-not-open-source-and-that-is-okay #fleeting #inbox --- <!-- deep-read:sections end -->