-
Notifications
You must be signed in to change notification settings - Fork 202
Proposal of a source code inventory pattern #322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 40 commits
2656ba4
dd4792e
680001a
3ec654b
c90ae3c
3982427
9ad0f23
bd6b2f1
0725837
6d94592
c0789e2
3778a2a
456563f
200d5c4
41f6b60
f69722a
93f2582
5ea79cd
ef4fc23
9e56f8e
fe03725
a4d0b4a
1c57a76
a32763c
b54e1c6
bb1696a
5c68fb2
1a285b1
fcdf80e
f539f30
eba1bdf
4bde80c
a9f7421
58d6464
3d37be5
ae1ffff
585e9ed
a95c162
be95507
b9bd29a
849278d
4e651dc
f3b3241
7314e14
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,109 @@ | ||
| ## Title | ||
|
|
||
| Unified Source Code Inventory | ||
|
|
||
| ## Patlet | ||
|
|
||
| In a large organization with different legal entities is often hard to get full visibility into all software assets, in particular all source code. This situation reduces the opportunities to increase business value and keep liability costs, such as software maintenance, under control across the organization as a whole. An organization-level source code inventory addresses these issues while exploiting opportunities to identify and support valuable InnerSource assets. | ||
|
|
||
| ## Problem | ||
|
|
||
| Given situations when InnerSource stakeholders do not value source code at the same level as other organization's assets; when source code strategies are ad-hoc and different among legal entities with little consolidation at organization-level; then it becomes harder both to select and support the right InnerSource project candidates as well as maximize business value of such a key asset. | ||
|
|
||
| Can you get consistent answers within the organization to questions like? | ||
|
|
||
| * How would you find all source code touched by anyone in your legal entity? | ||
| * How would you find out who else can also access each of the above? | ||
| * For new source code, what is your default level of access? | ||
| * How would you know nothing is missing from your inventory? | ||
| * What valuable insights or actions have you gained from your inventory? | ||
|
|
||
| ## Context | ||
|
|
||
| * You work on Legal Entity within a complex Organization under continuous change (e.g., new acquisitions or changing business priorities). | ||
| * You cannot find all source code touched, shared and consumed within the Organization. | ||
| * You do not have a clear policy on default sharing level when creating a new project (e.g., Open Source, InnerSource or Closed Source). | ||
| * You cannot scan significant parts of the Organization's source code looking for duplication, similarity or code smells. | ||
| * You do not know the existing ratios of Open Source, innerSource and Closed Source and their trend. | ||
| * You cannot measure the diversity of contributions and resulting value for a given project. | ||
| * You cannot identify and optimize tech stack diversity. | ||
| * You cannot identify technical debt and determine the priorities for retirement (e.g., dead APIs/source). | ||
|
|
||
| ## Forces | ||
spier marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| * Fragmentation of source code hosting systems in the organization. | ||
| * Ad-hoc source code strategies scattered across the different Legal Entities in the organization. | ||
| * Continuously changing map of the relationships between: projects, repositories, products, tech stacks, domains, solutions, platforms, services, components, sub-systems, people, authors, teams, external repositories. | ||
| * Diverse software culture of teams across the organization (e.g., more open to collaboration or more siloed). | ||
|
|
||
| ## Solutions | ||
|
|
||
| ### Set up an organization-level source code inventory live dashboard | ||
|
|
||
| * Combination of manual and automated input data sources to a single source of truth including an API for custom extension | ||
|
||
| * Key meta-data about each repository: | ||
| * Legal Entity | ||
| * URL | ||
| * Version control system (e.g., GIT or SVN). | ||
| * Hosting vendor (e.g., GitHub, Gitlab or BitBucket) and hosting type (e.g., on-prem, private cloud or public cloud). | ||
| * Sharing level (e.g., Open Source, InnerSource, Closed Source). | ||
| * Visualization in place to list all assets with options to filter based on meta-data | ||
| * Enable access to automated source code static analysis tools (e.g., identify duplicated or similar code, flag code smells, benchmark test coverage). | ||
|
|
||
| Mockup dashboard | Mockup questionnaire | ||
| :-------------------------:|:-------------------------: | ||
|  |  | ||
|
|
||
| ### Define a Source Code Strategy Assessment Framework | ||
|
|
||
| * Help to define a source code strategy including an explicit definition of policies at Organization and Legal Entity levels for: | ||
| * Inventory | ||
| * Sharing | ||
| * Consumption | ||
| * Contribution | ||
| * Ecosystem | ||
| * Example of such a framework: [https://github.com/trieshard/source-strategy-assessment/blob/master/framework.md](https://github.com/trieshard/source-strategy-assessment/blob/master/framework.md) | ||
spier marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ## Resulting Context | ||
|
|
||
| ### For the Organization, Legal Entity and Project maintainers | ||
|
|
||
| * We have explicit policies at Organization and Legal Entity level on source code strategy (e.g., where to create new repository or how to select the right sharing level). | ||
| * We can find all source code touched, shared and consumed within the Organization or Legal Entity and take actions as needed. | ||
| * We can measure the diversity of contributions and resulting business value for our project. | ||
| * We can identify technical debt and determine the priorities for retirement (e.g., dead APIs/source). | ||
|
|
||
| ### For InnerSource governance | ||
|
|
||
| * We can scan significant parts of our Organization's source code looking for opportunities of reuse, duplication, similarity or code smells. | ||
| * We know the ratios of Open Source, InnerSource and Closed Source within the Organization so we can steer as needed. | ||
| * We can identify and optimize tech stack diversity. | ||
| * We can create awareness and culture shift on certain Legal Entities as needed (e.g., ratio of Open Source and InnerSource below average). | ||
|
|
||
| ## Rationale | ||
|
|
||
| It creates a dynamic and extendable single source of truth for repositories to capture, visualize and act on source code repositories across the Organization. That helps to create awareness and focus efforts on the right direction. The Source Code Strategy Assessment Framework helps teams to understand the value of intentional explicit policies on how to manage source code. It helps to create both continuous improvement cycles and references within the Organization of what others are doing. | ||
|
|
||
| ## Known Instances | ||
|
|
||
| This is under test at scale at: | ||
|
|
||
| * Philips | ||
|
|
||
| ## References | ||
|
|
||
| * Organization and Legal Entity terms as defined in [InnerSource License Pattern Glossary](../2-structured/innersource-license.md#glossary)) | ||
spier marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| * Explore aligned deployment of this pattern in combination with the [InnerSource Portal pattern](../2-structured/innersource-portal.md). | ||
dterol23 marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ## Status | ||
|
|
||
| * Initial | ||
|
|
||
| ## Author(s) | ||
|
|
||
| * [David Terol](https://github.com/dterol23) | ||
| * [Simao Williams](mailto://me@simaos.net) | ||
|
|
||
| ## Acknowledgements | ||
|
|
||
| * [Sebastian Spier](https://github.com/spier) | ||
Uh oh!
There was an error while loading. Please reload this page.