Blue-Sky: an Open Source Contribution Process Specification

[shanecoughlan]

Mail to Spec List on 2023-06-28:

Dear OpenChain Specification Work Group

Jimmy Ahlberg (Ericsson, OpenChain Chair) was brainstorming with Matthew Crawford (Arm board member) and myself about potential new specifications that may be useful for the OpenChain Project to consider. One interesting item discussed was the concept of taking our existing reference to contribution in ISO/IEC 5230 and building on that to have a full adjacent specification for open source contribution management.

(Section 3.5 of OpenChain Licensing 2.1 (ISO/IEC 5230): https://github.com/OpenChain-Project/License-Compliance-Specification/blob/master/Official/en/2.1/openchainspec-2.1.md)

(1) This would have utility for the many organizations that would like to get started in contributing to open source but may be hindered by the fact that no internal processes exists.

(2) It would avoid attempting to bolt on too many things to our existing focused standards, a model which makes sense now that we are in the business of building a family of standards.

(3) Meanwhile, the projects receiving contributions would have assurance that contributions are properly approved by the contributing organization. This may include various measure such as code checks to reasonable contain copyright concerns etc.

= Summary =

We have a foundation to build from that could potentially neatly lead people from ISO/IEC 5230 to another complementary, sister specification to get more granular around contribution. Today is about putting this on the table and getting your comments and suggestions. What do you think?

For the foundation on which we may potentially build, see Section 3.5 of OpenChain Licensing 2.1 (ISO/IEC 5230):

== Start ==

3.5 - Understanding open source community engagements

3.5.1 - Contributions

If an organization considers contributions to open source projects, then
• a written policy shall exist that governs contributions to open source projects;
• the policy shall be internally communicated; and
• a process shall exist that implements the policy

Verification material(s):

If an organization permits contributions to open source projects, then the following shall exist:
• 3.5.1.1 - A documented open source contribution policy;
• 3.5.1.2 - A documented procedure that governs open source contributions; and
• 3.5.1.3 - A documented procedure that makes all program participants aware of the existence of the open source contribution policy (e.g., via training, internal wiki, or other practical communication method).

Rationale:

When an organization permits open source contributions, the intent is that the organization has given reasonable consideration to developing and implementing a contribution policy. The open source contribution policy can be made a part of the overall open source policy or be its own separate policy.

== End =

Regards

Shane

[shanecoughlan]

On Jun 28, 2023, at 20:53, Mattran, Mary [email protected] wrote:
It would be helpful to my company to have this now as we are building our contribution process now.

[shanecoughlan]

Thanks Mary, let’s get this show on the road :)

The OpenChain Project has prior work in this area via ISO/IEC 5230 Section 3.5. Anything we do will be expansion of this work rather than blank sheet, and it will come with the usual framing considerations applied in our process management context.

Starting off, the optic taken by the OpenChain Project is “what” rather than “how,” so the scoping discussion will naturally focus on what process points are needed, while leaving the details of how the processes are filled to reference material.

The potential end result? It could be:
(1) another sister standard to ISO/IEC 5230 and ISO/IEC 18974,
(2) or it may be a discussion that leads to improvements to the existing standards,
(3) or it may be an item that we conclude does not fit into our portfolio.

I have created a repo for us to record issues (and this thread):
https://github.com/OpenChain-Project/Contribution-Process-Specification

Reference Item #1 - Let’s take a look at ISO/IEC 5230:2020 Section 3.5 - Understanding open source community engagements

3.5.1 - Contributions

If an organization considers contributions to open source projects, then

• a written policy shall exist that governs contributions to open source projects;
• the policy shall be internally communicated; and
• a process shall exist that implements the policy

Verification material(s):

If an organization permits contributions to open source projects, then the following shall exist:

• 3.5.1.1 - A documented open source contribution policy;
• 3.5.1.2 - A documented procedure that governs open source contributions; and
• 3.5.1.3 - A documented procedure that makes all program participants aware of the existence of the open source contribution policy (e.g., via training, internal wiki, or other practical communication method).

Rationale:

When an organization permits open source contributions, the intent is that the organization has given reasonable consideration to developing and implementing a contribution policy. The open source contribution policy can be made a part of the overall open source policy or be its own separate policy.

