Proven approaches that can guide you through applying open source best practices within your organization
Home Page: https://patterns.innersourcecommons.org
License: Creative Commons Attribution Share Alike 4.0 International
... on whatever
InnerSource Portal - Hygiene
Based off the InnerSource portal pattern.
Allow generation of an official badge for projects intending to be recognised as InnerSource project within your company.
This will help users distiguishing InnerSource projects which strive to adhere to InnerSourcing principals from repos that have been made public due to neglegence or other reasons, plus the badge serves as additional marketing for the InnerSource intiative at your company.
Large organisation with lots of public repos, not all necessarily meeting the desired innerSource project standard.
Sorry about the picture :(
In your InnerSource portal allow registering your project as an InnerSource project. This is a super simple an intuitive webform that only requires you to enter your repos url.
Once the url is entered some basic checks will be carried out against your repo based on some very basic standards required for entry into the InnerSource portal. These checks include:
Once all checks have passed the InnerSource portal will generate your very own InnerSource badge, which is basically am image with a random filename. Note this badge is specific to the repo that was being registered. In the background the repo name, badge filename and badge expiry date is stored.
The last step is for users update there repos README.md file to include the badge. This will then allow the InnerSource portal to discover the project and will automatically include it in the portal.
The autom managed InnerSource portal and badge system has ensured that the InnerSource portal only displays active projects and as result contains less clutter, thus increasing the credibility of the portal and InnerSource project initiative itself. The badges in the repos itself allow people to quickly distinguish an innerSource project from a standard public repo.
#156 is great stuff, we just need to remember to add a GitHub Action to regenerate the SVG / HTML / rendered products once the .md changes and make a checklist item for PRs to update the .md once new things come in to keep everything fresh.
Originally posted by @lenucksi in #156 (comment)
Define how we want to use the InnerSource patterns repo for brainstorming, writing, reviewing and publishing InnerSource patterns
I propose a folder structure that reflects the maturity that a given pattern as reached.
Specific proposal:
patterns
├── donut
├── proven
└── unproven
What happens to the existing patterns:
patterns/provenREADME.md today.I work on a fintech company, recently, we are going to start a InnerSource project , but my group members are distributed on different cities. Is there any feasible steps ?
just for fun
Hey, I'd like to share with all of you our previous work in Maturity Models.
Work done by Jorge from Entelgy, Nerea from Zylk, and Daniel from Bitergia.
| Key process AREAS / Maturity LEVELS | ACCIDENTAL (L0) | EXPLORATION (L1) | ADOPTION (L2) | EFFICIENT (L3) | SURVEY MAPPING |
|---|---|---|---|---|---|
| TRANSPARENCY | |||||
| Plans & Products | Individuals and teams do not regularly disclose their plans or products to multiple stakeholders. No formal actions exists at the organization. | Individuals and teams give visibility to their plans or products to multiple stakeholders, before they are started. Shared roadmap. |
Stakeholders can contribute to some plans or products | There is an standard process for collective product and plans definition | |
| Development Process & Tools | Each team follows its own development process and tools. They are not defined to share knowledge and artifacts outside development team. Siloed development teams. | Development teams use shared code repositories, internally. Some teams develop their own CI process, using non corporate or standard CI tools. There is no code review process defined, although some projects teams do it internally. |
The organization sponsors and promotes a shared repository for collective knowledge Some teams develop their own CI process, using corporate CI tools. There are CI environments. Code review process defined, and used by some projects. Code review is sometimes done by external team members. |
Most teams develop their own CI process, using corporate CI tools. There are CI environments. Code review process defined, and used by some projects. Code review is usually done by external team members. |
|
| Decisions | Decision-makers often withhold data and resources without explanation | Materials that are part of decision-making practices become available for review after decisions are finalized | People feel like they know about—and are helping to shape—most (but not all) important decisions as those decisions are unfolding. Materials that are part of decision-making practices are available at defined project milestones |
People feel like they are a part of a shared, standard process for collective decision-making that the organization endorses Materials that are part of decision-making practices are continuously accessible during work processes |
|
| Helpful Resources | Individuals and teams neither contribute to nor draw upon a shared repository of knowledge | Individuals and teams release project materials for review internally, after they've finished their work Individuals and teams share resources, but in disconnected, fragmented, or individualized/siloed systems or repositories Individuals and teams share resources, but there is no commonly expressed or shared understanding of the criteria used to determine whether information is sensitive or not. Do not "share thinking on others". |
Individuals and teams make project-related materials accessible to some members of project teams according to clearly defined and shared formats and/or protocols Individuals and teams withhold sensitive data and resources, provide limited details, context, and scope |
Individuals and teams make project-related materials broadly accessible to the organization—and possibly outside the organization as well—according to clearly defined and shared formats and/or protocols Individuals and teams who must withold sensitive data and resources are clear about what they're not sharing, and others understand why those materials are not available to them |
|
| Stories | Individuals and teams are comfortable sharing stories about successes, but not about failures | Individuals and teams are comfortable sharing stories of successes and failures during retrospectives and reviews | Individuals and teams are comfortable sharing stories of successes and failures, and learn from failures according to formal protocols | ||
| COLLABORATION | |||||
| Channels for Providing Feedback | There are no processes nor stablished channels. Some members of the organization share materials via private channels or discussions. |
The organization is in the process of establishing internal guidelines and channels for encouraging diverse points of view about company/departmental decisions, so that anyone belonging to the organization can use them Some members of the organization share decision-making materials unformally using unofficially platforms Leaders maintain at least one clear and direct channel for organization members to share opinions constructively on some matters relevant to their work |
The organization has established internal guidelines and channels, and provides specific resources (training programs, access to content, etc.), for encouraging and soliciting diverse points of view on team or decisions Members of the organization share decision-making materials on officially sanctioned platforms |
Members of the organization share materials openly via multiple channels and methods for feedback Leaders use those channels themselves, openly encourage others to use them, and maintain team-facing or public-facing records of the feedback they've received and/or the actions they've taken to address this feedback |
|
| Leadership | Command & control culture, within a highly hierarchical organization. | Some leaders are open to receiving feedback and creating an environment where people feel safe providing it | Most leaders in the organization are open to receiving feedback and creating an environment where people feel safe providing it Leaders show passivity about understanding whether all members feel empowered and enabled to share Organization encourages leaders to actively seek voices not present in dialog out for inclusion |
Members feel empowered and enabled to share opinions constructively on any matter relevant to their work or about which they feel passionate | |
| Organizational and Functional Structure | Working groups tend to be static in terms of membership and skill sets | Cross-functional teams exist, but team roles are often unclear and governance structures are vague | Cross-functional teams are common, and teams post their roles and goals publicly | Cross-functional teams are common and make their activities known broadly to the organization; in turn, the organization promotes best practices for working together | |
| Contribution | Completly siloed, no collaboration outside the teams. Just some collaborations due to cross-functional teams | Members of the organization and teams collaborate but frequently say it's "too difficult" Teams infrequently revisit the outcomes of their collaborations |
Members of the organization and teams actively seek opportunities to collaborate Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and make these outcomes available by default |
Members of the organization collaborate both internally and externally in ways that benefit all involved Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and share their learnings outside the organization, and make these outcomes externally available by default |
|
| COMMUNITY | |||||
| Sharing Policies | No sharing culture nor written policies. | Some members of the organization unite to define values and principles, but are not clearly supported when they do | Members of the organization collectively document shared visions and agreements like mission statements and codes of conduct, make them easily accessible, and reference them often Onboarding materials and orientation rituals provide adequate context for helping new members understand how the organization will benefit from their contributions |
Shared values and principles inform decision-making, conflict resolution, and assessment processes among members of the organization, who reference these values and principles consistently in both verbal and written formats | |
| Feel part of the Organization | Low engagement, no collaboration and people do not feel comfortable sharing with others. | Members of the organization feel comfortable sharing their thoughts and opinions without fear of retribution, but only in familiar domains People understand that the best ideas win, and leadership responsibilities accrue to people with histories of contribution and commitment |
Members of the organization feel comfortable sharing their thoughts and opinions without fear of retribution Leaders demonstrate dedication to the organization's shared values |
The organization is proactive in telling members that it benefits from their contributions; as such, members demonstrate shared consciousness and empowered execution, and feel a sense of responsibility to the community Leaders understand that they grow by helping others grow, and they mentor junior members of the organization |
|
| Governance | |||||
| Rewards | No rewards | Leaders are encouraged to reward exceptional collaborations, but there are no policies or processes established | Standard processes are established to reward collaborations outside the developers' teams. Team leaders or boards decide who has to be rewarded. | Rewards are not only proposed by the organization, but the communities are able to define their more valuable rewards. The community is responsible to decide who has to be rewarded. | |
| Monitoring Policies | No existing monitoring policies | Some people start using metrics for their own needs at their own hierarchical level | Existing process at the organization | Clear rules and processes in the use of metrics with specific training and monitoring in place | |
| Support and Maintenance | Support given by the core dev or support team. A business contract guaranties the support. There is no knowledge about the product outside the team | There are rules and regulations to formalize the support on the product, given by a dedicated supporting team | There are rules and regulations to formalize the support on the product, given by a mature community | ||
| Culture | Silos | Reactive | Contributive | Activist | |
| InnerSource Roles | There are no specific roles helping InnerSource adoption. Only common development roles are present: developer, analyst, tester, etc. | Occasionally some individuals and teams contribute to other projects. These are technical contributions, where the user/contributor role is seen. For some teams, it can be identified at least one member being a technical reference, who explains the development process to other development team members. He/she could be a candidate for covering the trusted commiter role. |
An InnerSource Officer role is in charge for governance and support, including processes, etc. Identifies the education needs and ensures it is provided to the organization. Leads and mentors the organization in the engagement in IS projects. Is the first formal step in the way, defining the IS vision and roadmap. The organization has defined a trusted committer role, being a point of contact/reference not only for dev team members but also for external contributors. There is a standard process describing how to contribute to the community, contributor role is present. Data Scientist role is in charge of managing the traces of activity left by the InnerSource initiative, needed to measure the IS evolution. |
Trusted committer role will evolve to a more technical profile, and a community manager will be in charge of "energyze" the community, being his main responsibility to attract and retain new developers/users (contributors/community members). Evangelists are moving inside organization, to let others know about the current work, what InnerSource does and how to do it, and help others to understand and become part of the initiative. Non technical contributors appear. |
README.md contains a link to a wiki page that does not exist (anymore).
[Donut 8: Not Invented Here](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-8:-Not-invented-here)
I have not checked the history of https://github.com/InnerSourceCommons/innersourcecommons.org/wiki yet but I would suspect that it was deleted at some point?
@lenucksi any idea about this one?
We've listed a few Trusted Committers in our TRUSTED-COMMITERS.md file. We've discussed the benefit of using the GitHub automation around this.
Hence, this issue is about enabling this.
.github/codeowners file with the listed persons handles in it.As we know , metrics just like a product must be sell to different kinds of users including C-level, middle managers and the team members. All of them are concerned about different aspect. So what kind of metrics would work?
I'm not sure if this is one pattern or multiple:
I think it would be beneficial for people that are just about to start with InnerSource and have no experience with Open Source to give some guidance on which communication to have where - similar to what @bdelacretaz is describing there:
https://www.youtube.com/watch?v=HPjYa_O6yEk
I'm not sure if this should be a separate pattern or something that we reference from the Open Source world though.
Contractors from separate companies or organizations will not fully collaborate on a shared code-base, often viewing each other as competitive in nature despite an overarching org telling them otherwise. This is common in the US Federal Government, where the government is required to contract out the majority of its software production needs, and very often uses multiple contractors on a single project. It could also occur if org's have announced a partnership, but parties within each org still consider themselves competing forces.
#156 is great stuff, we just need to remember to add a GitHub Action to regenerate the SVG / HTML / rendered products once the .md changes and make a checklist item for PRs to update the .md once new things come in to keep everything fresh.
Originally posted by @lenucksi in #156 (comment)
Following on from a conversation in the ISC Slack, would a metadata file added to Inner Source repos in source control (e.g. inner-source.json or inner-source.yaml) aid discovery of Inner Source repos within an organisation? If so, should we define a common format for this metadata?
Alternatively, should this information be derivable from your SCM tool (GitHub/GitLab/Bitbucket etc.)? This would negate the need to add a file to each inner source repo in your organisation.
One suggested format:
# description should be one paragraph
description: This is where you describe the purpose to your users.
Is this a component library, is this a template project, what
benefit is there to me if I use this library in my own project. You
Could even say something about how the project is versioned here.
# github pages or a conflunce link by default
# could be a readme for the project
documentation: https://github.com/InnerSourceCommons/InnerSourceLearningPath/
# technologies used
technologies: Javascript, React, Graphql, etc..
# comma separated list, name <email> (url)
maintainers: Barney Rubble <[email protected]> (http://barnyrubble.tumblr.com/)Prior art:
Pattern Donut Idea: “The ‘F’-you InnerSource project” - Where a team says they are innersource because you can ‘simply send us a pull request!’ but they don’t provide avenues for actual ramp-up, friendly community interactions, places to ask questions (and get them answered), documentation to learn, etc. As told to: Nick Yeates
The link to Poor Naming Conventions 404s and i can't find the file to correct the link.
DB Systel created their own InnerSource License, see DB Inner Source License (in German).
They used the EUPL, as that offered an open-source-like starting point, and then worked out the constraints and additional rules required in their specific company context.
I would like to turn this into a pattern, mostly to learn how they did it, and also how the pattern syntax "works in practise" :)
Human Resources department or hiring managers can use inner source and open source as a selling point to prospective candidates. These can be key to building and sustaining your target culture.
Mentioning it as "Inner Source (Internal Open Source)" may clarify to candidates who aren't familiar with the term. Also, mentioning full-out open source projects (if they exist in your org) may be 'sexy' to candidates.
I found that many of the branches are fully merged into master already, and therefore should be safe to delete:
* master
remotes/origin/HEAD -> origin/master
remotes/origin/common-req-patlet-change
remotes/origin/master
remotes/origin/modular-code
remotes/origin/pattern-states
remotes/origin/pattern-system
remotes/origin/pattern-system-Russ
remotes/origin/pattern-template-update
remotes/origin/pattern/30-day-warranty
remotes/origin/pattern/dont-bother-looking
remotes/origin/pattern/introducing-metrics-in-innersource
remotes/origin/pattern/junkyard-styled-innersourcing
remotes/origin/pattern/modular-code
remotes/origin/pattern/start-as-experiment
remotes/origin/readme-links
Time for some cleanup? :)
There is engineering-level support of innersource, but not management-level. Ex: Management wont support sharing of source code across departments/contractors and still expects waterfall-type reporting of man-hr requirements (vs something more Agile).
We should develop an initial version of an advanced style guide. This is relevant for the maturity level 4: established proposed by #155.
(Edited by @maxcapraro)
When comparing the number of markdown files in this repo, to what is linked from README.md, I found that the numbers are different:
$ ll *.md | wc -l
19
$ ack "\([^/]+.md\)" README.md | wc -l
15
So we have 19 markdown files, but only 15 files linked in README.md.
I will send a PR to investigate where the difference comes from.
Likely a lot can be taken from
https://tech.europace.de/voting-in-new-trusted-committers/
as well as from
http://community.apache.org/newcommitter.html
This information needs to be translated into pattern format though.
This task aims at bringing to this repo the donut available at https://github.com/paypal/InnerSourceCommons/wiki/Pattern:-change-the-developers-mindset
I'll assign this to myself in a first stage and upload the pull request.
Despite the contribution guidelines stating "First you need to create a branch (no need to ask for permission!)." I am not able to create a branch. Please help
@spier noted very correctly that there are stale issues and PRs (e.g. here #17 (comment)).
This increases the burden for people who want to learn "what's going on" and makes it more difficult to new contributors. Also, it might give the impression that we don't care about our "project hygiene" :-)
I suggest we enable Github actions that label and close stale issues and PRs.
Do you have objections / concerns / comments?
Story provides a more narrative, less academic description to a pattern. When a pattern has a good narrative description at the first few sections, it helps people deciding quickly whether this is something they want to dive deeper. Some patterns provide good narrative while some other patterns lack those narrative angle. It would help to add story or improve narrative description to the patterns that don't have good narratives.
It could be helpful to validation patterns against the Pattern Template for various reasons:
## (h2) (i.e. no #)I tried out markdownlint, together with the the GitHub Action markdown-linting-action.
As many of the existing patterns contain optional headlines as well as custom headlines, we will likely have to write custom validation rules. I have already tried this out and it looks manageable. (see experimental code).
My current suggestion would be to validate rules 1-4 above, but don't validate rule 5.
bring from wiki and then make it more detailed, explaining terms and states
Something, anything. Bring from wiki?
Just for testing PRs.
It's great to see so many IS patterns from the community. A good problem we have is how to make these patterns easy for discovery/consumption. Here's some thought for discussion.
One pair is management and empowerment. Some patterns help to manage, govern, mitigate risk. Some other patterns help to empower, attract, build communities. This categorization can help others to quickly find the group of patterns that fit their needs.
Another angle is single project vs organization. Some patterns are applicable to single project, while others are organizational effort. For people working on specific initiative, single project level patterns might be more interesting. For people working on scaling IS, organizational patterns are important.
Thoughts? Comments?
Currently we have patterns in various places:
There are some challenges with this:
a) it is harder to find the patterns (as one has to look in multiple places)
b) providing feedback for the patterns in the wiki is not possible (as the wiki does not get forked together with the rest of the repo)
c) providing feedback for the patterns in gDocs might not always be possible (depending on how the owner of the gDoc has set the permissions)
Therefore I propose to move all patterns to the repo, irrespective of the Maturity or Review Step they are in.
This change will empower all contributors to use the same contribution process for any pattern i.e. fork + edit + pull request.
To slice the problem a bit smaller, I suggest to start by moving the patterns from the wiki to markdown files in the repo.
bringing content from https://github.com/paypal/InnerSourceCommons/wiki/Common-Requirements
The common code in the shared repository isn’t meeting the needs of all the projects that want to use it.
I would like to propose an idea for an inner source pattern - not sure if others have seen similar issues in their organisation.
Imagine the following situation: We are looking at an organisation that values devops as an approach to software development and deployment. Teams are responsible end to end: Starting with requirements engineering, software development down to deployment and maintenance, support etc.
Team A has developed service lovelyTree. Team B has a business issue, that could be solved by re-using lovelyTree, except they need a few modifications. When cross team collaboration and inner source is brought to the table, both teams are reluctant to collaborate - it's unclear who should get the wakeup call for the service, also error handling and communication chains are different for both teams.
The solution is to remind the team that this is about inner source, not inner deployment: Much like in open source, the same source code can be deployed in more than one context while still sharing the bulk of the code in one common service (or one common library that encapsulates the business logic).
This is related to the 30-day-warranty pattern, except it gives a bit more flexibility in a micro-services world.
Risk: This pattern breaks in a setup where one team has a vested interest in providing their software as a common service to others, e.g. when trying to collect data to feed into some machine learning training pipeline.
I am making this assumption:
The #Status defined in pattern-template.md is meant to be one of the defined pattern-states.
Assuming that the above is true:
When reading some of the existing patterns I found that some of them don't have a #Status set at all, while others have one but they don't match the defined pattern-states.
Would it be worth fixing this, so that all patterns specify what their Pattern Maturity is, following the pattern-states.
For reference some examples of patterns and their #Status:
$ egrep -A2 "Status|State\s*$" InnerSourcePatterns/*.md
InnerSourcePatterns/30-day-warranty.md:# State
InnerSourcePatterns/30-day-warranty.md-Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.
--
InnerSourcePatterns/common-requirements.md:## Status
InnerSourcePatterns/common-requirements.md-Shepherded pattern
--
InnerSourcePatterns/contracted-contributor.md:## Status
InnerSourcePatterns/contracted-contributor.md-_Proven Pattern_
--
InnerSourcePatterns/dedicated-community-leader.md:## Status
InnerSourcePatterns/dedicated-community-leader.md-_Reviewed Pattern_
--
InnerSourcePatterns/discover-your-innersource.md:## Status
InnerSourcePatterns/discover-your-innersource.md-Brainstormed pattern idea in progress
--
InnerSourcePatterns/improve-findability.md:## Status
InnerSourcePatterns/improve-findability.md-Brainstormed pattern idea reviewed 2017-03-11.
--
InnerSourcePatterns/introducing-metrics-in-innersource.md:# State
InnerSourcePatterns/introducing-metrics-in-innersource.md-Early Idea
--
InnerSourcePatterns/junkyard-styled-innersourcing.md:## Status
InnerSourcePatterns/junkyard-styled-innersourcing.md-Brainstormed pattern idea in progress
--
InnerSourcePatterns/modular-code.md:**Status:**
InnerSourcePatterns/modular-code.md-Donut
--
InnerSourcePatterns/review-committee.md:## Status
InnerSourcePatterns/review-committee.md-_Finalized and Reviewed_ as of 8/31/17.
--
InnerSourcePatterns/start-as-experiment.md:# Status
InnerSourcePatterns/start-as-experiment.md-Proven Pattern
While this is not a source code repository, there are still some classes of bugs that we can avoid. We could establish some automated checks. From the top of my head:
CONTRIBUTING.md is the common place naming scheme in OSS github projects.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.