\n
![](\"https:\/\/plus.maciejpiasecki.info\/wp-content\/uploads\/2023\/05\/Wordpress-1-1024x536-1.png\")
\nSource: opensource.org <\/p>\n","protected":false},"excerpt":{"rendered":"
Building a healthy Open Source community is much more than just choosing an Open Source license for the project. It involves creating a contributing guide, adopting a code of conduct, and establishing an open governance structure that allows all members to actively participate in and contribute to the project.
\nThis article provides a hands on guide on how to establish an open governance structure for an Open Source project. In fact, I\u2019m currently in the process of proposing an amendment to the existing charter of the ClearlyDefined\u00a0project, and this article will highlight what steps are being taken to make this process as smooth as possible.
\nJust to give some background, ClearlyDefined was originally developed by Microsoft\u00a0and it was donated to the Open Source Initiative\u00a0about 5 years ago. Microsoft still plays a key role in the project, but is seeking external contributors. Several individuals and companies have demonstrated interest in helping with ClearlyDefined, but as of now there\u2019s no clear guidelines on how these contributors can play a role in the governance of the project. At ClearlyDefined there is an interest in receiving contributions from other organizations, but the governance structure that exists today does not provide any incentives for organizations to contribute.
\nI recently joined\u00a0the ClearlyDefined project as a Community Manager, and one of my first steps was to reach out to several community members to understand their needs and desires. Besides scheduling calls with these members online, I also had the opportunity to attend the first ever ORT Community Day. The OSS Review Toolkit (ORT) is a Linux Foundation project that is currently being used by several organizations for managing Open Source supply chain compliance and security, and is one of the key projects that currently makes use of and promotes ClearlyDefined. It was in talking with the community face-to-face that I identified the clear need for an open governance model.
\nMy second step was to conduct research about open governance models for Open Source projects. I identified several good resources, probably the most important being The Open Source Way 2.0, a comprehensive guidebook created by Red Hat and several prominent Open Source leaders. It\u2019s also worth mentioning the GitHub Open Source Guide, which provides a good summary of open governance. There\u2019s also a more recent article published by the CNCF, Outlining the structure of your Open Source software project, which provides a good explanation of how to structure an Open Source project based on its maturity level.
\nMy next step was to study the different charters and by-laws from projects that are part of the same ecosystem as ClearlyDefined. We don\u2019t want to create something from scratch, but seek inspiration from adjacent projects that already exist:<\/p>\n
ORT Governance
\nOpenSSF Charter
\nSPDX Governance
\nFOSSology Governance
\nOpenChain Charter
\nCNCF Charter
\nTodo Group Charter
\nEclipse Foundation Bylaws<\/p>\n
And finally, it was time to start making some suggestions of changes to the existing ClearlyDefined charter. This is a very delicate process, because everything has to be very well justified. Let\u2019s go over each section of the charter:
\nMission
\nThe original mission is very generic. The mission is not \u201cclearly defined\u201d:<\/p>\n
Help FOSS projects be more successful through clearly defined project data.<\/p>\n
So let\u2019s make it more specific and inspiring:<\/p>\n
ClearlyDefined\u2019s mission is to create a global database of licensing metadata for every Open Source software component ever published.<\/p>\n
Principles
\nThe original principles are rather good, so we left them unchanged:<\/p>\n
Neutral \u2013 The project carries no affiliation or company driven focus;
\nOpen \u2013 The data, infrastructure, and processes are open to all;
\nFactual \u2013 All data is factual. No interpretation or assessment is made;
\nUpstream \u2013 Enable upstream projects as much as possible;
\nSimple \u2013 Wherever possible the project will use the simple solution.<\/p>\n
The community has asked for more open data, for example, and that\u2019s already addressed here. We just need to follow our principles.
\nScope
\nThe original scope was overly ambitious, and aimed to address security, accessibility, among other issues:<\/p>\n
ClearlyDefined will pursue any data that makes FOSS projects easier to consume and thus more successful. Initially this work will focus on licensing data that form the core of understanding and meeting the legal obligations related to using FOSS. This includes: License (declared and observed); Copyright holders; Source location (including revision\/commit).
\nWhy? The FOSS licensing and security information landscape is vast and varied. Projects without clear metadata are harder to adopt and so get fewer contributions and lower engagement \u2013 they enjoy less success. On the consumer side, enormous effort is required to discover and comply with licensing obligations and track security issues. Even simple things like the location of the source for a component can be painful to find. These ambiguities mean that FOSS cannot be consumed with confidence. This affects the success of FOSS projects. We want to break this vicious cycle.
\nWhat? Crowdsourcing the curation of licensing, security, accessibility data for FOSS projects. First clear licensing data. Later, clear security, accessibility data.
\nHow? Harvesting data embedded in projects, curating the data in an open and collaborative process, contributing clearly defined project data back to the FOSS projects, and making the data freely and easily accessible. A virtuous cycle.
\nFuture efforts will focus on further topics such as: Security \u2013 facilitating the reporting and tracking of vulnerabilities in projects; Accessibility \u2013 Characteristics and analysis of a project\u2019s support of accessibility related technology and concerns; Project data\u00a0\u2013 Governance model, principals, issue tracking, discussion forums, \u2026 The ordering of this work and effort applied will depend entirely on the community and their interests.<\/p>\n
Let\u2019s reduce the scope and focus on licensing metadata. Security, accessibility and project data are also important, of course, but there are other initiatives that are already working on these, so let\u2019s collaborate with them.
\nThis is the proposed scope:<\/p>\n
ClearlyDefined will focus on licensing metadata that form the core of understanding and meeting the legal obligations and security best practices related to using Open Source software. This includes: License (declared and observed); Copyright holders; Source location (including revision\/commit).<\/p>\n
Motivation
\nIn the original charter, the motivation (Why?) was part of the scope section. Let\u2019s break the motivation into a separate section to make things clearer. Also, let\u2019s rephrase the motivation, making it shorter and more concise:<\/p>\n
With the move towards SBOMs (Software Bill of Materials) everywhere for compliance and security reasons, organizations will face great challenges to generate these at scale for each stage on the supply chain, for every build or release.
\nAdditionally, multiple organizations will have to fix the same missing or wrongly identified licensing metadata over and over again.
\nThis is where ClearlyDefined comes in, by serving a cached copy of licensing metadata for each component through a simple API.
\nOrganizations will also be able to contribute back with any missing or wrongly identified licensing metadata, helping to create a database that is accurate for the benefit of all.<\/p>\n
Processes
\nIn the original charter, under governance, it described the project processes and community roles. But governance addresses how a system works on a higher level, and that\u2019s entirely missing from the original charter. So let\u2019s create these 3 sections: processes, community and governance.
\nThe processes section remains mostly the same:<\/p>\n
The continuing goal of ClearlyDefined is to help originating projects craft and maintain clarity around their in-scope data as a native part of their operation. Where that is not possible, the project will maintain the relevant data. This is viewed as a fork of the upstream project and, like code forks, should be minimized. Either way, the project serves as a one-stop-shop for the in-scope data making life easy for consumers.
\nThe project undertakes four main operations in support of the stated goals and scope: Harvesting data embedded in projects; Curating the data in an open and collaborative process; Contributing clearly defined project data back to the FOSS projects; and Making the data freely and easily accessible.
\nThese processes are further described below.
\nHarvest
\nHarvesting is the act of getting data from upstream projects. This may be as simple as reading prescribed data from canonical locations to full-on analysis of the source code using a variety of open tools. The discovered data is stored in its entirety in its native form in the ClearlyDefined infrastructure and made available to the community on demand. The harvesting tools themselves are always fully open and accessible to the community for vetting and inspection. The project is open to including new tools subject to a vote, as described below.
\nHarvesting may be run by the ClearlyDefined project itself or by designated parties, typically curators. In all cases, only output from agreed-upon tools and configurations will be admitted to the system. Harvesting operators are free to focus on a given domain of projects that best suit their expertise and interests.
\nCurate
\nThe curation process is fundamentally open and transparent. Curators (aka project committers or maintainers) work on harvested data, data contributed by the ClearlyDefined community, and with the origin project artifacts and community to validate presented information. All deliberations, discoveries and discussions are recorded and made available for community inspection.
\nInitially this workflow will happen in one or more GitHub repositories using standard Pull Request workflows on human-readable and diff-able curation artifacts. The project may develop additional tools to supplement or supplant this flow but will always ensure full transparency.
\nAs with committers on typical FOSS projects, curators are free\/expected to focus on particular domains that fit their interests and expertise.
\nAt least initially, all curated data must be signed off by two curators. This is more in the interest of working through thought and mechanical processes and developing a common understanding of the data and determining what is admissible. This requirement may be removed through a vote, as described below.
\nContribute
\nHaving curated data about a project, ClearlyDefined community members will seek to contribute the data upstream in a form most attractive to the receiving project. Given the anticipated scale of this effort, some automation will be used but with a sensitivity to spamming projects with pull requests. These contributions will include information supporting the inclusion and ongoing maintenance of the curated data.
\nProjects accepting the curated contribution will be deemed ClearlyDefined (see Badging below) and will no longer need curation. Validations will continue but by opting into this program, the projects are endeavoring to effectively self-curate the data.
\nServe
\nRegardless of whether projects are self-curating or externally curated by ClearlyDefined, as a service to the consuming community, the ClearlyDefined project serves up the harvested and curated data both through programmatic (e.g., REST) APIs and through browsable web properties. The raw harvested data as well as the summarized and curated is made available through both access methods.<\/p>\n
Community
\nThe community section remains mostly the same as well:<\/p>\n
Roles
\nData Curator
\nA data curator is akin to a project maintainer or committer in typical Open Source projects. Curators have write permissions to the curation repo(s) and are ultimately responsible for admitting data to the curated store. A curator is more librarian and data scientist than lawyer or developer. The role requires enough domain context to enable issue identification and resolution. The role also requires technical expertise in running the various tools used to detect and analyze components. Each curator must be, and be seen to be, vendor neutral and unbiased. This helps them in their other key role \u2013 working with upstream projects to incorporate the curated data into the original project.
\nAs with committers and maintainers, curators are nominated and approved by the project community based on their merits and prior contributions. The role of curator relates to an individual, not an organization or a position in an organization. Under no circumstances is a curator held responsible for any errors or other flaws in the data merged into the service.
\nData Contributor
\nA ClearlyDefined data contributor is like a contributor on any other Open Source project \u2014 they identify bugs or improvements, fork the repo and contribute a pull request with their changes. For data contributors this could be a small change (e.g., spelling correction), a substantive change (e.g., identifying the license for a component), or wholesale data definition (e.g., providing data for a previously unknown component). Contributors should, as with any other project, expect to substantiate the changes with background information and proof of correctness.
\nA serial contributor of quality data is a candidate to become a curator.
\nData Consumer
\nA ClearlyDefined data consumer accesses the curated or harvested data. They understand that the data is provided as-is with no guarantees or warranties as to the correctness of the data or is suitability for any particular purpose. All data is fully qualified as to its origin and any clarifications made and it is up to the consumer to use the data, or not.
\nCode Committer\/Maintainer
\nWhile ClearlyDefined is focused on data, the project will develop a modest amount of code. Code committership is independent of data committership. As such, code committers are elected by a vote of the existing code committer community as described below. Code committers have complete control over and responsibility for the operation of the harvesting, curation and serving infrastructure of the project.
\nRemoval from role
\nIn the unlikely event that a committer or curator becomes disruptive or falls inactive for an extended period of time, they may be removed from the role though a unanimous vote of the remaining set of committers or curators.
\nVoting
\nMost decisions within the project can be done through informal consensus and recorded in the appropriate public record. When a formal decision is required, for example, when electing committers\/curators, a vote is held using the following process: A topic for voting is tabled by a curator by notifying all other curators; Once tabled, curators may vote during an open voting period lasting no less than one working week. Voting will occur on an agreed to, mutually convenient, and open medium (e.g., email, GitHub issue, etc.); A minimum of two positive (+1) votes and no negative (-1) votes carries the topic. Note that negative votes must be substantiated; Abstention (0) votes do not affect the outcome.
\nRecognition and promotion
\nThe project may, from time to time, run programs that recognize and reward the efforts of a project to become and remain ClearlyDefined. For example, a badging program would enable eligible projects to show they are ClearlyDefined, thus increasing consumer confidence. Such recognitions may be made relative to a specific domain such as licensing or security, or in relation to the overall ClearlyDefined effort.<\/p>\n
Governance
\nAnd finally, let\u2019s describe the governance model. This section is entirely new, and was inspired by the governance models of other adjacent projects from the same ecosystem:<\/p>\n
Governing Board
\nThe Governing Board voting members shall consist of: the Executive Director of the Open Source Initiative, the Steering Committee Chair, and the Outreach Committee Chair.
\nThe Governing Board responsibilities consist of:
\n\u2013 setting the overall strategic direction of the ClearlyDefined project, establishing main goals and identifying key priorities in accordance with feedback and input from the community;
\n\u2013 managing the resources of the ClearlyDefined project in a responsible and sustainable manner, including budget, infrastructure, and human resources;
\n\u2013 adopting and maintaining policies or rules and procedures for the ClearlyDefined project, such as a Code of Conduct and a trademark policy and any compliance or certification policies.
\nSteering Committee
\nThe Steering Committee shall be responsible for:
\n\u2013 setting the technical direction of the ClearlyDefined project, establishing main goals and identifying key technical priorities;
\n\u2013 overseeing all processes (harvest, curate, contribute, serve), ensuring that the underlying architecture enables these processes to run smoothly;
\n\u2013 empowering the community (data curator, data contributor, data consumer, and code committer\/maintainer), providing all the technical support necessary to achieve ClearlyDefined\u2019s mission;
\n\u2013 establishing open collaboration with adjacent projects that are part of the ecosystem.
\nOutreach Committee
\nThe Outreach Committee shall be responsible for:
\n\u2013 planning and executing efforts to promote the ClearlyDefined project to potential users and contributors;
\n\u2013 organizing activities across events worldwide, both virtual and in person, to bring together existing community members and attract new ones;
\n\u2013 creating educational material (documentation, whitepapers, webinars, podcasts, etc) to help individuals and companies understand how to use and contribute to the ClearlyDefined project;
\n\u2013 managing communication across different channels (website, blog, social media, and press releases).
\nMembers and Chairs
\nThe Steering and Outreach Committees are made up of community members with a sustained contribution over time, and recognized as interested in the long term health of the ClearlyDefined project. Members of the Steering and Outreach Committee recommend and appoint new members and vote for a Chair for each Committee to serve for a one-year term. Members will be removed from the committee if they resign or if they are inactive in participating and contributing to the project for more than 6 months.
\nMeetings
\nGoverning Board meetings will be limited to the Governing Board members. They will be private unless decided otherwise by the Governing Board, as sensitive matters may not be made public. The Governing Board may choose to hold open, community meetings at its discretion.
\nSteering and Outreach Committee meetings should be held periodically (monthly or fortnightly) and are intended to be open to the public. They can be conducted electronically, via teleconference, or in person. The chair for each Committee should set the agenda ahead of time and preside over the meetings. The meeting minutes should be published and shared with the community through public channels.
\nVoting
\nWhile it is the goal of the ClearlyDefined project to operate as a consensus based community, if any decision requires a vote to move forward, the members of the Governing Board, Steering Committee, or Outreach Committee, as applicable, shall vote on a one vote per member basis.
\nDecisions by vote will be based on a majority vote, provided that at least sixty percent (60%) of the Governing Board, Steering Committee, and Outreach Committee members, as applicable, are either present, participating electronically or via electronic vote (e.g., such as by email, or in a form as specified by the board materials) in advance of the meeting.
\nA two-thirds majority vote will be required for any vote amending this Charter. Amendments will be communicated to the community through public channels, and will take effect immediately.<\/p>\n
Clearly defined governance
\nNow the final and crucial step is to engage with all the stakeholders and ask for their feedback again. The initial feedback is what drove the changes to the charter in the first place, and we want to make sure that the changes proposed addresses the concerns from the stakeholders.
\nWe want to avoid discussing these changes and making decisions behind closed doors. We should try to do everything we can to make the process as open and as transparent as possible from the very beginning.
\nBy establishing a clear and open governance model, our hope is that ClearlyDefined will become more welcoming towards contributions from individuals and organizations, not just in terms of code or data contributions, but also contributions that will help govern the project itself.
\nIf you are interested in learning more about ClearlyDefined and how to get involved, please visit our website\u00a0and discord.<\/p>\n
Image from ktasimarr via Canva.com<\/p>\n
The post <span class=’p-name’>What Is Open Governance? Drafting a charter for an Open Source project<\/span> appeared first on Voices of Open Source.
\n
\nSource: opensource.org
<\/p>\n","protected":false},"excerpt":{"rendered":"
Building a healthy Open Source community is much more than just choosing an Open Source license for the project. It […]<\/p>\n","protected":false},"author":57,"featured_media":12464,"comment_status":"false","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-12463","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mp"],"_links":{"self":[{"href":"https:\/\/plus.maciejpiasecki.info\/index.php\/wp-json\/wp\/v2\/posts\/12463","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/plus.maciejpiasecki.info\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/plus.maciejpiasecki.info\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/plus.maciejpiasecki.info\/index.php\/wp-json\/wp\/v2\/users\/57"}],"replies":[{"embeddable":true,"href":"https:\/\/plus.maciejpiasecki.info\/index.php\/wp-json\/wp\/v2\/comments?post=12463"}],"version-history":[{"count":1,"href":"https:\/\/plus.maciejpiasecki.info\/index.php\/wp-json\/wp\/v2\/posts\/12463\/revisions"}],"predecessor-version":[{"id":12465,"href":"https:\/\/plus.maciejpiasecki.info\/index.php\/wp-json\/wp\/v2\/posts\/12463\/revisions\/12465"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/plus.maciejpiasecki.info\/index.php\/wp-json\/wp\/v2\/media\/12464"}],"wp:attachment":[{"href":"https:\/\/plus.maciejpiasecki.info\/index.php\/wp-json\/wp\/v2\/media?parent=12463"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/plus.maciejpiasecki.info\/index.php\/wp-json\/wp\/v2\/categories?post=12463"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/plus.maciejpiasecki.info\/index.php\/wp-json\/wp\/v2\/tags?post=12463"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}