Looking through this, it's not immediately clear how these are meant to be used. It seems like this is less about the maturity level from the community's side, and more about what a company might put in their job description / evaluation / promotion model. Does that seem right?
[EDIT] Yes; from the linked article:
"Greg Kroah-Hartman said that the only way for developers to be able to work as maintainers within companies is for it to be a part of their job — something they will be evaluated on at the end of the year. This has to come from the top down, he said. Airlie answered, though, that maintainership can come from the bottom up as well; the DRM subsystem has a group review structure that requires developers to help review code. When the need arises, that makes it easy to pull developers up into maintainer roles. Chris Mason said that, at Facebook, maintainership is in the job description, and the company has had good success with that.
"Ts'o concluded the session by suggesting that this might be a topic for the Linux Foundation Technical Advisory Board to consider; perhaps the board could draw up a set of recommendations for companies." [1]
The item that I thought was interesting was this one from level 5: "Organizations shall actively seek out community member feedback as a factor in official performance reviews." Is the kernel dev community really volunteering itself as the target for a ton of big-corporate 360-degree annual performance review process feedback requests ? :-)
This already happens today at many companies. I write a few of these a year for companies that I do not work at, and have been for the past decade or so. It's not unusual and the companies that recognize that having their developers be a valued part of the overall kernel community is a very good thing to support.
Interesting. In the QEMU community I've never been asked for this kind of perf-feedback (with one exception in the last decade, which was related to a promotion case), and I don't think my fellow-developers would appreciate it if I passed on the request-for-feedback stuff my own employer's annual-review process includes. But if you're all happy to fill in those forms then I guess it works for you...
I think this is some advanced level tech-company-politics-jiujitsu.
The challenge is getting one or two companies to adopt it, then the CTO's of other companies will have to admit they are on "maturity level 1" when rival X is on level 3.
Its a neat idea.
My quibble is this would be a really good FOSS Maturity Model (ie contributions to OSS projects in general)
Yes, it's written considering companies with a formal yearly review process centered on cleary defined objectives. My guess is that it's supposed to be used as a guideline to help companies see how they are positionned with regard to kernel development but is somewhat strangely built to my management consultant eyes. It's a multi-axis analysis but they are not clearly stated. Well, I guess I'm not the intended target.
If what they want to do is outreach, they would be better with an additional assessment framework based on it but I think they intend to rely on companies goodwill.
8 comments
[ 3.2 ms ] story [ 25.0 ms ] thread[EDIT] Yes; from the linked article:
"Greg Kroah-Hartman said that the only way for developers to be able to work as maintainers within companies is for it to be a part of their job — something they will be evaluated on at the end of the year. This has to come from the top down, he said. Airlie answered, though, that maintainership can come from the bottom up as well; the DRM subsystem has a group review structure that requires developers to help review code. When the need arises, that makes it easy to pull developers up into maintainer roles. Chris Mason said that, at Facebook, maintainership is in the job description, and the company has had good success with that.
"Ts'o concluded the session by suggesting that this might be a topic for the Linux Foundation Technical Advisory Board to consider; perhaps the board could draw up a set of recommendations for companies." [1]
[1] https://lwn.net/Articles/870581/
The challenge is getting one or two companies to adopt it, then the CTO's of other companies will have to admit they are on "maturity level 1" when rival X is on level 3.
Its a neat idea.
My quibble is this would be a really good FOSS Maturity Model (ie contributions to OSS projects in general)
If what they want to do is outreach, they would be better with an additional assessment framework based on it but I think they intend to rely on companies goodwill.