The Illusions and Truths of Participating in OSS Communities

As a part of AGL OSPO-EG activities, I published a slide deck explaining the misconception and reality of Open Source Contribution. There are 2 versions, English and Japanese currently, and translation contribution is appreciated.

Editable PowerPoint files are available at:
https://lf-automotivelinux.atlassian.net/wiki/spaces/OSPO/pages/397082627/Publications#OSS-Contribution---Illusion-and-Reality

Transcript

1. 1 The Illusions and Truths of Participating in OSS Communities v1.0, June 2025 Masanori Itoh, AGL OSPO-EG CC-BY-SA 4.0
2. 2 A Detailed Overview of OSS Contributions Various Aspects of "OSS Community Activities" and "Contributions" Even if you think "Is this really okay?”, it can still be considered a significant "contribution.” 1. Trying it out for the first time <Beginner> 2. Asking/reporting questions about unclear points, new behaviors, feature requests, etc., on mailing lists or forums <Beginner> • This also means "cooperating in testing“, and feature requests can also mean "introducing use cases.“ 3. Presenting at events <Intermediate> to <Advanced> • The level/content can vary, including introducing use cases, proposing new features and/or explaining structures, etc. 4. Reporting issues when you find bugs, strange behaviors or questions <Beginner> to <Intermediate> • Simply reporting the issue is <Beginner> while being able to analyze it is <Intermediate> 5. Fixing bugs yourself and submitting the bug fix patches <Intermediate> to <Advanced> 6. Publishing your research and development results or implementing new features to contribute <Advanced> 7. Participating in developer communities <Quite Advanced> 8. Reviewing submitted patches (so-called core dev) <Very Advanced> 9. Participating in the management of developer communities <Very Advanced> 10. Serving as the leader of a specific project <Very Advanced+> 11. Participating in the overall management of the community <Super Advanced> • Representatives in decision-making bodies like Technical Committees that are involved in the overall management.
3. 3 A Detailed Overview of OSS Contributions Various Aspects of "OSS Community Activities" and "Contributions" Even if you think "Is this really okay?”, it can still be considered a significant "contribution.” 1. Trying it out for the first time <Beginner> 2. Asking/reporting questions about unclear points, new behaviors, feature requests, etc., on mailing lists or forums <Beginner> • This also means "cooperating in testing“, and feature requests can also mean "introducing use cases.“ 3. Presenting at events <Intermediate> to <Advanced> • The level/content can vary, including introducing use cases, proposing new features and/or explaining structures, etc. 4. Reporting issues when you find bugs, strange behaviors or questions <Beginner> to <Intermediate> • Simply reporting the issue is <Beginner> while being able to analyze it is <Intermediate> 5. Fixing bugs yourself and submitting the bug fix patches <Intermediate> to <Advanced> 6. Publishing your research and development results or implementing new features to contribute <Advanced> 7. Participating in developer communities <Quite Advanced> 8. Reviewing submitted patches (so-called core dev) <Very Advanced> 9. Participating in the management of developer communities <Very Advanced> 10. Serving as the leader of a specific project <Very Advanced+> 11. Participating in the overall management of the community <Super Advanced> • Representatives in decision-making bodies like Technical Committees that are involved in the overall management. "Many people seem to equate 'contributions' with 'publishing new work,' but that’s just a small part of it (a misunderstanding and a bit of a myth). While publishing new work has a significant impact, aiming for that alone from the beginning is like jumping straight into commercial development without any prior validation. It's not something I’d recommend.
4. 4 A Detailed Overview of OSS Contributions Various Aspects of "OSS Community Activities" and "Contributions" Even if you think "Is this really okay?”, it can still be considered a significant "contribution.” 1. Trying it out for the first time <Beginner> 2. Asking/reporting questions about unclear points, new behaviors, feature requests, etc., on mailing lists or forums <Beginner> • This also means "cooperating in testing“, and feature requests can also mean "introducing use cases.“ 3. Presenting at events <Intermediate> to <Advanced> • The level/content can vary, including introducing use cases, proposing new features and/or explaining structures, etc. 4. Reporting issues when you find bugs, strange behaviors or questions <Beginner> to <Intermediate> • Simply reporting the issue is <Beginner> while being able to analyze it is <Intermediate> 5. Fixing bugs yourself and submitting the bug fix patches <Intermediate> to <Advanced> 6. Publishing your research and development results or implementing new features to contribute <Advanced> 7. Participating in developer communities <Quite Advanced> 8. Reviewing submitted patches (so-called core dev) <Very Advanced> 9. Participating in the management of developer communities <Very Advanced> 10. Serving as the leader of a specific project <Very Advanced+> 11. Participating in the overall management of the community <Super Advanced> • Representatives in decision-making bodies like Technical Committees that are involved in the overall management. These are excellent contributions to the community, and they also provide significant benefits to your organization/company.
5. 5 Points to Keep in Mind  As an employee  Ensure that no confidential information is included.  Present and share information by distilling it into technical generalities.  As a member of the (broader) community  Follow the appropriate time, place, and occasion (TPO) when presenting proposals.  When suggesting "new feature additions" or "modifications to existing feature specifications," thoroughly explain aspects such as "use cases (benefits, necessity, etc.)" and the validity of "specifications and design.“  Sending fixes (pull requests) abruptly without any explanation can be counter productive.  Consider relationships with communities in similar/related fields.  For "completely new tool publication“, building a network of collaborators is crucial.  Pay close attention to "licenses" and "terms of use”  Typically, documentation for these matters is prepared by each company's legal and intellectual property departments.
6. 6 Interim Summary Participating in OSS community activities is not difficult.  Even just reporting something like "Under these conditions..." or "Here’s an issue I’ve encountered" is a valuable contribution.  Many people (particularly in Japan) prefer to investigate thoroughly before reporting, but sharing problems or issues should be done quickly. By doing so, problems can often be solved with less effort overall, and holding onto an issue until you solve it yourself often results in more disadvantages than benefits.
7. 7 Points to Keep in Mind  As an employee  Ensure that no confidential information is included.  Present and share information by distilling it into technical generalities.  As a member of the (broader) community  Follow the appropriate time, place, and occasion (TPO) when presenting proposals.  When suggesting "new feature additions" or "modifications to existing feature specifications," thoroughly explain aspects such as "use cases (benefits, necessity, etc.)" and the validity of "specifications and design.“  Sending fixes (pull requests) abruptly without any explanation can be counter productive.  Consider relationships with communities in similar/related fields.  For "completely new tool publication“, building a network of collaborators is crucial.  Pay close attention to "licenses" and "terms of use”  Typically, documentation for these matters is prepared by each company's legal and intellectual property departments.
8. 8 Points to Keep in Mind  As a software engineer  Regarding development platforms such as Git (tools) and GitHub Write logs and comments in English. – Limit the use of local languages, such as Japanese, to multilingual support sections only Organizing commit logs (before submitting a pull request) – Do not combine multiple types of fixes into one large commit » For smaller fixes, it’s reasonable to address one issue per commit – Combine intermediate commits, such as typo corrections, into a single commit Provide sufficient explanations in commit logs, including links to related issues for example. Follow the project-specific conventions for rights declarations – For example, include "Signed-off-by:" to comply with the DCO (Developer’s Certificate of Origin) » https://developercertificate.org/
9. 9 Summary Participating in OSS community activities is not difficult  Let's approach things from familiar, practical levels