The Secure Production Identity Framework For Everyone (SPIFFE) Project defines a framework and set of standards for identifying and securing communications between application services. You can read more about it at the README.
You may be interested in contributing a project to SPIFFE in order to:
- Fill some technological or use case gap
- Enhance UX for operators of a SPIFFE solution such as SPIRE.
- Build on top of one or multiple existing solutions as a unique offering or other possible motivations.
We are grateful for your desire to expand the SPIFFE ecosystem with your contribution!
This is an evolving set of guidelines and instructions for how to bring your existing project, or idea for a completely fresh project, under the SPIFFE organization.
If your project is already under the SPIFFE banner, you may be looking for MATURITY instead.
Maintainer groups are given significant freedom in managing their projects to that we may best foster growth and innovation. There are some elements of SPIFFE subproject ownership to be aware of:
- The SPIFFE Steering Committee (SSC) governs the SPIFFE organization as a whole, and has the final authority on acceptance, rejection, or eviction of projects. Additionally, as stewards of community health, the SSC is responsible for intervening in any Code of Conduct violations or derelictions of maintainer responsibility.
- Note that when contributing a project to SPIFFE, its purpose becomes to serve the SPIFFE community rather than any personal gain. Additionally, we expect a sufficient number of maintainers for a project as it grows, not all of whom may bring the same direction you may originally have had in mind.
Carefully consider this change in control and purpose.
Every SPIFFE project at minimum must follow the SPIFFE Code of Conduct.
The SSC can be contacted with proposal details at ssc@spiffe.io or in the #ssc channel of SPIFFE slack.
The following details are expected for proposals to help us best understand how the project will serve the community.
Additionally, the information here make great initial README.md, CONTRIBUTING.md, and GOVERNANCE.md files for the repo!
The list of initial maintainers of the project, including GitHub handle.
What need is the project solving for the community? What problem exists or what enhancement will this create?
What is the direction of the project? This is similar but distinct from the purpose of the project.
While the purpose highlights the "Why" and "What" of the project, the direction should be about the "How". This could include- Vision:
- What specific pain point does the project address?
- What does "done" mean for the project? What is the idealized vision for the shape of the project? What are the milestones to complete for each level of maturity?
- What notable features or options are in-scope or out-of-scope for the project? This especially will help differentiate your project from any similar ones that might already exist.
- What are the current workarounds or alternative solutions, and why are they inadequate?
- How does your project align with SPIFFE's overall mission and goals?
- Who are the primary end-users or beneficiaries of this project?
Direction:
- What is the project’s roadmap for the next 6-12 months?
- What are practices or styles that will be encouraged or discouraged?
- How will the project scale? What are the scalability goals?
- Are there any legal or ethical considerations?
- What are potential challenges, and how do you plan to overcome them?
- What kind of community involvement do you foresee (e.g., are there opportunities for novice contributors, or is the project more suitable for experts in the field?)
- What technologies will the project leverage, and are they aligned with the larger ecosystem?
- How will the project maintain data integrity, security, and privacy?
- Are there any possible collaborations with existing SPIFFE projects?
- How will your project deal with failure scenarios or fallbacks?
It's ok if there's not fully fleshed-out answers to each of these, and projects evolve over time. However the more information that can be provided the more easily SSC may understand the proposal, and the more confidence there will be in alignment amongst the maintainers.
The operations of the project.
- How will maintainers be added or removed? What is the goal number of maintainers?
- How often will the maintainers meet?
- How will maintainers interact with contributors and review their Pull Requests and Issues? Slack? Dedicated online meetings? What is the goal turn around time?
- What conflict resolution mechnisms will the maintainers follow? (e.g., allocated debate time? Majority vote? Unanimous vote for certain topics? What is the SLO for resolution?)
Do similar projects already exist actively within the SPIFFE community? If so, what makes this project sufficiently unique to justify any overlap?
Do similar projects exist outside of SPIFFE that can better help us understand the project's value?
Has this project existed in the past but was abandoned or closed out? What is different in today's world?
The SSC will work with you to schedule a review of the proposal. Ideally all initial maintainers would be present in that review. Anyone not present should at least sign off on the proposal so that we know there is a unified commitment.
The SSC will bring up any concerns around the proposal, but overall we aim to accept proposals that serve even a subsection of the community as long as there is confidence that the project will be healthy.
The SSC meets regularly, and will do its best to come to resolution within a couple sync cycles. Acceptance of a new project into the community is a significant decision, and your patience is appreciated.