[shanecoughlan]

Ana from TODO Group has flagged two items of potential interest.

The first is that TODO Group’s Slack has a channel called #wg-employee-engagement-guide and the participants are working on six principles of open source engagement. I will hand over to Ana in this thread to expand on those principles and links to source.

There is also a TODO Group publication called "A Guide to Outbound Open Source Software” with a section discussing contribution towards open source projects:
https://todogroup.org/guides/outbound-oss/#how-to-contribute-to-oss-projects

[shanecoughlan]

There is some SAP material on the topic here:
https://www.openchainproject.org/news/2023/07/21/external-saps-outbound-open-source-processes

[shanecoughlan]

Reminder: the question is what - apart from listed below - is needed to help organizations with their open source contribution processes. The immediate answer seems to be:

(1) More about the procedure for governing open source contributions
+
(2) More about the procedure to make all program participants aware of the contribution policy

From ISO/IEC 5230 Section 3.5.1

Contributions

If an organization considers contributions to open source projects, then
• a written policy shall exist that governs contributions to open source projects;
• the policy shall be internally communicated; and
• a process shall exist that implements the policy

Verification material(s):
If an organization permits contributions to open source projects, then the following shall exist:
• 3.5.1.1 - A documented open source contribution policy;
• 3.5.1.2 - A documented procedure that governs open source contributions; and
• 3.5.1.3 - A documented procedure that makes all program participants aware of the existence of the open source contribution policy (e.g., via training, internal wiki, or other practical communication method).

Rationale:

When an organization permits open source contributions, the intent is that the organization has given reasonable consideration to developing and implementing a contribution policy. The open source contribution policy can be made a part of the overall open source policy or be its own separate policy.

[anajsana]

TODO focuses on topics related to sharing best practices regarding an organization's open source strategy and contributions. I believe that the resources and expertise from the TODO community can offer valuable guidance and support during the creation of this standard

As Shane referenced in the last email, TODO has an OSS Employee Guide WG working on the six principles of open source engagement (WIP), along with a previous TODO guide called "A Guide to Outbound Open Source Software"(Completed).

I would like to share more details in this email on the six principles that TODO WG has been developing, so hopefully these can be referenced in the standard and re-use existing content: The principles are documented in the todogroup/todogroup.org issues and have a dedicated milestone. (Everyone can become a contributor and join the WG, btw). The content of this guide splits into several issues:

• General Documentation

• Principles

  • Starts Early
  • Puts the Community First: the collective holds the timeline
  • Starts With Listening
  • Has Transparent Motivations
  • Ends Gracefully

• Open Questions/ Suggestions

• Bad Experiences maintainers suffered from corporate developers

Thank you for your time and consideration 🙂

[shanecoughlan]

Hi Ana!

Thank you for sharing these links and highlighting the work of the TODO Group around OSPOs and open source contribution, and additional best practice information developed by the project on adjacent open source topics. This will be useful contextual information for our work in exploring a contribution process management specification.

I wanted to reiterate that OpenChain has always been about making standards and best practices around open source process management. Our goal is to ensure open source is delivered with trusted and consistent process management information. It is inherent to implement our vision as outlined on our site:
https://www.openchainproject.org/.

More specifically:

The OpenChain Project has an extensive global community of over 1,000 companies collaborating to make the supply chain quicker, more effective and more efficient.

We Maintain Standards

• OpenChain ISO/IEC 5230: The international standard for open source license compliance programs
• OpenChain ISO/IEC DIS 18974: The industry standard for open source security assurance programs

We Develop Best Practices

Our community develops best practices to reduce friction and increase efficiency across all aspects of open source process management. Everyone is invited to be part of what we do. There are no restrictions to join our mailing lists, our calls and most of our events.

We Are Carefully Focused

The OpenChain Project is focused on commercial and non-commercial open source process management in the supply chain. It is not involved in other aspects of government policy or political issues. Similarly, we do not develop software or work on different topics around open source.

One important point is that our scoping has always been what not how, both in how we make ISO or de facto industry standards, and in how we present our large corpus of reference material and community groups to the global supply chain. As outlined in our FAQ, the OpenChain Project:

• Embraces different implementations to solve challenges
• Avoids mandating specific process content

