was an artificial island created exclusively to receive and host European traders in 17th-Century Edo Period Japan in accordance with the shogunate's strict foreign policies.
created exclusively to receive and host European traders in 17th-Century Edo Period Japan in accordance with the shogunate's strict foreign policies. You can trade here You cannot
a journey to culturally transform towards an internal sharing economy similar to open source, while respecting corporate culture and internal organizational constraints, and breaking down organizational silos.
community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. Founded in 2015, the InnerSource Commons is now supporting and connecting over 2500 individuals from over 750 companies, academic institutions, and government agencies.
project extends across many teams within the organization. This allows the organization to embed differentiating trade secrets into the code without fear that they will be revealed to outsiders, while benefitting from the creativity and diverse perspectives contributed by people throughout the organization. From “Getting Started with InnerSource” by Andy Oram, an editor for O'Reilly Media
and discoverable by placing a README.md file and a CONTRIBUTING.md file at the top of the repository. Transparency - The direction of the project/repository, unresolved feature requirements, progress on feature requirements, and decisions of the host team are made transparent. Prioritized Mentorship - With prioritized mentorship from the host team to the guest team by Trusted Committers, contributors from the guest team are leveled up to fully understand and make changes to the host team's project/repository. Voluntary Code Contribution - Participation in InnerSource from both the guest team and host team is done based on their free will.
the software lifecycle and publish design documents to facilitate early discussions. 30 Day Warranty Contracted Contributor InnerSource License Base Documentation InnerSource Portal Design Document Guiding Principles Trusted Committer Improve trust between the two teams by allowing contributors to fix bugs and suggest features with 30 days of support. Encourage contributions to InnerSource through formal contracts and agreements within the organization, rather than as volunteers. Provide a legal framework for sharing source code within an organization and offer new collaboration options. Index InnerSource project information to make it easier for contributors to discover projects of interest. Define ways to recognize ongoing contributor work. Provide standard project documentation and a self-service process for new contributors. Document and make widely available the key principles of InnerSource. Patterns Short Description
provides the means and environment to realize InnerSource within the organization. While the program office promotes development, it is not a development department or a gatekeeper. Main responsibility: • Sharing of InnerSource policies • Measuring InnerSource Metrics (eg. # of PR across teams) • Conducting mentoring/training • Developing incentive models • Ensuring appropriate tooling PR Cross Team PR % Q1 FY19 852k 37k 5.6% Q2 FY19 810k 35k 4.2% Q3 FY19 912K 39k 4.8% Q4 FY19 1.0M 46k 4.1% Q1 FY20 1.2M 43k 3.6% * The above is an example from Microsoft.
tap the organization’s collective knowledge, and collaborate across teams to improve software. Appendix / Customer Stories Paul Pottorff / Cloud and Security Architect
need to place more emphasis on the Developer Experience. Productivity and cost savings Consistency and quality Security and compliance. Speed. * “Why your IT organization should prioritize developer experience” by McKinsey https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-forward/why-your-it-organization-should-prioritize-developer-experience
project extends across many teams within the organization. This allows the organization to embed differentiating trade secrets into the code without fear that they will be revealed to outsiders, while benefitting from the creativity and diverse perspectives contributed by people throughout the organization. From “Getting Started with InnerSource” by Andy Oram, an editor for O'Reilly Media
leads to misunderstandings and creates friction. Basically, both can be achieved, but know that there are different balances for different purposes. InnerSource for Developer Experience to maximize the value of the people & teams InnerSource as a Competitive Strategy to maximize the value of the product and IP vs
collaborative culture • Improve skill levels through sharing • Employee satisfaction • Production Cost Reduction by preventing reinvention of the wheel InnerSource as a Competitive Strategy: • New value or innovation through co-creation • Quality improvement through sharing • Synergy between products through team collaboration • Production cost reduction by preventing reinvention of the wheel
• Fewer legal, tax, and accounting issues • The product itself is not considered of much value • Hard to measure the impact Project examples: Documentation, Templates, Shared libraries, Internal tools, SDK, API, Hackathon projects InnerSource as a Competitive Strategy: Measurements: Value Added • Legal, tax, and accounting issues are very complex • Clearly trying to share "product and technology value,” which of course brings its own set of problems • Middle management unwilling to allow employees to contribute (=provide the value) beyond the team Project examples: Patented Technology, Technologies related to Intellectual Property, Competitive advantage product itself)
components. Collaboration between specific teams The team receives contributions Autonomous collaboration with various teams The team receives contributions widely within the organization Considerations for Each Type and the Respective Evolutionary Paths Apply IT Asset Management best practices to share "software" items in the accounting entries. Establish labor management and sharing rules for each team for Components of the R&D phase (that are not "software" in the accounting entries) Software Entries Established sharing rules for consolidated accounting Establishes rules for transfer pricing taxation Coordinate by discussing in advance how the cost center will be managed Create a template as an InnerSource License so that collaboration can easily occur Organize the organizational view of the InnerSource rules on transfer pricing taxation Since the scope of sharing in a particular project is limited, it may be sufficient to work with the accounting department. Innersource Program Offifce will assist in turning examples into an innersource license and develop an official corporate license Model collaboration as an InnerSource License, so that cost centers and shared rules do not have to be conversed with each team every time. Take into account IP usage rules and usage restrictions, as well as black- boxing of reusable portions. Set rules for IP sharing Develop rules and best practices for sharing limited portions of IP (that hide valuable and patent-related portions of IP, such as sharing only interfaces such as usage SDKs and libraries) Organize the company's view of the InnerSource rules on transfer pricing taxation and prepare internal documents. At this time, there is a possibility that the software could be shippable as a category of software or could be considered as "just labor being provided" to the core hosting company [WIP] More sorting out is needed here Further steps of collaboration are necessary when seeking autonomous and flexible sharing of items beyond internal black boxing, such as sharing only the SDK, or redefining the scope of shared items by splitting the architecture. For example, it is necessary to define a mechanism for selling the developed items to the company or other companies, such as a joint venture. Note: This documentation does not represent a formal GitHub / InnerSource Commons Foundation position based on accounting, tax, or legal considerations. It is a list of items for each of the considerations as a starting point for discussion of the technical InnerSource adoption in the company. 42 Single Legal Entity Collaboration Within the Group International collaboration Collaboration With External Companies
components. Collaboration between specific teams The team receives contributions Autonomous collaboration with various teams The team receives contributions widely within the organization Considerations for Each Type and the Respective Evolutionary Paths Apply IT Asset Management best practices to share "software" items in the accounting entries. Establish labor management and sharing rules for each team for Components of the R&D phase (that are not "software" in the accounting entries) Software Entries Established sharing rules for consolidated accounting Establishes rules for transfer pricing taxation Coordinate by discussing in advance how the cost center will be managed Create a template as an InnerSource License so that collaboration can easily occur Organize the organizational view of the InnerSource rules on transfer pricing taxation Since the scope of sharing in a particular project is limited, it may be sufficient to work with the accounting department. Innersource Program Offifce will assist in turning examples into an innersource license and develop an official corporate license Model collaboration as an InnerSource License, so that cost centers and shared rules do not have to be conversed with each team every time. Take into account IP usage rules and usage restrictions, as well as black- boxing of reusable portions. Set rules for IP sharing Develop rules and best practices for sharing limited portions of IP (that hide valuable and patent-related portions of IP, such as sharing only interfaces such as usage SDKs and libraries) Organize the company's view of the InnerSource rules on transfer pricing taxation and prepare internal documents. At this time, there is a possibility that the software could be shippable as a category of software or could be considered as "just labor being provided" to the core hosting company [WIP] More sorting out is needed here Further steps of collaboration are necessary when seeking autonomous and flexible sharing of items beyond internal black boxing, such as sharing only the SDK, or redefining the scope of shared items by splitting the architecture. For example, it is necessary to define a mechanism for selling the developed items to the company or other companies, such as a joint venture. 43 Single Legal Entity Collaboration Within the Group International collaboration Collaboration With External Companies
Premise: Basically, you are allowed to collaborate if you wantso • In a 100-person company, everyone is collaborating at the Enterprise level in an internal-type repository at GitHub. • In a 2000-person company, 300 people are collaborating within the one single GitHub organization. But not all users of GitHub Enterprise have access to the codebase. • In a 5000-person company, 5 units, 1400 people are collaborating in a single closed repository in InnerSource way
different ways by different people • Don’t only be a Product-oriented or People-oriented thinker, Draw the holistic roadmap and prioritize what you want as an organization • Don't be a fundamentalist, be Flexible and get start with Innersource These will reduce friction, and achieve competitive advantage and the great Developer Experience at the same time.
yuhattor
shin1988
rryz09
vtryo
oikon48
yanzm
oracle4engineer
kakehashi
ahus1
bata_24
moznion
maruloop
davidcarrasco
samanthasiow
gurzu
stuffmc
rkendrick25
honzajavorek
jonrohan
afnizarnur
codingconduct
.png){kind=avatar}
helenjbeal
samtorres
tanoku
