Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Eclipse OS-Gov
We would like to create, publish, and standarize a best practices guide on Open Source Governance. Our intent is to work in an open, transparent and fully-collaborative set of text documents, and to submit this work to a standardisation body.
Eclipse OS-Gov defines a set of guidelines and best practices for the governance and management of open source projects. It covers a wide range of topics, from decision making and tooling, to communication and security, and provides good practices and recommendations gained from years of experience. It includes documents (Markdown or AsciiDoc) and the accompanying diagrams/visuals, with a few scripts to generate the various outputs (e.g. epub, pdf, html).
The Eclipse OS-Gov project provides guidelines and best practices for the governance and management of open source projects. Developed by recognised open source experts, it covers a wide range of topics, from tooling to communication and security. It only provides recommendations, as projects should adapt their practices to their own context.
We intend to develop these recommendations in a collaborative manner with the community, and publish various outputs (PDF, epub, HTML) freely available to everybody.
We would like to standardize the guideline and Eclipse Foundation has a relationship with standardisation bodies, strict IP checks, and a good experience with specification processes. Please note that we want to develop these guidelines in a similar way to a typical OSS project using Git and allowing transparency in regards to contributions.
We expect to complete the specification within 2 years.
Eclipse Foundation, Leadingbit Solutions, FOSET.org, OSI, ESOP
We are in the process of identifying previous contributions owners, and making sure we indeed are allowed to bring in some of the work done already. (consists of markdown files) Whatever the conclusion, we will quickly add some files in the repo and start filling them up.
- Log in to post comments
- Log in to post comments
Happy to be here
Submitted by Evan Leibovitch on Mon, 10/16/2023 - 12:11
Thanks to Silona, Boris and Tobie.
Glad to see the project restarted (tho there's no mention in the background of this project's roots...nothing to be ashamed of).
Looking forward to participating.
Re: Happy to be here
Submitted by Boris Baldassari on Thu, 11/09/2023 - 02:55
In reply to Happy to be here by Evan Leibovitch
Hi Evan,
Thanks for your kind comment. Regarding the origins of the project, there is definitely nothing to be ashamed of - but we wanted to play it safe regarding the use of names - and not point fingers as well. Have a wonderful day!
Re: Re: Happy to be here
Submitted by Joshua Gay on Sat, 03/16/2024 - 02:54
In reply to Re: Happy to be here by Boris Baldassari
Staff submitted a request to initiate a new open source project. The chair withdew.the request and made a series of statements explaining what the will od .the.
"This is not an open source project. We are not developing a software project published under an open source software license supporting the open source software definition for others to freely use or contribute to."
"The [WG name] work will always be copyright [ORG-NAME], all rights reserved, as it evolves to become an [ORG-NAME] published recommended practices. (There is no suggestion of even publishing that document under a Creative Commons license commonly used to publish document-centered works to encourage future collaboration.)"
And lastly, "None of us in the working group like bringing open source software licenses near documents in general (preferring more appropriate licenses like the CC family). Furthermore, we are intent on building an [ORG-NAME] standard and not an open source software project. No one in the working group is suggesting the recommended practices standard be licensed as open source software."
Needs to be the right fit.
Submitted by Joshua Gay on Sat, 03/16/2024 - 03:04
I think sharing helps. Especially when it is a group level decision. Staff submitted a request to initiate a new open source project on behald of the Working Group. The chair withdrew the request stating:
"This is not an open source project. We are not developing a software project published under an open source software license supporting the open source software definition for others to freely use or contribute to."
"The [WG name] work will always be copyright [ORG-NAME], all rights reserved, as it evolves to become an [ORG-NAME] published recommended practices. (There is no suggestion of even publishing that document under a Creative Commons license commonly used to publish document-centered works to encourage future collaboration.)"
And lastly, "None of us in the working group like bringing open source software licenses near documents in general (preferring more appropriate licenses like the CC family). Furthermore, we are intent on building an [ORG-NAME] standard and not an open source software project. No one in the working group is suggesting the recommended practices standard be licensed as open source software."
The WG wanted access to the ORG's gitlab, but didn't want to open source the.projects.
Ultimately the WG and ORG were a bad fit. The ORG could support Apache 2.0 projects on its GitLab-based platform. The ORG wasn't flexible enough with supporting non-open source licensed projects.