An example is that we reference SPDX ISO/IEC 5962:2021 in the Terms and Definitions of ISO 5230, but it is not included as a normative mandate in the standard itself. Instead, we mandate that an organization should use an SBOM, as we have since 2016. The choice of SBOM is entirely up to their market requirements.

This may indicate a certain difference between OpenChain and TODO in approach, and also place information in a slightly different context.

TODO Group focuses on how the implementation choice of creating an OSPO can work on an operational-level for organizations. Underlying these are some normative assumptions. For example, implementation assumptions (“you should manage this through an OSPO”) or operational correctness (“you should probably be a project contributor if you use open source”).

There is nothing wrong with having these assumptions, but it is equally true from OpenChain's current insight into the supply chain via our work groups, neither assumption holds true at this juncture for the majority of the companies involved in the global supply chain.

Mental models with normative assumptions appear to impact the six principles you flagged, for example here [1] in the discussion around 'Principle 2: Puts the Community First.’ This approach works in the context of guiding individual engineers around project contribution with a mission to avoid community friction, but it is a different optic to business strategy decisions for organizations with other motivations.

To put it another way, all of an organization’s open source work may be managed through an OSPO, but an OSPO is an implementation choice, and plenty of organizations use other methods to manage open source. By the same token, some organizations want to contribute to projects, some do not know it may be beneficial to contribute, and some explicitly do not want to contribute. All of these stances are equally valid from a business strategy perspective, albeit with the middle one being a “you should probably explore this” item.

OpenChain Project operates at the organizational and inter-organization level. We reference but do not mandate implementation choices. Our job is to address and support all the organizations in the supply chain regardless of their implementation choices. We do this by identifying the key requirements of quality process management programs, with actually filling the process items being up to them. We help organizations locate context, get information, make their choices and - along the way - increase trust in the supply chain.

To be clear, we definitely want to learn from pre-existing work originating from OSPOs. But I want to set expectations around the type of material that will inform our process management work in considering a contribution specification. We will be focused on the what from an organizational perspective with the topic of trust in the supply chain. The how is an individual organization decision.

Principles with a normative bias are reference points to compare against actual corporate actions, but they are unlikely for inclusion in the standard. They generally fall under how and normative modeling.

At first glance the stance of the OpenChain Project may appear to be somewhat dismissive of the norms and perceived useful benefits in the context of open source as a software management paradigm. However, the inverse is true.

1. Many of the OpenChain Project contributors (well, all) are aware of the value open source and the open source community offers.

2. However, the context of how we address the global supply chain confronts us with the reality that most organizations have:

• (2i) Little awareness of open source use and management at any level.
• (2ii) Little reason to care about the open source community at this juncture.
• (2iii) And no extra resources to apply to the subject regardless.

3. That said, OpenChain has always had the concept of “raising all the boats” through providing the simplest and most core process management for an organizing to use open source. We have most famously addressed this through licensing and now security standards.

• (3i) These help address the largest systemic risks to both the users of open source and the broader open source ecosystem in terms of legal exposure and legislative exposure.
• (3ii) To borrow a term from finance, these are not only a Product Development Cost line item for the CFO, but are fundamentally a Cost of Goods line item.
• (3iii) Put another way, this is is the baseline for open source use.

4. Our collective experience over the last two decades show that many users become better users and then potentially become contributors. Our reference material supports this without asserting that it is a requirement.
5. For example, a company needing a bootable kernel on generic Arm silicon with a functional network stack has little reason to contribute to the Linux kernel or worry that the Linux kernel will disappear. But they still need a contribution policy (“nope” in policy/process form).
6. In the end, we are convinced of the value of open source as the most effective way to manage software yet created, and we are equally convinced that this becomes evident to companies as they mature.
7. We open the door to maturity in the objective distillation of core process management for quality license compliance or security assurance programs in what form, we provide reference material to help inspire people on the how, and we reference other projects for further learning, tools and support.
8. And now we are responding to market demand from input that it would be useful to expand the contribution section of ISO 5230 with more baseline process items for organizational management.
9. We are responding to similar marketing demand in determination of quality SBOM requirements and other domains.
10. These discussions may lead to expansion of our portfolio of sister standards after review and approval by our board.

