of applying Open Source principles inside an organization. Focus on What you do Make internal assets accessible so teams can share and contribute. Goal Enable cross-team collaboration and knowledge sharing for successful outcomes. Dirk Riehle, Inner Source (Software Development), InnerSource Summit 2018 Welcome visitors! Open all artifacts! Openness Transparency Prioritized Mentorship Voluntary Code Contribution
≠ “Just Open Everything” It’s about opening the right things to the right people and MORE. 01 Everything must be open. Openness should be designed based on who benefits. Start with the right scope, not full exposure. 02 InnerSource is the ultimate goal. InnerSource is a means, not an end. The real goal is accelerating collaboration, innovation, and impact. 03 It’s only about source code. Documentation, templates, scripts—any reusable, editable and commentable asset counts. 04 You need a massive company- wide community. Success starts small—two teams collaborating is already InnerSource in action. 05 If you open it, contributions will come automatically. Contributions require clear processes, transparency, and psychological safety (e.g., review SLAs, decision logs)
Contexts Open widely — but with purpose. Misunderstanding “Open all artifacts!” sounds like everything must be open without limits. What it really means “Open all relevant artifacts to everyone who can benefit” Goal Recommended Practice ⚫ Ensure that when new stakeholders join, there’s no barrier or cost to grant access. ⚫ Openness enables collaboration, reuse, and faster onboarding. ⚫ Make artifacts visible across the company (unless legal/security constraints apply). ⚫ Actively notify the people who could benefit right now. ⚫ Benefit: ⚫ Reduces friction when teams expand. ⚫ Encourages cross-team discovery and reuse. ⚫ Builds a culture of transparency without chaos.
practical mindset and approach to solve real business or technical challenges by using InnerSource Principles to creating value together. Key Point Details Start with “Who is it for?” • Identify (potential) stakeholders who will use or contribute to the asset • This question determines the right level of openness Openness Principle • Ideal: open to everyone in the company. • Minimum: ensure the identified stakeholders have access. Focus on Common Issues • If multiple teams share the same requirements or pain points, InnerSource delivers immediate value. Beyond Code • Include docs, templates, scripts—anything reusable and editable Focus on How and Why you do it Use InnerSource principles as a tool to deliver measurable value. Goal Drive successful outcomes (innovation, speed, and impact) through collaboration.
InnerSource Way Approach Start with shared challenges and common interests with right people Supporter （Expert） Proposer Supporter （Developer / User） Open Environment Ideas/Solutions Issue Implementation
Over 60 Products: Why So Many? Letter Sorting Machine Industrial Controller Broadcasting Weather Rader Controller for Thermal Power Plant Elevator Destination Control System Multifunction Printer … and much more
to the Entire Company Dev Dept. A Dev Dept. C Private Environment Dev Dept. B Linux Distro Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. Linux Disto Dev Team
to the Entire Company Linux Disto Dev Team Dev Dept. A Open Environment Dev Dept. B OSS Community Dev Dept. C Contractor C Dev Dept. D Contractor A Product team Linux Distro
to the Entire Company InnerSource principles accelerated standardization and reuse Background Approach ⚫ Multiple business units required Linux → A common challenge needed to be solved ⚫ Released the distribution company-wide ⚫ Accepted improvement proposals via Pull Requests and Issues Results ⚫ Standardization improved development efficiency ⚫ Bug reports from external partners enhanced quality ⚫ Increased reusability reduced costs across multiple businesses ⚫ Ease to contribute to upstream OSS community
Planning Open Environment Leader Teams / OneDrive （Open to everyone） Share/Comment/Revise/Respond Reviewers Comment Product Owner Comment/ Requirement/ Proposal Manager Member Corporate SNS Manager / Member From other depts. Marketing Review/ Approve
Planning (Background and Impact) A plan only has value when it reaches beyond one team Background Positive Impact ⚫ Our division develops technologies intended to benefit multiple business units ⚫ During mid-term technology planning, both documents and decision-making process were made visible to the entire company ⚫ Created an environment where “anyone can comment,” ensuring transparency ⚫ Diverse feedback from business units improved the plan ⚫ Different perspectives helped us refine priorities and uncover blind spots ⚫ It increased visibility of our work and created potential collaborators ⚫ A bit sparked interest in building a culture of open discussion
Planning (Failure and Lessons) A closed room turns collaboration into defense — no alternatives, no progress Failure Lessons ⚫ Initial response was slow (over a week without action) ⚫ Internal closed-door review → invisible to contributors ⚫ Discussions skewed toward defending existing positions, lacking alternative proposals ⚫ Feedback requires immediate response + public visibility ⚫ Log decisions and rationale so anyone can trace them later ⚫ Design spaces for dialogue from a community perspective
From static documents to living knowledge. Overview Operation ⚫ Created a technical catalog in Markdown for company-wide sharing ⚫ Accessible via browser; improvement proposals submitted through Pull Requests ⚫ Product Owner: Oversees the entire catalog ⚫ Trusted Committer: Reviews PRs and ensures consistency ⚫ Contributor: Submit contents or enhancements via PR ⚫ Low-friction improvement: “If something wrong, fix it with a PR” encourages participation Results ⚫ Transparent history → Knowledge accumulation ⚫ Self-service updates → Avoids bottlenecks to update ⚫ Minimal load makes continuous operation feasible
(My role) Supporting PO and TC Negotiate with other Product Owners Environment preparation for efficient work • Time allocation for documentation (leveraging internal exhibition time) • Safe and collaborative environment via shared development platform Internal Marketing • Used the materials at internal exhibition
(Community building at internal exhibition) Simple solutions that “remove pain” tend to spread widely Overview ⚫ Needed to accelerate to create simple-text slide creation → Adopted Marp ⚫ Developed a template aligned with corporate format and made it public Corporate Slide Style Template Ref: https://marp.app/ Markdown-based Slide contents
(Community building at internal exhibition) Simple solutions that “remove pain” tend to spread widely Overview Approach to scale ⚫ Needed to accelerate to create simple-text slide creation → Adopted Marp ⚫ Developed a template aligned with corporate format and made it public ⚫ Displayed posters to recruit users and collect improvement suggestions ⚫ Initial phase: lots of feedback → Later phase: stable usage continued Results ⚫ Markdown-based slides in corporate format became easy to create ⚫ Feedback improved template quality significantly ⚫ Low maintenance over time, but high sustained value for users
stay transparent, enable contributions, then grow with support. Step What to Do Why it Matters 1. Define “Who is it for?” Clearly identify the target users/team Knowing who benefits clarifies what should be shared 2. Start Small, but Open Begin with 1 asset and 2 teams or persons – and make it accessible to others Safe to try, easy to join, low resistance 3. Make It Transparent Open source, discussions, decisions, history Transparency builds trust and reusability 4. Set Contribution Rules ( & SLA for PO and TC ) Define how to submit issues/PRs and response time (e.g. within 48h) Contribution only works when there’s a reliable response 5. Clarify Roles Assign PO, Trusted Committer and other Prevents “open but unmanaged” projects 6. Measure & Share Metrics Track PRs, adoption, time-to-merge, contributor diversity Visible impact → easier to get support and funding 7. Gain Management Support & Scale Present results, secure budget and formal backing Scaling requires structural support, not just enthusiasm
Company – Scaling InnerSource in Japan 2. Series Articles on CodeZine (Web Media) Reference: https://codezine.jp/article/detail/14809 Shoeisha, Yoshitake Kobayashi Licensed under CC BY-SA 4.0 1. InnerSource Learning Path – Japanese Translation Reference: https://innersourcecommons.org/ja/learn/learning-path/ InnerSource Commons Foundation Licensed under CC BY-SA 4.0 3. Talks at Conferences & Meetups Reference: https://innersourcecommons.connpass.com/event/271207/ InnerSource Commons Foundation
InnerSource Way InnerSource doesn’t start from “someone else.” Roll What they can do Executives • Set a clear vision: “Cross-team collaboration is valued here.” • Support cross-organizational projects with budget and policy • Provide a safe environment and tolerance for trying & failing Managers / Team Leads • Connect teams that share the same problem → form cross-team projects • Encourage to make project outputs visible (avoid closed-room development) • Recognize and reward contributions across teams includes incentives Members • Start small: publish scripts, docs, templates—anything reusable • Send Issues/PRs to other teams’ work • Invite others: “Would you like to solve this together?” • Each role has a different but essential action to take. • When these align, culture starts to shift.
the InnerSource Way Take one step with the InnerSource Way : think open, share a little and create value beyond your team. Step What You Can Do 1. Define who benefits Identify who benefits and why 2. Share something small A script, document, template or anything — make it visible to others who may have interests 3. Make it transparent and discoverable Open documents, discussions, history in Slack/Teams/Git repo and add README, CONTRIBUTING.md, usage example 4. Find one collaborator Invite a colleague or ask your manager: “Want to try doing this with InnerSource Way together?” 5. Show the value Track users, PRs, time saved — even small wins matter
and Collaboration Potential Unique Innovation (企業が顧客に提供する価値) Commodity Platform Ref: How to Contribute to the Linux Kernel, and Why it Makes Economic Sense (James Bottomley, Novell; LinuxCon Japan 2009) Delivery Support for the innovation (価値提供に必須の技術) Area Mainly Covered by OSS Commodity Platform (Ready-to-Use) Delivery Support for the innovation (Technology Required for Value Delivery) Unique Innovation (Value Delivered to Customers) Area Addressed by InnerSource We can solve common challenges that cannot be shared outside the company!
Overcome Them Each barrier has a practical way to solve it — not theory, but tactics. Barriers What Happens How to Overcome “Everything must be open” Misunderstanding Teams hesitate → fear of exposing unfinished work Start with limited-scope openness (e.g., 2 teams, internal repo only). Define what is shareable or not. Low motivation / “What’s in it for me?” No contributors, no momentum Translate value into business language (time saved, bug reduced). Highlight success cases & give credit visibly. Slow or no response to contributions Contributors feel ignored → stop contributing Set response SLA (e.g., reply within 48h). Use public triage meetings, open backlog, decision logs. “Closed-room decisions” after feedback People think feedback goes nowhere → trust is lost Keep discussions open. Record decisions publicly. Show accepted & rejected proposals (and why). Governance & confidentiality concerns Managers block sharing due to risk and compliance Prepare a “tiered openness model” (internal-only, selected teams, company-wide). Define approval rules & roles.
Planning (Improvement Plan) From defending the plan to evolving the plan together Key Point What to Do 1. Public Triage • Set regular review sessions (open for anyone to observe) • Prioritize Issues and proposals in a transparent forum 2. SLA (Response Rules) • Aim for initial response within 48 hours • Clearly state: “Acknowledged” and “Next Action” 3. Public Backlog & Decision Log • Progress and rationale must be traceable by anyone • Use standardized templates for PRs and Issues 4. Alternative Proposals • When rejecting, provide reason and suggest alternatives • Maintain trust through transparent decision-making
ystk
tkyowa
hayama17
shogogg
nrslib
staffrecruiter
danielbryantuk
mot_techtalk
shuta13
minorun365
rung
rfdnxbro
belongadmin
jakevdp
schlessera
bkeepers
jct
sonatard
madoxten
.jpg){kind=avatar}
cargoodrich
nikkihalliwell
rasagy
honzajavorek
gurzu
kristinabergwall1
