On Classifying Projects and Communities (definitions, shared vocabulary) #1219
Replies: 2 comments 2 replies
-
|
As someone who supports our projects and development, I strongly disagree with this model for project classification. "Toys" and "Clubs" are perjorative terms. The model also ignores the fact that projects grow and change. Further, I need to ask what the goal of doing this kind of classification is. How does it help our users? How does it benefit the projects themselves? The tools we build should have outcomes in mind. We have a classification system around project lifecycle, which is our matriculation model. Any additional classification should take that into account -- and help enable project advancement. |
Beta Was this translation helpful? Give feedback.
-
|
this is kind of where I was going with: cncf/tag-contributor-strategy#64 many moons ago agree that toys and clubs might not be the best terms but I think that projects can come and go out of these categories based on growth and investment. thats the point of categorizing them because they have different needs at different cycles and stages. those needs translate into governance changes, community infrastructure changes, etc. And, we've spent the last n decades arguing and comparing projects communities and problems that might look closely related but in actuality they are different. Nadia's book really hits this home. A community categorization to pair with a maturity level creates a level of understanding about a project that users and contributors can make decisions on/about without digging into the weeds. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, your proposal is why I was already familiar with the book and the model. If the CNCF Landscape has taught us anything, it's that the number of ways you can classify projects exceeds the number of projects we have. For this reason, any system that puts projects in a reductive number of groups is necessarily going to be an exercise in pigeonholing -- and if some of those categories are considered more desireable than others, a contested exercise. Classification is only useful to the extent that it can lead to useful and informed action. Engbal's 4-category classification, while quite useful for the purpose it's described in the book, would not be helpful for the CNCF*. It also ignores the work we've already done to tag projects, between the matriculation levels and the governance types, to say noting of the Landscape. Adding another, completely orthagonal, taxonomy is just going to confuse people, users and developers alike. (* for example, it's quite useful for the individual project owner, in private, to realize that their project is a "toy", because they can stop trying to build a community around it, at least until something unexpectedly changes. However, if the CNCF classifies a CNCF project as a "toy", that's quite a different matter.) |
Beta Was this translation helpful? Give feedback.
-
|
This may be worth bringing to TAG CS for additions to Cloud Native Glossary |
Beta Was this translation helpful? Give feedback.
-
On Classifying Projects and Communities
spawned from: #1210
The model described below might be a useful way to help TAG's, OSPO's, CTO’s, TOC's, technical leaders, contributors, and users as they determine which projects to use in their solutions and platforms. It can help us as a TAG co-chair community to make clear our assessment(s) of OSS projects and their communities' cohorts, interdependence, health, sustainability, and safety. All of these activities are facilitated by a shared vocabulary. I've found what's outlined in the "Working in Public" [very orange] book to be an accessible model. I would like us to explore this topic further, discover prior art, and to gather additional input, models and ideas. Let's learn about what's working in practice.
I can't recall which talk it was @ KubeCon in Chicago (someone help me, it's killing me that I can't place it) but a reference was made to the "Gang of Four" book, Design Patterns. When I first read this book, it was in the context of my first job as an engineer, and I was a few months in. What I love so much about KubeCon is the sharing of ideas en masse. Hearing that reference dislodged a bit of happy memory, happily!
The shared vocabulary we learned about together made everything else we built possible. I propose that if we collaborate and come to consensus around such a shared vocabulary for our domain, it will allow us to more effectively understand and help each other. One could imagine that increasingly the projects we'll have the opportunity to learn about, assess, and engage with will span TAG's.
Healthy software teams win together. When an extended team pulls together towards a major release, the endgame is AWESOME when folks that finish early have the opportunity to devote cycles to helping others. This fosters cross-pollination, builds and strengthens relationships between [otherwise and oftentimes siloed] people. This is only possible with shared language and processes. The lack of these can yield lonely journeys.
Please share your thoughts and comments.
apart from the diagram, what's below is reproduced from "Working in Public," by Nadia Eghbal (https://press.stripe.com/working-in-public)
Types of Projects, Contributors, and Communities
Project Types
The upper right quadrant (Federations) have the highest user and contributor growth, while the lower left quadrant (Toys) have the lowest of both measures.
Federations
Stadiums
very low maintainer to user ratio.
Unlike Federations and Clubs, which exhibit decentralized communities, Stadiums typically have a centralized community topology.
Often enjoy large, sometimes federated user communities and groups, oftentimes replicated and segmented by geography. .
Clubs
Toys
Project member types
Maintainers
Maintainers are those who are responsible for the future of a project's repository (or repositories), whose decisions affect the project laterally. Maintainers can be thought of as "trustees" or stewards of the project.
Contributors
Contributors are those who make contributions to a project's repository, ranging from casual to significant, but who aren't responsible for its overall success.
Active Contributors
(aka "regular" or "long-term" contributors) are considered members of the project, based on their reputation, the consistency of their contributions, or in many cases by explicit declaration from the project's governance mechanism(s) or via fiat.
Casual Contributors
Also known as drive-by, reactive, or passive contributors. Often motivated by interests of self or employer, commonly presenting with a transactional engagement style.
Users
Users are those whose primary relationship to a project's repository is to consume or use its code [and/or artifacts].
Active Users
Frequently self-identified in ADOPTERS.md or via other declarative mechanisms, and captured in case studies and whitepapers as part of project collateral. Historically (and more generally) a project's maintainers don't have a way to identify users, an expectation shared by Users.
Passive Users
On project member type mobility and fluidity
TODO: Contributor Ladder, and its utility as a signal type.
TODO: Reference and/or link to tag-contributor-strategy docs
Contributor Cohorts (Segmentation)
What's "Cohort Analysis?"
(source: https://en.wikipedia.org/wiki/Cohort_analysis)
n-th Time Contributors
Reputation Index
This is problematic if not done transparently. We might consider generating a number of indices and considering their utility in practice.
Project Metrics, Measures, and Attributes
These form part of a picture, but taken alone, in isolation, or without local, project specific context they are in practice often misunderstood. I’ve expanded on this here:
https://medium.com/@halcyondude/on-measuring-developer-productivity-9a81a50175da
For all given points in time, aggregated by cohort(s) or other dimensions (never by individual):
Beta Was this translation helpful? Give feedback.
All reactions