Phew. Long mail. Also posting to GitHub issue here:
#1

Next steps: read TODO materials and other materials flagged from SAP.

Regards

Shane

[1] "Putting community first means that the majority of actions are taking with the community in mind not any particular company. This means as a corporate developer your role is not to push your company's roadmap into the project but rather contribute from your experience with other community members towards solving problems the community is facing."

[shanecoughlan]

Noticed typo in the above comment from website copy/paste. Corrected. Website also adjusted. Penalty of having updates across reference site links happening at the same time as other material like mails are being prepared. New process in play to avoid in future.

[shanecoughlan]

On Jul 28, 2023, at 18:33, @anajsana wrote:

Hello Shane and all,

Thanks again for the detailed explanation of OpenChain's contribution process specification.

Indeed, while both the Linux Foundation's projects, OpenChain and TODO, may sometimes deal with similar open source challenges faced by organizations, they follow different goals and ways to operate. TODO is an OSPO community of practice that focuses on identifying key process choices related to open source engagement and creating tools and educational materials that promote best practices around such engagements.

However, considering the increasing number of OSPOs being established as the preferred approach for managing open source operations not only within enterprises but also in governments and public administrations, my aim with this email is to emphasize that this specification holds great significance for OSPO professionals seeking to implement it within their respective organizations. So, I'd like to involve representatives from the TODO Community to contribute to this specification whenever possible.

Shane, could you guide us on the best way to welcome the TODO community to become contributors to this specification? Do you have any documentation that explains how OpenChain's specifications are created and the typical process/workflow they follow? I can share that information with the TODO OSSEmployee Engagement WG to help them understand better and ease their contribution efforts.

Best

Ana

[shanecoughlan]

From Jimmy Ahlberg @ Ericsson on July 28, 2023 20:31:20 JST

Hi Shane, Its really great to see that we are starting this WG activity, and that there is already momentum and expressed need for it. I just wanted to flag that most of Europe (certainly northern Europe) are in vacation mode, myself included. I think we will see much more engagement in September from Europe once we settle into our normal work routine. So far it seems that there is a great base to start pulling knowledge from, and contribute to. Knowing myself I will probably be unable to resist the temptation to do some work on this over the summer holiday. 😊

BR J

[shanecoughlan]

From Simon Phipps @ OSI on July 29, 2023 0:37:43 JST

One more item to consider is the Good Governance Initiative Handbook, now in edition 1.1 and freely reusable under a CC-BY license, produced by an open collaboration of European open source organisations. See https://ospo-alliance.org/ggi/ for more information.

Cheers

Simon

[shanecoughlan]

Hi Ana!

There is no doubt that we want to tap into all the current knowledge and experience around contribution from parties involved in TODO Group. As you pointed out, OSPOs have grown rapidly in number over the last couple of years, and for a clear reasons: they provide a useful, practical way to help manage open source inside organizations.

We try to make onboarding as smooth as possible for all interested contributors. We have a formal process as listed at the link below and with key parts extracted below for reference as well.
https://www.openchainproject.org/resources/faq#specification-development-questions [1]

In short, once something gains traction with people interested in developing it further, we hold a kick-off call and review the process.

The email thread clearly shows traction and interest, so let’s start scheduling the kick-off call. I have created a Doodle Poll here:
https://doodle.com/meeting/organize/id/eg2GL2Gd
This call will be recorded and shared online for everyone to review.

Meanwhile, Jimmy has opened Issue #2 to show the initial topics for discussion. That gives us the first topics once we formally run through the process on the kick-off call:
#2

Let’s get this show on the road :)

Regards

Shane

[1] See below for the key items from the Specification Development section of the FAQ:

We have four guiding principles:

1. Build trust around the open source supply chain.
2. Remember that less is more:
   -- Define the key requirements of a quality program
   -- Do this by solving real pain points in the supply chain
3. Keep our specifications limited to what and why (avoid the how and when)
   -- Embrace different implementations to solve challenges
   -- Avoid mandating specific process content
4. Be open to all to participate and contribute

Our community development process is to:

