Proposal for Project Adoption Criteria

[dalemyers]

One of the most common questions being asked currently is along the line of "Is my project suitable for being adopted by the foundation?" Answering that is a very difficult question, but this proposal outlines some basic criteria which could be used to help make a decision. The list is not exhaustive, nor is it definitive, and at the end of the day the committee get to make the final decision. These criterial will continue to evolve and adjust as the foundation continues to develop.

1. The project should be open source and under a permissible license

This one seems obvious, but no candidate should be considered unless it is open source and covered by a license which is suitable for the foundation directly (or can be re-licensed in such a way that it is suitable).

2. There should be a community interest in the project

What does that mean? It means that the project should be relatively well known within the community, and used by a significant proportion of it. There should be a desire to keep the project alive and functioning for the community.

3. There should be a suitable scope for the community

Some projects solve very specific problems that only one or two teams/companies face. These do not make good candidates for ownership. Instead, these projects should solve problems that a significant part of the community face.

4. The project should be non-trivial

There are many projects which meet the other criteria, but are only a few dozen lines of code and trivial for anyone to replicate. These are usually not suitable candidates for adoption.

5. The adoption should serve a purpose

Projects should not be donated "just because". There should be a reason behind the adoption. That may be that it is a popular project that your team/company/etc. can no longer maintain for some reason; that the foundation can steer it in a direction better suited to the community than your own team/company can; etc.

6. The project should be "production ready"

This means that the code should be of a high quality, documentation should exist and be clear and available, the README should cover any details that are relevant, there should be deployment/usage instructions, a comprehensive test suite should ideally exist, etc.

7. The existing maintainers should ideally want to continue in that role

If the project is actively maintained, then the existing maintainers being able to commit to continuing that role would be preferred. The foundation does not currently have resources to take over development, and so depends on the community. It serves no one for the foundation to adopt a project and for it to then be ignored.

---

As a reminder, these criteria are not exhaustive, nor are they absolute. This is merely a proposal that we can use to start evaluating the existing ecosystem. Over time, I'd expect this to evolve to follow the model used by the Cloud Native Computing Foundation. For now though, it's useful to have a base set of guidelines.

[keith]

Thanks for starting this conversation, sorry it has taken me so long to jump in here.

1. The project should be open source and under a permissible license

+1, note that by default Apache-2.0 is the only "accepted" license, although the TSC can vote to allow projects with other licenses.

2. There should be a community interest in the project

I definitely agree here, although I do think it's a bit hard to measure

5. The adoption should serve a purpose

This is definitely the most nuanced feeling issues with projects coming in. I think the non-company-specific ownership is a huge benefit, as we often see projects getting orphaned as the single employee maintaining it switches jobs. I think there's some small benefit here where, if they want to, the employee can maintain some amount of ownership over the project even if they leave the company.

6. The project should be "production ready"

I think we could probably be relaxed in the case, depending on the case. One example that comes to mind is there is a hope that there is a community driven bazel Xcode project generator collaboration, and I think a project like that could make sense to be kicked off within the foundation.

7. The existing maintainers should ideally want to continue in that role

+100, I definitely don't want the impression to be the foundation becomes a dumping ground for abandoned projects. Although I do think this gets tough in the case of already orphaned projects that are hoping to move to the foundation to get some new steam behind them, but I think we can probably handle that case by case.

[dalemyers]

Yeah, I think all of this is extremely nuanced and should be handled on a case by case basis. The intent is that nothing I've written here should be taken as gospel, but instead should serve as guidelines. If something doesn't mean one or two criteria, probably fine. If it misses a bunch, probably not.

[ileitch]

Apologies if this is already noted somewhere - I had a look through the Charter and some discussions, but haven't found anything concrete. Why would an open-source project consider adoption into the foundation? What problem is adoption attempting to solve?

[keith]

Totally fair question, I think it was mentioned a bit in the announcement blog posts, but IMO there are a few potential reasons:

• Shared community ownership, while it might be great for your company's image to open source some project, depending on the stewardship of it, it may not really "feel" like an open source project when a single company holds all the keys to the castle. In this case, practically speaking, it's unlikely for a company to give external access to folks, so having it instead owned by the foundation can allow it to be a more of a community driven project, ideally making way to it being more-adoptable by others since it de-risks the chances of it going an entirely different direction. Theoretically the foundation could fork things to the same effect, but given how github disincentivizes that, and to not split the community in general, donation feels like a much more reasonable path
• Remove single points of failure, this is related to above, but quite often realistically even though a company open sources a project, there's a single individual who owns it, and drives it (likely in this case they're also the only person who knows how it works). When they then leave the company, they aren't really incentivized to continue maintaining it (even if the company would be willing to let them) since they don't really feel like they have much ownership over it. By moving it to the foundation the original author can maintain ownership over the project regardless of whether or not they work for the company that authored it, ideally leading to fewer orphaned projects. Of course the author also may not want to continue maintaining the project, at which point the foundation owning it also has the benefit of being able to find new maintainers outside of the original company as well if there's enough community interest in keeping it alive (which ideally there is otherwise it likely shouldn't make it to the foundation in the first place as mentioned above)
• Community standardization, in my example above of a bazel based Xcode project generator, one of the reasons folks are potentially excited about a shared effort that is community owned is ideally it can be the last implementation of something like that. Today there are about 3 of these tools floating around in open source, and many companies implemented their own internal versions, so there's a lot of duplicate effort. Ideally a project being in the foundation, and the benefits of community ownership, can mean we can standardize on one solution, and stop duplicating our work across the industry.

[ileitch]

Thanks Keith. As the author of a project potentially suitable for adoption (Periphery) this is certainly something for me to consider. I'd say at this point the benefits appear much more clear from a company's perspective, but perhaps a little less so from an independent author's. These are still early days for the foundation however, so I imagine further benefits may be realized as it matures. I'm excited to see the growth of the foundation, and the projects that may opt for adoption over the coming months.

[jschear]

👋 The technical steering committee spent some time iterating on these criteria and I've put them up for review here: MobileNativeFoundation/foundation#12 Thank you @dalemyers for the initial proposal!