Open Jimmy-ahlberg opened 1 year ago
Call on 2023-10-17 reviewed.
We need to check globally (non-English) what terms can work better.
Our discussion indicates "contribution" is too loaded, and by narrowly defining it we would be excluding current real-world cases (project contribution policies and so on). Creating issues, sending comments can also be regarded as contribution.
Outbound open source process may work, but can it be understood, and would it need qualifiers for inbound? "if there is an outbound guide, where is the inbound guide?"
tl;dr: contribution seems too wide as a term, outbound is narrower, but would need further examination to ensure clarity. It appears to require further adjustment.
Caution required: this discussion easily veers into "how" rather than "what," and our mandate is to cover "what."
I raised a similar Reference Material Issue regarding contribution and consumption definition. Here is my proposal of a definition mapped to upstream and downstream activities of an Open Source Program. This may be too prescriptive for the standard, but hopefully provides context for discussion.
Open source consumption refers to the use and benefit derived from open source software or projects. It involves individuals or organizations utilizing software, applications, or other resources made available under open source licenses. Open source consumption allows users to:
Open source contribution involves actively participating in the development, improvement, and maintenance of open source projects. This can include:
Open source contribution is a collaborative effort, often undertaken by volunteers or organizations that believe in the principles of open source software. It is a way to give back to the community, improve software for everyone, and ensure the continued development and success of open source projects.
Thank you @shanecoughlan for the updates! Made some comments to your summary below:
Call on 2023-10-17 reviewed.
We need to check globally (non-English) what terms can work better.
Our discussion indicates "contribution" is too loaded, and by narrowly defining it we would be excluding current real-world cases (project contribution policies and so on). Creating issues, sending comments can also be regarded as contribution.
In the TODO Outbound OSS Guide, the community defined Outbound as " how to contribute to or launch open source projects (also called “outbound open source”)"
Outbound open source process may work, but can it be understood, and would it need qualifiers for inbound? "if there is an outbound guide, where is the inbound guide?"
We had the discussion that organizations usually understand the "Inbound" process, and is usually well implemented. However, the main blocker goes into the "Outbound" side. I would say that, despite the two guides being useful, prioritizing the efforts on what is more demanded by the participants contributing to this specification, would a good path to follow (?)
tl;dr: contribution seems too wide as a term, outbound is narrower, but would need further examination to ensure clarity. It appears to require further adjustment.
Caution required: this discussion easily veers into "how" rather than "what," and our mandate is to cover "what."
@shanecoughlan on a side note and regarding your previous comment on "We need to check globally (non-English) what terms can work better." At least in Castilian Spanish, there is no widely used translation to "Outbound Open Source" AFAIK, but it does for "Open Source Contribution" (Contirbución a código abierto) and "Release of Open Source Projects" (Lanzamiento de proyectos de código abierto)
graph LR
subgraph External OSS
ContributionUp(Contribution)
ConsumptionUp(Consumption)
end
subgraph External OSS
ContributionDown(Contribution)
ConsumptionDown(Consumption)
end
OpenSourceProgram((Open Source Program))
ContributionUp ---|Downstream| OpenSourceProgram
ConsumptionUp ---|Inbound| OpenSourceProgram
OpenSourceProgram ---|Upstream| ContributionDown
OpenSourceProgram ---|Outbound| ConsumptionDown
Downstream Contribution: Downstream contribution is the proactive engagement in enhancing, fixing, or extending an external open source project upon which an organization depends. It typically involves code contributions and collaboration, aimed at improving the external project for the benefit of the community.
Inbound Consumption: Inbound consumption involves the passive use and integration of existing open source solutions into an organization's projects. It includes leveraging preexisting software components and libraries without active involvement in development, while also contributing to the broader open source ecosystem.
Upstream Contribution: Upstream contribution involves actively participating in the development of an external open source project, typically by submitting code changes, enhancements, and collaborating with the project community to benefit the wider open source community.
Outbound Consumption: Outbound consumption refers to an organization actively sharing its own open source software, repositories, or projects with the broader open source community. It involves creating and maintaining publicly accessible code repositories, contributing to the open source ecosystem.
Notes
Inbound Consumption
have been previously defined in ISO 5230 training slides Chapter 4 - How do you want to use a Open Source component?Inbound Consumption
and Outbound Consumption
already have a more broad term of MaintainerThe convergence of terms for contributing original material vs. contributing to a running project (not owned by self or company) has been a struggle for us, too. What about "original contribution" and "supporting contribution"? the "outbound" part is not really needed since that is already implied in the word "contribution".
@jacobdjwilson, it's not clear to me what the difference is between Downstream Consumption and Upstream Consumption. Outbound Consumption the way you describe it doesn't make sense to me because you are contributing it, not consuming it.
Hi @ContiMary 👋 You are correct the meaning of Outbound Consumption is not within the context of your Open Source Program but rather providing Open Source to the community for others to consume. A bit confusing I know, but if the diagram had additional Circles for all of our Open Source Program(s) it would connect together and be an Open Chain. 😄
Some of the helpful language in the definitions I provide are passive and active contribution. If you have downloads on your OSS that's outside consumption, and Issue Tracker and PRs would be considered contribution made to your OSS that was from upstream consumers making contributions.
It might make more sense to consolidate to inbound/outbound OR upstream/downstream rather than using both.
In various offline discussion in for example Open Source Summit Europe in Bilbao, it seems we do not have a perfect alignment on how we define "Contribution".
I would have defined contribution as an ""Outbound" delivery of an "Organizations" proprietary copyrighted material, with the intent to have accepted into a existing body of work under an open source license. "
This purposely does not include spinning up new projects, as this at least to me is a very different process with other considerations.
I understand not everyone defines contribution in this way, thus perhaps we should either define contributions so that we are all talking about the same thing, and/or rename the work as "outbound open source process" if that is a more accurate description of what we try to do.