1. Hold a community kickoff meeting and revisit the OpenChain Project specification development guiding principles.
2. Accept and discuss feedback from anyone who wants to participate either at the Monthly Community Calls or on the specification mailing list.
3. Record feedback through GitHub issues for the relevant specification. The current practice is usually to have a GitHub Repository dedicated to each specification under development.
4. Publish modifications and additions in a draft document contained in relevant GitHub Repository.
5. Open a Public Comments Period six weeks before our target completion date. This runs for 30 days and only accepts minor updates such as typos or grammar corrections that do not change the requirements of the content. We do not accept any material changes during this period. All other feedback and recommendations are queue for consideration during the next version release cycle.
6. Open a Freeze Period two weeks before our target completion date to allow a 14 day review of any changes made during the Public Comments Period.
7. If a consensus expresses concerns over any changes made during the Public Comments period we would i) make changes to accommodate those concerns followed by ii) an additional 14 day Public Comments period; followed by iii) another 14 day Freeze period. Anyone with significant reservations on the final draft should state their position/concerns via the spec mailing list. The changes will be accepted once we achieve consensus for the final draft.
8. In the event we do not have consensus on the final version – we would repeat the following cycle until we have consensus: i) accommodate changes to address majority concerns; ii) 14 day Public Comments period; followed by iii) a 14 day Freeze period cycle.
9. Send the completed draft specification to the OpenChain Steering Committee for formal review and a vote on whether to accept the community recommendations for an updated or new specification.

[shanecoughlan]

On Aug 2, 2023, at 20:11, Cornelius Schumacher [email protected] wrote:

Hi Shane,

as somebody who was and is involved with the creation of the two guides from the TODO group, I would like to share my perspective how these could be useful from the point of view of an OpenChain contribution process specification:

The upcoming "Employee Open Source Engagement Guide" is meant to give guidance to contributors working on behalf of an organization. This is a vital element of a framework for contributions. I would think, that in a contribution process specification it would make sense to have something along the lines "You should have guidance for contributors how to engage with the open source community" and the TODO group guide could be a reference and possible implementation for that.

The "Outbound Open Source Guide" describes motivation and processes for managing contributions. It includes descriptions and advice on how to structure contribution processes. It's more concrete and more focused on the how than what would be in the process specification, but it might be interesting to use it as a check for the areas which should be covered by a process specification.

In any case, it's great to see that there is the initiative to create an OpenChains specification for contributions. I'm pretty sure that this will be helpful to many organizations which create or evolve their processes for open source contributions.

Kind Regards,
Cornelius

--
Cornelius Schumacher
Open Source Steward
Enterprise-Team Chief Technology Office (CTO) (T.IP E-T-378)

DB Systel GmbH
Digital Campus, Kynaststraße 1, 10317 Berlin

[shanecoughlan]

Thanks Cornelius. Well noted.

To ensure that we have explicit action items for reviewing this material, I have opened issues here referencing the material in this thread (new issues are also welcome):
https://github.com/OpenChain-Project/Contribution-Process-Specification/issues

Here is what we have so far:

Review TODO Group's 'A Guide to Outbound Open Source Software’
#3

Review TODO Group's 'Employee Open Source Engagement Guide' with 'the six principles of open source engagement’
#4

Review The OSPO Alliance 'Good Governance Initiative Handbook’
#5

Review SAP’s Outbound Open Source Processes
#6

Meanwhile, our kick-off call to reiterate the approach and plan next steps is about to be scheduled, and after going through the process, will open with "Initial topics for discussion - tabled by Jimmy @ Ericsson to help initiate the practical discussion”:
#2

Regards

Shane

[shanecoughlan]

Our kick-off call for the contribution specification discussion is scheduled for:
2023-08-23 @ 00:00 PDT / 07:00 UTC / 09:00 CEST / 15:00 CST / 16:00 KST + JST

You will find the call in our global calendar:
https://www.openchainproject.org/participate

This will explain what processes the OpenChain Project uses to develop new specifications. It will then proceed to review the current ideas being fielded for a contribution process specification and discuss next steps.

Here is the overview of how we create specifications:
https://www.openchainproject.org/resources/faq#specification-development-questions

Here is the initial thread discussing the idea of a contribution process specification:
#1

Here is a link to the first topics for discussion:
#2

Here is a link to all open issues with items to review:
https://github.com/OpenChain-Project/Contribution-Process-Specification/issues