[Rust-VMM] Proposal for contribution and crate approval process

Matt Wilson msw at linux.com
Fri Mar 8 20:04:54 UTC 2019

On Wed, Feb 20, 2019 at 02:25:56PM -0600, Jonathan Bryce wrote:
> Hi everyone,
> On the rust-vmm community meeting this morning there was a
> discussion about the approval process for new crates. From the
> discussion a basic proposal emerged:

Hi Jonathan,

Thanks for writing this up, and for the infrastructure services from
OpenDev. I have some thoughts about this that I'd like to share after
a few disclosures:

1) I am an Amazon employee, and Amazon is contributing to rust-vmm
   through the efforts of other employees. I have an interest in how
   the rust-vmm community grows in that context.
2) I have not contributed code to rust-vmm, and I probably won't be
   able to participate in things like community calls due to my
3) My thoughts about how to foster open source communities that
   I'm sharing today are my own, and do not represent the views of my
   employer. Therefore I'm wearing my individual hat and sending this
   from my msw at linux.com email address.

> - Create a group of rust-vmm project-wide maintainers
> 	- Group size would start out with around 5 individuals
> 	- Maintainers should come from a variety of backgrounds and
> 	  affiliations
> 	- Inclusion of a new crate would require approval from at
> 	  least 3 maintainers
> 	- Maintainers should look for approval and feedback from
> 	  multiple “consumer" communities (e.g. qemu, crosvm, kata,
> 	  firecracker)

I think it is much too early to establish this level of process about
governance, number of maintainers, approval process, etc. Before
establishing rules like this, I encourage communities to have a
transparent discussion about exactly what problems they (as a
community) are trying to solve. Due to my understanding of the
intended nature of rust-vmm crates, as building blocks that can be
used in other VMMs, this community may embrace a more decentralized
approach with smaller numbers of contributors, and healthy forking of
projects if the needs of a "downstream" are not met in the "upstream."

There is no "one right way" to do open source. From past experience,
we know of many successful patterns, and many anti-patterns. I have
similar opinions about agile software development, and I encourage
teams to discuss what works the best for them, rather than prescribing
"you shall do agile development this way."

I have found the most accessible way to have these discussions is via
plain text email. Phone meetings and video conferences can be useful,
but there are challenges in scheduling due to timezones and competing
priorities. Additionally, they can exclude contributors that are
unable to participate in speech based conversations. I encourage this
emerging community to find what works well for the individuals who are
showing up to collaborate, but be aware of who you may be
unconsciously excluding.

> - As the number of crates scale, maintenance at the crate level
>   would be distributed beyond the project-wide group to avoid
>   overloading the project-wide maintainers or creating bottlenecks
>   within individual crates

I'm not sure what the overheads are here, having never done GitHub
organization management. Again, my suggestion is to get experience
with running the project before optimizing for a problem that might
not exist.

> I offered to write this up and post on the list to make sure
> everyone had a chance to see and comment on it, so please send your
> thoughts/feedback.
> If this is agreeable as a process, we’ll need to bootstrap the
> initial set of maintainers. I have thoughts on that as well, but
> would love to hear others’ opinions too.

The idea that bootstrapping maintainers to reach a critical mass does
not sit well with me. I would like to encourage a much more organic
approach where natural leaders emerge based on their contributions
establishing the direction and shared technology of a project.

Finally, while things like logos are helpful promoting your project,
it's probably not the first order of business. Nor is it the first
order of business to obtain additional services from foundations. When
I was a board member of Software Freedom Conservancy (of which QEMU is
a member), and part of the Evaluation Committee considering
applications to join, we established the following as part of the key
criteria [1]:

   * The project should have an existing, vibrant, diverse community that
     develops and documents the software. For example, projects that
     have been under development for less than a year or only a "proof
     of concept" implementation are generally not eligible.

Figure out who you are as a community, what problems you're trying to
solve, and how you want to interact with one another as
individuals. Creating a safe environment where people can collaborate
and earn trust of one another should be a high priority.

Make very intentional decisions here first. Experiment, double down on
what works, and re-evaluate when things don't. Discuss it intently on
a mailing list (... or don't, I do not have all of the answers here.)


[1] https://sfconservancy.org/projects/apply/

More information about the Rust-vmm mailing list