Statistics from the 4.7 development cycle

Interesting perspective given that there exist(ed?) spesific outreach program for women <--- ( not everyone and if that's still ongoing but does not mention women specifically those behind that great idea have changed it to "minority" because that's "better" ) anyway knowing the history of women in the kernel would still be interested to me ( at least ) since it's gone quite daunting seeing more or less the same stats, listening to the same people question the same people with the same questions which gets answer the same way or the same people giving the same talk based on the same material year after year.

Even Linus Linux X.X-rcX announcements have repeated pattern in them. yada yada small/big, yada yada driver updates, yada yada go test <shortlog> with occasional yada yada vacation in them. He should have his wife or kids ( or someone else ) write the announcements to break up that pattern for a bit.

> "I don't use my boobs to program, so it shouldn't matter if I have them"

It shouldn't, but for many it does. Ignoring that reality doesn't solve it.

> Stopping the cycle of self-selection by permeating the stereo type of the socially inept, white male geek as the only type of people who suit a programming career/hobby is a much more practical use of time.

Evidence doesn't really suggest that the stereotype is the problem here - there are far more women in almost every avenue of professional computing than there are in the kernel. While it is a problem that women are outnumbered by men in the field at every stage of the education and career ladder, those numbers alone don't explain why our community is so disproportionately bad. Very few women enter Linux development, and retention of those that do is abysmal. One demonstrated way of increasing representation in communities is to have more role models, and outreach programs are an excellent way of achieving that.

But you're right that focusing on women isn't the only part of this, which is why the focus of projects like Outreachy is now on minorities in general. We should recognise all minorities who are involved despite social pressure making that more difficult, but we should also look at individual groups to determine whether specific strategies are working more effectively or are unintentionally excluding others.

> People often ask for country-based statistics as well. It would all be interesting to know

There are some statistics here : http://www.remword.com/kps_result (look at NT:Nation by Patch).
But apparently the site was not updated since November 2015 :-(

>The lack of contributions from academia have been an interesting problem for years. There are guesses as to why (once the work has gone far enough to be published it stops and there's no incentive to polish it for inclusion, for example), but nobody really seems to know what the roots of it are.

Perhaps academia is also focusing on solely academic kernels, since a kernel that does not have to deal with all the pitfalls of real world hardware is a lot easier to work on when you're trying to implement a proof-of-concept feature, though that's just a guess of mine. Someone (with access to comp sci publications) would have to actually dig through all the papers to find out where the work ended up.

It could also be very possible that some company or individual then re-implements the work in an upstreamable shape after reading the paper, which would mean academic contributions are still very much real, just not as direct. Searching the kernel git log for the word "paper" brings up some commit messages where people mention work to be published in a paper and such.

There was a fairly recent study [1] done on pull request and their acceptance in opensource projects on github that showed that women's contributions tend to be accepted more often than men's but only was the women's acceptance rates higher when they are not identifiable as women.

This raises the question if the same thing might apply to the kernel community.

1. https://peerj.com/preprints/1733/

> The lack of contributions from academia have been an interesting problem for years.

As said in the article kernel is boring and academia needs hot and sexy. Also kernel is likely old OS technology so nothing really novel fit for research.

The roots should be obvious to anyone who's been in academia: There is no reward to an academic in getting stuff upstream. Indeed, resources spent cleaning and polishing code for upstream - past the point of having gotten it working enough to get the results for ones' papers - are resources that are *diverted* away from working on the next academic paper, and hence cleaning up and polishing code for upstream inclusion can *damage* ones' academic career.

Academics can not fix this alone. One would need to go to the governments' and government agencies funding CS work and make the case to have factors other than paper output considered as success criteria in funding applications, in departmental assessments, in career progression, etc. Now, the relevance of "Impact" (i.e. real-world effects of research) in academia has slowly become more important to funding agencies - academics do often now have to pay some attention to this in funding applications - however it seems generally still to be a side-line performance metric compared the traditional measure of papers (weighted by venue).

> The lack of contributions from academia have been an interesting problem
> for years. There are guesses as to why (once the work has gone far enough
> to be published it stops and there's no incentive to polish it for inclusion, for
> example), but nobody really seems to know what the roots of it are.

How is "academia" tabulated on the list? I try to contribute regularly (but possibly not during the 4.7 timeframe) using my .edu address. Would all people with .edu be tabulated under academia, or would we be individually broken out by our University?

The main problem with academia are threefold:
1. Most academic code contributions are *awful*, generally one-off hacks made during a mad rush to get a paper/thesis out the door
2. There are no incentives to merge your results back in (i.e. federal grants and such don't stipulate this, and really outside of google I'm not sure if there's anyone who is sponsoring linux-kernel related reserach grants), and also open-source contributions don't matter for anything on tenure packages.
3. There's a perception (probably rightly so) that trying to get code merged in is going to be a long, frustrating process. Often by the time the student has finished the work and it's time to contribute back, the student has graduated, moved on to a new job, and has no incentive or time to deal with the hassle.

So most of the people I know from academia who contribute back are ones who (like me) were open-source developers first, academics second. And the fact we bother trying to get things contributed back probably hurts our career both financially and timewise.

It's possible that some of the academic contributions are showing up as industrial ones even when done by the academics - at Linaro we're currently working with Paolo Valente on BFQ which was work he originally did in an academic context and is now upstreaming with support from us. Due to the way it's being funded he is contributing from a Linaro account and shows up that way but the core of the work is academic.

Thanks for never forgetting the privacy issue. However, the key point is not the data, but the treatment you do with it.
So, what would we do with this information and the associated statistics? I am not sure we can do something useful (to either gender) with the result.
Similar for countries.