Hi Hart,

Made it to the end, thank you for the blessing! 😊

I agree with the general direction and would like to emphasize how important it is that the community size metrics be objective ones and also trustworthy. I separate those two because a Github repo could have a thousand stars, but no production users, if it was featured in the right place or somehow received enough attention (or maybe people just like the idea and give it a thumbs up even if they are not intending on using it).

In this sense GitHub is just like any other social media platform where seemingly objective metrics must be interpreted with a grain of salt => I heard the same rumor a number of times now that the average Silicon Valley venture capitalist will consider one github star worthy of 1500 dollars of investment money.

What gets measured gets managed. What gets managed gets distorted, almost by definition (not saying that anybody here or elsewhere had/have/will have any bad intentions at all, just that incentivization is a double edged sword).

One idea that I have (that I’ve seen done elsewhere a lot) is to for projects to open a survey asking “Who uses/planning on using the project and for what?”. People who are genuinely planning on or already are using the project usually pile in there with use-cases from money-backed/profitable companies and often times it results in a new “Who uses X” section of the project readme showing off company logos.

So, maybe we could consider this an item on the active checklist. It does have a chicken-egg problem with 1.0 releases being dependent on the active status itself since I couldn’t advise anyone with good conscience to adapt a project while it hasn’t had it’s first official stable release yet. Which brings me to my next idea:

Maybe labs should be free to issue major/stable releases before they reach active status and we could find some other way to label the releases as active/incubation.

What I’m saying in a longwinded way I guess is that changes may be necessary, but we should take extra care not to “lower the bar” while fixing/optimizing the process.

I’m deeply involved in one of the labs projects so it would be convenient for me to support anything that gets our project faster to active status, but when we get there I want that active status to still mean the same thing, a certain level of guarantee to would be users that the project can be integrated into their stack with confidence.

In other words, I don’t (and nobody should) mind working hard for the active status, but a predictable, transparent, easy to understand process/metrics is very much appreciated (not saying the current process is not all of these things, just that more of it is welcome).

Another random idea: Could also help to add more statuses to avoid the binary good/not good, in/out feel and the human emotions that come with them.

I’ve seen in real estate investment that projects can have phases like ramping up, stabilizing, operating which immediately tells you what can you expect if you get on board at any one of those stages. Not saying we need exactly those, just something to consider as well.

Peter

Peter Somogyvari

OOO: Dec 18 - 31

Workshop: -

Technology Architect

Accenture Products & Platforms | Technology & Engineering CoE

Office: - | Mobile: 650.488.1741