Skip to content

docs: mandate public adopters list for growth stage projects #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dsterz wants to merge 1 commit into
base: main
Choose a base branch
from
+1 −1
Open

docs: mandate public adopters list for growth stage projects #5

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion lifecycle-policy/project-lifecycle-policy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -127,7 +127,7 @@ Projects in the Growth stage are generally expected to move out of the Growth st

##### 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).
Copy link
Copy Markdown
Member

@jakobmoellerdev jakobmoellerdev Mar 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Copy Markdown
Contributor

@fmui fmui Apr 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Author

@dsterz dsterz May 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown

@ScheererJ ScheererJ May 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

@ariexi ariexi May 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. ;-)

Copy link
Copy Markdown
Author

@dsterz dsterz May 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Copy Markdown
Author

@dsterz dsterz May 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown

@ScheererJ ScheererJ May 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


##### Approval Process

Expand Down