docs: mandate public adopters list for growth stage projects#5
Conversation
I would like to propose adding a requirement for projects to publicly list their adopters, but I suggest we place this in the Growth stage rather than waiting until Graduation. My thinking here is that bringing this transparency forward in the project lifecycle offers three major benefits for our ecosystem: * Lowers Adoption Hesitation: Transparency of adoption is an essential trust signal for prospective users. By showcasing real-world use earlier, we can help eliminate the hesitation enterprises feel when evaluating new software. * Increases Trust through Transparency: Publicly showcasing adoption proves that these are widely accepted standards, which encourages more providers and integrators to join and helps us circumvent market fragmentation. * Enables Easier Open Collaboration: When it is public knowledge who is already using the project, it becomes much easier for maintainers to communicate with them. As we note in our foundation goals, real-world adoption and feedback raise the quality and reliability of the entire stack for everyone. This places virtually no technical burden on developers but will significantly aid the TAC in proving the early success of our initiatives. Signed-off-by: David Sterz <opensource@davidsterz.de>
| ##### Acceptance Criteria | ||
|
|
||
| The TAC has not yet defined requirements for the Growth Stage. | ||
| * The project must maintain a public list of project adopters for at least the primary repository (e.g., via an ADOPTERS.md file or prominently displayed logos on the project website). |
There was a problem hiding this comment.
The "primary" repository is undefined. I believe since we anyhow request a web presence (https://github.com/neonephos/guidelines-development/pull/5/changes#diff-d581ac8f08d67c132fa72c8c07f2b40c58ad6d723a299c43784623b3a08b9256R57) we could make them force adoption there?
On top of this I believe we need to define very clearly what adoption means, and at which point a project counts as adopted (I believe you have something correlated in a separate pr here #4)
There was a problem hiding this comment.
IMO, this should be a SHOULD requirement for all projects. We can define the specifics in the project guidelines to be more flexible. The policy may elevate it to a MUST for projects in the Growth and Graduated stages.
There was a problem hiding this comment.
Excellent points from both of you. I completely agree.
@jakobmoellerdev - You are absolutely right about 'primary repository' being ambiguous.
That phrasing was actually inherited from the original June 2024 NeoNephos policy, but in today's multi-repo ecosystems, it doesn't make much sense.
What about dropping 'primary repository' entirely and replacing it with something like a 'public and centrally accessible location.' - probably we can find a better wording here ;)
This gives projects the freedom to put it on their website or in a central .github or community repo without splitting hairs over which code repo is "primary", also this can change over time pretty fast.
@fmui - I completely second this. Now that we are about established the baseline adopter counts (#4) for both stages (2+ for Growth, 5+ for Graduated), it is a somehow mechanical necessity that both stages maintain this public list so the TAC has the evidence they need for their evaluations.
To resolve both concerns, I propose to update the PR to apply to both stages, using the following refined and unambiguous language:
Growth Stage (Acceptance Criteria):
The project must maintain a public list of project adopters in a prominent, public and centrally accessible location (e.g., via an ADOPTERS.md file in a central community repository or prominently displayed logos on the project website).
Graduated Stage (Acceptance Criteria):
The project must maintain a comprehensive public list of project adopters in a prominent, public and accessible location (e.g., via an ADOPTERS.md file in a central community repository or prominently displayed logos on the project website) to facilitate the TAC's formal due diligence and adopter interviews.
Would you agree this wording clears up the ambiguity and align also with our almost consensus on adopter metrics?
There was a problem hiding this comment.
I do not get why we split this over two PRs that are obviously closely related. Let's close this one and add the content in #4. From my point of view, it does not make sense to discuss this separately.
There was a problem hiding this comment.
Excellent points from both of you. I completely agree.
@jakobmoellerdev - You are absolutely right about 'primary repository' being ambiguous.
That phrasing was actually inherited from the original June 2024 NeoNephos policy, but in today's multi-repo ecosystems, it doesn't make much sense.
What about dropping 'primary repository' entirely and replacing it with something like a 'public and centrally accessible location.' - probably we can find a better wording here ;)
This gives projects the freedom to put it on their website or in a central .github or community repo without splitting hairs over which code repo is "primary", also this can change over time pretty fast.
@fmui - I completely second this. Now that we are about established the baseline adopter counts (#4) for both stages (2+ for Growth, 5+ for Graduated), it is a somehow mechanical necessity that both stages maintain this public list so the TAC has the evidence they need for their evaluations.
To resolve both concerns, I propose to update the PR to apply to both stages, using the following refined and unambiguous language:
Growth Stage (Acceptance Criteria):
The project must maintain a public list of project adopters in a prominent, public and centrally accessible location (e.g., via an ADOPTERS.md file in a central community repository or prominently displayed logos on the project website).
Graduated Stage (Acceptance Criteria):
The project must maintain a comprehensive public list of project adopters in a prominent, public and accessible location (e.g., via an ADOPTERS.md file in a central community repository or prominently displayed logos on the project website) to facilitate the TAC's formal due diligence and adopter interviews.
Would you agree this wording clears up the ambiguity and align also with our almost consensus on adopter metrics?
Another possibility for having a list of adopters could be an example from the IoT world within the Eclipse Foundation: https://iot.eclipse.org/adopters/
Just as an idea.
From my POV, it is not "just" a criteria for the current project stage, it is also a marketing instrument. ;-)
There was a problem hiding this comment.
I think thats another good use of the Adopters once identified and and approved to use "their" logo / reference on the NeoNephos website once we aligned on the definitions (when to should and when to have an adopters, and under which criterias this is considered as an adopter #2 .
I can foresee valid concerns from companies to be listed with their name, and we definitely don't want to penalize a project just because an enterprise legal team won't approve a public logo release.
Since our main goal with the ADOPTERS.md file is to build trust and demonstrate real-world momentum rather than create marketing hurdles, what if we compromise by allowing anonymized, descriptive listings?
For example, projects could list:
"A Tier-1 European Telecommunications Provider"
"A German Automotive Manufacturer"
Maintainers could simply verify the actual identities privately with the TAC to maintain the list's integrity.
Would updating the PR to explicitly allow "TAC-verified anonymous adopters" be a workable solution for everyone?
And in addition we could combine this with the good idea from @ScheererJ in #2 - #2 (comment)
There was a problem hiding this comment.
I do not get why we split this over two PRs that are obviously closely related. Let's close this one and add the content in #4. From my point of view, it does not make sense to discuss this separately.
@ScheererJ Yep, meanwhile I agree with you as we started discussing the criterias of the ADOPTERS.MD , the initially (as written in the introductional text) was only to have ADOPTERS.md already in growth stage.
Proposal:
As we seem to agree on this (having ADOPTERS already in growth stage) we close this and continue in #2
There was a problem hiding this comment.
While I understand that some entities might not want to be listed on an adopters page, from my point of view, it is not helpful to do anonymisation there. If an entity does not want to be listed let's not list it. It is too easy for projects to claim anything with anonymisation.
| ##### Acceptance Criteria | ||
|
|
||
| The TAC has not yet defined requirements for the Growth Stage. | ||
| * The project must maintain a public list of project adopters for at least the primary repository (e.g., via an ADOPTERS.md file or prominently displayed logos on the project website). |
There was a problem hiding this comment.
I do not get why we split this over two PRs that are obviously closely related. Let's close this one and add the content in #4. From my point of view, it does not make sense to discuss this separately.
5 participants
I would like to propose adding a requirement for projects to publicly list their adopters, but I suggest we place this in the Growth stage rather than waiting until Graduation.
My thinking here is that bringing this transparency forward in the project lifecycle offers three major benefits for our ecosystem:
This places virtually no technical burden on developers but will significantly aid the TAC in proving the early success of our initiatives.