Open source is a talent strategy 🔗 **Source:** [Open source is a talent strategy](https://leaddev.com/hiring/open-source-is-a-talent-strategy) > [!note]+ Document Notes > tags: [open-source, hiring, talent-strategy] > author: Manik Surtani, Bill Doerrfeld > source: LeadDev > reference: [https://leaddev.com/hiring/open-source-is-a-talent-strategy] > date created: 2025-12-03 12:00 > > # 🏷️ Title: Open source is a talent strategy > <!-- 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 - Block relies heavily on open source and has turned contributing and open-sourcing into a deliberate talent strategy. - Treating open source as core policy (not charity) improves hiring, retention, engineering quality, brand, and ecosystem stability. - Stakeholders: engineering leaders, OSPOs, maintainers, open-source communities, foundations, and regulated businesses. - Risks: ad hoc decisions on what to open-source, underfunded ecosystems, security issues, and maintainer burnout. - Bottom line: strategic contribution, innersourcing, and foundation support turn open source into a competitive advantage. --- ## 📖 Main Content - The article argues most companies already run on open source, but only a minority treat contributing back as a strategic business function. Block uses open source both as “good digital citizenship” and as a way to “punch above their weight” in attracting senior engineering talent. - Visibility is central: engineers whose work is public tend to avoid shortcuts, and candidates can assess real-world code. The authors suggest tracking hires with open-source backgrounds, retention, and whether lack of open-source engagement correlates with churn. - Block open-sources impactful internal projects such as Goose (an extensible, LLM‑agnostic AI agent for automating development tasks) and Bitkey (a Bitcoin wallet released for security and auditability). More eyes mean faster bug and vulnerability discovery, lowering long‑term maintenance risk. - They also contribute upstream to dependencies like Android and gRPC. This gives Block influence over roadmaps, compatibility, and performance, while helping ensure long‑term continuity of critical infrastructure. - An open source program office (OSPO) at Block goes beyond license compliance. It mentors engineers, helps decide what to open-source, supports maintainers, and promotes innersourcing—applying open-source collaboration patterns to internal code used by multiple teams. - Block backs ecosystem health financially via foundations such as the Kotlin Foundation, the Linux Foundation’s TODO Group, and the Open Source Initiative. Foundations provide neutral governance and prevent ecosystem failures (burnout, unmaintained critical libraries, surprise project shutdowns). - The article concludes that open source should be an explicit corporate strategy—covering funding, policy, innersourcing, and individual contributor incentives—because it improves recruitment, partnerships, internal culture, and the resilience of critical code. --- ### 🗒️ Notes - Modern software stacks are 70–90% open source; Block is representative of this reality. - Most companies underinvest in contributing or open-sourcing, leaving value (and risk reduction) on the table. - Strategic benefits: - Talent: public contributions attract strong engineers and act as a portfolio. - Quality: public visibility discourages shortcuts and encourages higher engineering standards. - Security: more eyes on code surface vulnerabilities earlier. - Influence: upstream contributions shape roadmaps and ensure compatibility. - Brand: active contribution boosts engineering reputation and partnership opportunities. - Block examples: - Goose: open-source AI agent for software tasks, LLM‑agnostic, reaching significant traction (tens of thousands of GitHub stars). - Bitkey: open-sourced wallet code to improve auditability and security trust. - Android & gRPC: upstream contributions to core infrastructure Block depends on. - OSPO responsibilities at Block: - Traditional: compliance and license/legal checks. - Expanded: mentorship on open-source practice, support for new maintainers, decision frameworks for open‑sourcing internal software. - Innersourcing: - Applies open-source practices (distributed collaboration, contribution workflows, transparency) inside the company. - Especially suited to internal services used by multiple teams, like internal dashboards. - Ecosystem support: - Membership in Kotlin Foundation, Linux Foundation TODO Group, OSI. - Foundations provide neutral governance, coordinate multiple corporate interests, and prevent failure modes like maintainer burnout or abrupt project EOL. - Recommended leadership moves: - Track hiring/retention tied to open-source experience. - Include open-source contributions and championing in promotion criteria. - Develop a “default to open” posture with guardrails. - Back critical dependencies with code contributions and funding. - Core thesis: since everyone already consumes OSS, treating contribution as a strategic pillar (not side hobby) yields outsized returns for both talent and resilience. --- ## 📚 References - LeadDev article: Open source is a talent strategy – https://leaddev.com/hiring/open-source-is-a-talent-strategy - Block (Square) – https://block.xyz - Goose AI agent – https://github.com/block/goose-ai (representative link; verify exact repo) - Bitkey wallet – https://bitkey.world or Block’s Bitkey GitHub org - gRPC – https://grpc.io - Android Open Source Project – https://source.android.com - Kotlin Foundation – https://kotlinfoundation.org - TODO Group – https://todogroup.org - Open Source Initiative – https://opensource.org - Linux Foundation OSS consumption statistic (70–90% OSS) – typical LF research summary pages --- ## 🗣️ Paraphrase - Paragraph A: The article shows how Block turns open source from a cost‑saving dependency into a proactive talent and product strategy by contributing code, open‑sourcing internal tools, and funding foundations. - Paragraph B: It argues that leaders should formalize open‑source policy, empower OSPOs and innersourcing, and measure hiring and retention outcomes, because treating open source strategically improves both business resilience and engineering culture. --- ## 📰 Newsletter Open source isn’t just infrastructure anymore—it’s a hiring engine. In this LeadDev piece, Block’s Manik Surtani explains how making contributions, innersourcing, and foundation support part of company strategy helps “punch above your weight” for engineering talent. For WordPress builders, the lesson is clear: visible contributions to core, plugins, and upstream PHP tooling can double as recruiting, reputation, and resilience. Consider how your org supports contributors, bakes open source into promotion paths, and funds the dependencies your stack leans on. --- ## ✅ Action Items #### DevRel - Map current and prospective open-source projects to developer personas; design talks and demos showing real‑world problems solved (e.g., “how we use our OSS agent to ship faster”). - Build short curricula on contributing to company and upstream projects (Git workflows, review norms, security basics). - Publish quickstarts and reference implementations for flagship OSS projects; keep SDKs and examples aligned with internal best practices. - Run campaigns around “contribute with us” (hack weeks, pairing streams) and attribute inbound candidates who cite OSS work. - Operate community spaces (forums, chat) with clear codes of conduct and periodic sentiment surveys to detect burnout. #### OSPO - Codify contribution and release policies (what can be open-sourced, approval paths, security and legal gates). - Maintain license compliance scanning and regular training on OSS licenses for devs and product managers. - Define vulnerability intake and embargo procedures for internal and upstream code; standardize signing and attestations for releases. - Keep an inventory of critical OSS dependencies; manage SBOMs and ownership; set freshness SLOs for upgrades. - Offer “office hours” to help teams decide whether to open‑source, innersource, or keep closed. - Manage memberships and sponsorships with key foundations; track impact and alignment with company strategy. #### Community - Support maintainers with roadmap check‑ins, release templates, automated changelog/release tooling. - Offer contributor onboarding sessions and “first issue” rotations, including pairing for new joiners. - Provide sponsors with transparent budgets, milestones, and impact narratives tied to business value. - Coordinate incident simulations across projects (e.g., dependency takedown, critical CVE) to test joint response. #### WordPress - Core: align open-source strategy with core priorities; encourage companies using WordPress at scale to upstream performance and reliability patches. - Core Performance: track performance bottlenecks in major hosts/themes and incentivize contributions that close real‑world perf gaps. - Core AI: articulate responsible AI guidelines for WordPress AI plugins and experiments; publish evaluation sets and transparency norms. - Core Program Team: schedule cross‑team rituals to surface where upstream contributions would unblock multiple teams at once. - Mobile: capture learnings from mobile‑specific OSS work (offline UX, push, security) and upstream them into core/mobile tooling. - Playground: use Playground for reproducible OSS bug reports, tutorials, and live contribution labs. - Community: ship meetup kits on “Using OSS as a hiring strategy” and “Innersourcing with WordPress.” - Training: design contribution learning paths from “new contributor” to “maintainer,” with example repos and sample issues. - Marketing: promote stories of companies that improved hiring or brand via WordPress contributions. - Support: maintain a knowledge base on licensing, security, and contribution patterns for plugin/theme authors. - Design: document reusable design tokens and patterns that live in public repos to encourage cross‑ecosystem reuse. - Documentation: expand examples‑first guides showing how to build and responsibly open‑source plugins/themes. - Photos / TV / Polyglots / Accessibility / Meta / CLI / Hosting / Tide / Openverse / Themes / Plugins: - Emphasize that contributing improvements and moderation capacity to these projects is both ecosystem care and talent branding. #### The WPOCC - Offer fellowships and microgrants tied to stewarding critical WordPress OSS components. - Run governance clinics to help large adopters set up internal OSPOs and innersourcing practices. - Pilot funding models (matched grants, milestone payouts) for under‑resourced but widely used plugins/themes. ### FAIR - Encourage local, verifiable metadata and signatures on critical OSS releases. - Publish transparent funding policies and anti‑capture covenants for WordPress and adjacent OSS. - Turn governance learnings into reusable templates—charters, MoUs, scorecards—for OSS projects and operators. --- ## 🧪 Hypotheses - Organizations with a formal open-source strategy (including OSPO + incentives) will see higher engineering retention than similar orgs without one. - Open-sourcing internally successful tools (like Goose) increases high‑quality inbound engineering applicants. - Companies that contribute upstream to their critical dependencies experience fewer severe production incidents tied to those dependencies. - Innersourcing practices correlate with faster cross‑team delivery and fewer duplicated internal tools. - Financial support of foundations governing critical OSS decreases ecosystem‑level security incidents over time. --- ### 📊 Methodology - Run matched cohort studies comparing engineering retention and time‑to‑hire across companies with and without explicit OSS strategies. - Analyze recruiting funnel data before and after launching/highlighting open‑sourced internal projects; track applicant volume and quality. - Correlate incident postmortems with dependency upgrade cadences and upstream contribution levels. - Survey and instrument innersourcing adoption (PR patterns, cross‑team contributions) and measure lead time for multi‑team features. - Use public vulnerability databases and foundation membership lists to compare incident rates in projects with strong vs. weak institutional backing. --- ### ❓ Questions - How much engineering time should a non‑software‑native company realistically allocate to open-source work? - When does open-sourcing internal tools risk competitive advantage more than it improves hiring? - What is an effective promotion rubric for open-source impact that doesn’t disadvantage non‑maintainer roles? - How can smaller companies participate meaningfully without overextending staff or budgets? --- ### 🔮 Future Research - Longitudinal studies on how open-source visibility impacts compensation and promotion trajectories. - Comparative case studies of companies that default to open vs. default to closed in regulated industries. - Frameworks for quantifying the ROI of foundation memberships and sponsorships. - Best‑practice blueprints for OSPOs at different maturity and company sizes. --- ### 💡 Implications - Practice: Engineering orgs should treat open-source work as first‑class, with budget, time, and promotion pathways. - Policy: Regulators and industry groups could encourage transparent support for critical OSS, especially in finance and infrastructure. - Security: Upstream contributions and foundation support become part of cyber‑risk management, not just goodwill. - Education: Developer education should include open-source citizenship, licensing, and innersourcing habits. - Funding: Sustainable funding models for critical OSS are directly tied to corporate risk reduction and talent pipelines. --- ### 🧠 Learning Styles Assessment - Reading level estimate: roughly Flesch–Kincaid Grade 11–12 (dense corporate/technical vocabulary, long sentences). #### 👀 Visual learners - Present: Primarily text; conceptual descriptions of OSPOs, innersourcing, and foundations. - Improve: Add diagrams of the OSS ecosystem, OSPO responsibilities, and flows between internal, open‑sourced, and upstream projects. #### 🔊 Aural learners - Present: None indicated. - Improve: Offer audio narration or a short podcast episode discussing Block’s approach and similar case studies. #### 🗣️ Verbal learners - Present: Clear explanations, quotes from Surtani, examples of projects like Goose and Bitkey. - Improve: Add a short glossary (OSPO, innersourcing, foundation) and more analogies for non‑technical leaders. #### 🧩 Kinesthetic learners - Present: Implicit suggestions (set up OSPO, innersource); no step‑by‑step tasks. - Improve: Provide checklists and “first 90 days” playbooks for launching an OSPO or open‑sourcing a project. #### 🧠 Logical learners - Present: Causal reasoning (open-source → visibility → talent/quality), some metrics suggestions. - Improve: Include explicit decision trees for “open vs. closed vs. innersource” and sample KPI tables. #### 🧑‍🤝‍🧑 Social learners - Present: Emphasis on collaboration, communities, and foundations. - Improve: Add guided discussion prompts and workshop formats for leadership and engineering teams. #### 🧘‍♀️ Solitary learners - Present: Article can be read and reflected on individually. - Improve: Include reflection questions like “Where does our company already rely on under‑funded OSS?” #### 🌿 Naturalistic learners - Present: No environmental analogies. - Improve: Use ecosystem metaphors (e.g., keystone species, resource flows) to explain OSS health and dependencies. --- ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Likely standard article headings; little info beyond that. - Improve: Ensure proper heading hierarchy, language attributes, and descriptive alt text for any images. #### Keyboard navigation - Present: Typical web article structure should be keyboard‑navigable. - Improve: Confirm visible focus indicators and add skip‑to‑content links if absent. #### Contrast and readability - Present: LeadDev usually uses reasonably high contrast and body text size. - Improve: Check contrast ratios, line spacing, and paragraph spacing for long‑form readability. #### Text resizing and reflow - Present: Responsive layout probably handles mobile and zoom reasonably. - Improve: Verify reflow at 200% zoom and consider “prefers-reduced-motion” support. #### Media and captions - Present: This specific article is text‑based. - Improve: If adding video/audio, include captions and downloadable transcripts. #### Forms and interactions - Present: Minimal interactive elements (maybe newsletter/signup). - Improve: Ensure form labels, error messages, and target sizes meet WCAG 2.2 AA. #### Standards reference - Map improvements to WCAG 2.2 AA, especially 1.4.x (contrast), 1.2.x (media), 2.1.x (keyboard), 2.5.x (inputs), 3.3.x (errors). --- ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focuses on a US‑based fintech, Block. - Improve: Include examples from diverse regions and industries, especially non‑US and under‑resourced ecosystems. #### Inclusive language - Present: Neutral, professional; minimal jargon beyond technical terms. - Improve: Add plain‑language summaries that non‑engineering leaders can easily follow. #### Neurodiversity support - Present: Clear sections, but dense paragraphs. - Improve: More headings, bullet lists, and consistent patterns to reduce cognitive load. #### Representation - Present: Quotes a single leader (Surtani) and one company (Block). - Improve: Include voices from maintainers, smaller companies, and community organizations. #### Psychological safety - Present: Encourages supportive structures (OSPO, mentorship); no hostile framing. - Improve: Explicitly address burnout and healthy boundaries for open-source contributors. --- ### ✅ Logical Validity #### Strong reasoning - Inductive/causal: “Visibility of work → better hiring and fewer shortcuts.” This is plausible, aligns with anecdotal experience, and is supported by examples like Goose and Bitkey. - Strategic framing: “If you depend heavily on OSS, you have an interest in its health, so you should invest.” This is a coherent risk‑management argument. #### Fallacies - Potential survivorship bias: Focus on Block’s success may overgeneralize to all companies. Could be balanced with counterexamples or constraints. - Limited quantification: Claims about benefits (retention, quality) are largely qualitative; stronger if paired with data. #### Tone of voice - Professional, pragmatic, mildly advocacy‑oriented. - Uses quotes to ground claims (“You punch well above your weight to get good talent”) without being bombastic. --- ### 🛡️ DARVO Analysis - Deny: No denial or minimization of responsibility; instead, it emphasizes responsibility to contribute. - Attack: No attacks on critics or detractors. - Reverse victim/offender: The article does not portray companies as victims of open source; instead, it frames them as beneficiaries with obligations. - Overall: No DARVO patterns; rhetoric is constructive and responsibility‑oriented. --- ## 🎯 Conclusion Open source is framed as core infrastructure and a deliberate talent and resilience strategy, not a side project. Block’s example shows how contributing code, open‑sourcing internal tools, innersourcing, and funding foundations can attract better engineers, improve security, and stabilize critical dependencies. Practically, readers should assess where they already rely on OSS, define contribution policies and incentives, and empower an OSPO (formal or lightweight) to turn that reliance into a strategic advantage. --- ## 🧱 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 visibility boosts hiring outcomes > [!quote] [Open source is a talent strategy](https://leaddev.com/hiring/open-source-is-a-talent-strategy) by [[Manik Surtani, Bill Doerrfeld]] via [[LeadDev]]. Published 2025-11-28. Accessed 2025-12-03. > “Working in open source helps visibility, which helps attract better talent.” Two lines: captures the claim that public work improves recruiting and retention; useful for notes on OSS‑driven hiring. [view highlight](https://leaddev.com/hiring/open-source-is-a-talent-strategy#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] OSPOs extend beyond compliance into mentorship > [!quote] [Open source is a talent strategy](https://leaddev.com/hiring/open-source-is-a-talent-strategy) > “Our OSPO is more than that” and provides guidance and mentorship on open-source fundamentals. Two lines: shows OSPOs as cultural and educational anchors, not just legal gatekeepers. [view highlight](https://leaddev.com/hiring/open-source-is-a-talent-strategy#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 visibility improves talent attraction - Holds for engineering organizations that publish meaningful OSS used by peers. - Pointer: LeadDev article; Surtani’s quote about “punching above your weight.” - Links: [[Open-Source-Talent-Strategy]] [[Engineering-Branding]] #### [Z2] OSPOs function as cultural infrastructure - Holds where OSPOs mentor contributors and shape innersourcing, not just licenses. - Pointer: Description of Block’s OSPO in the article. - Links: [[OSPO-Design]] [[Innersourcing-Practices]] --- ### ✏️ 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] Sketch a 90‑day plan to bootstrap a lightweight OSPO inspired by Block — context/https://leaddev.com/hiring/open-source-is-a-talent-strategy #fleeting #inbox - [F2] Define promotion criteria that reward open-source and innersourcing impact — context/https://leaddev.com/hiring/open-source-is-a-talent-strategy #fleeting #inbox - [F3] Audit which critical OSS dependencies my org should fund or contribute to — context/https://leaddev.com/hiring/open-source-is-a-talent-strategy #fleeting #inbox --- <!-- deep-read:sections end -->