LWN: Comments on "Some notes from the Collaboration Summit"

IBM: Rewards for pushing things along

Sho — Thu, 29 Apr 2010 18:52:35 +0000

> To that end, IBM has reworked things internally to reward developers who have managed to push things forward, even if somebody else's code gets merged in the end.

That sounds nifty. Is there any more information on how exactly IBM does this? How do they quantify "pushing things along", other than looking at signed-off-by and reviewed-by tags?

Some notes from the Collaboration Summit

neilbrown — Tue, 27 Apr 2010 05:28:31 +0000

> Andrew Morton raised an interesting related issue: as the core developers gain experience and confidence, they are happy to put code of increasing complexity into the kernel. That could indeed make it harder for new developers to come up to speed; it might also not bode well for the long-term maintainability of the kernel in general.

I think this is a real issue. We may be more confident, but I don't think we are more intelligent and there is a risk of over-reaching ourselves.
It reminds me of the well known quote:

> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it? ~Brian Kernighan

Fortunately we seem to be growing a useful collection of tools to help with debugging, but I think there is a real need to make things simpler too. Not necessarily less functional, but more elegant and transparent.

Android & Linux

martinfick — Sun, 25 Apr 2010 02:05:09 +0000

Google is not really an embedded developer, that is not whom they should be compared to. And if they were compared to embedded developers, they haven't done that bad, they have released their hardware specific drivers and even attempted to get them upstreamed.

But, they should actually be compared to a new distribution with a radically different approach to system design than other distributions. So, in this sense, if they do not upstream, they should be held accountable just like any other distribution. After all, Ubuntu got their share of complaints for this same reason not too long ago. And, at this, google has failed, they built new kernel infrastructure without community involvement and they expect this infrastructure to be used in newer roll outs. This is not a case of simply dumping support for a low volume device.

Being a large and a high profile company may not be a very strong reason to expect them to lead. But, since their "distribution" is high profile, and they are attempting to lead with this distribution, it surely seems justifiable to expect them to upstream the infrastructure required by this distribution or receive flack for not doing so.

Android & Linux - people

ndye — Fri, 23 Apr 2010 12:58:31 +0000

<blockquote>We pick [sic] a vendor a day, provide some analysis of their contributions, and easily come up with similar pros and cons of their interaction with the community.</blockquote>
A useful exercise indeed.
<blockquote>Anyway, if other vendors' compliance is basically only motivated by their competitors adherence to open source philosophies, well, then the whole thing is just a house of cards isn't it?</blockquote>
The FLOSS "house of cards" is, IMHO, the dependency on people getting along well enough to achieve a shared objective:
<ul>
<li>Someone has to articulate a worth shared objective.</li>
<li>Someone has to point the way for the team to achieve it.</li>
<li>Someone has to point out how the team can do better.</li>
<li>Someone has to encourage people to do right.</li>
<li>Someone has to discourage people from doing wrong.</li>
<li>There's more, and that's an understatement.</li>
</ul>
The hard work of "herding cats" is even more difficult for us who excel at studying things instead of people:   People don't appreciate being the object of being debugged (being poked repeatedly), and the process fails because people don't react reliably.
I'd think that hardware engineers should be better at it than software engineers:   I'm recalling an old Dr. Dobb's letter to the editor that described a (KGB-stolen or West-rejected?) computer that didn't always get 4 when adding 2 and 2, yet a Soviet computer engineer stuck with the job was able to tease out the circumstances that led to its failure modes and code up a program that reliably provided correct output.   Sounds just as difficult as debugging people.
And let's recall why Linus started his Minix replacement, via <a href="http://groups.google.com/group/comp.os.minix/msg/b5fb8c03...">Google</a> (fancy that):
<blockquote>[Linux] uses every conceivable feature
of the 386 I could find, as it was also a project to teach me about the
386.</blockquote>

Android & Linux

njs — Fri, 23 Apr 2010 04:33:40 +0000

I'm not sure what they're being high-profile has to do with anything... it seems to me that they should be especially pressured to push stuff upstream because, 1) they have gajillions of dollars and huge kernel experience, they know better and have no excuse, and 2) unlike most embedded systems, we're not just talking about a few hacked-together drivers for a one-off device, we're talking about a widely distributed fork of the kernel and its userspace ABI.

Android & Linux

AndreE — Thu, 22 Apr 2010 11:06:22 +0000

Those companies wouldn't know too much about Google's contribution if it wasn't constantly brought up. And if the attitude was slightly less biased against Google, it certainly shouldn't have been as news-worthy as it was. At the very least, the depth of the of discussion about Google in particular rather than non-compliance or non-conformity IN GENERAL seemed quite unbalanced. We picked a vendor a day, provide some analysis of their contributions, and easily come up with similar pros and cons of their interaction with the community.

Anyway, if other vendors' compliance is basically only motivated by their competitors adherence to open source philosophies, well, then the whole thing is just a house of cards isn't it?

Ax-sharpening

ncm — Thu, 22 Apr 2010 07:28:34 +0000

The additional information exposed here (thank you LWN!) demonstrates that the upstreaming problem really is a management problem. If Google management were to set aside a meaningful fraction of time in the schedule to negotiate upstream inclusion, the development team would be doing it. Google should also be letting contracts with upstream developers to help them absorb the influx. This isn't just for the kernel; Chrome notoriously forks the libraries it depends on, too.

The ax-sharpening metaphor is excellent.

Android & Linux

nevyn — Wed, 21 Apr 2010 22:51:34 +0000

> Yet, in a meritocracy, the level of your profile shouldn't matter.

Sure, if you assume all people are robots and won't be affected by other people/company actions. But that's not true. One problem is that if the biggest/richest/etc. embedded developer says "sorry, we're too busy working to bother upstreaming" then it sends a giant red flag up for all the managers at the smaller embedded developers who will start asking "wtf are we wasting time on upstreaming, when google don't".

You _really_ want those questions to be asked the other way around, so you have to do whatever it takes to make the largest "DTRT" ... so that you don't have to have the same battle with 666 small companies.

Speaking as a non-kernel developer who bought an unlocked Nexus One, and is currently happy with Chris's comments that they just need to hire more people to get it done, and are in the process of doing that.

Android & Linux

AndreE — Wed, 21 Apr 2010 12:20:17 +0000

Yet, in a meritocracy, the level of your profile shouldn't matter. Surely open source is all about meritoracy ("show me your code"), and to single one vendor out on the basis of their media profile (slamming Google always draws a crowd) if there truly are a large number of worse vendors seems to be against that spirit

Lack of young people involved in kernel development?

chantecode — Tue, 20 Apr 2010 22:30:01 +0000

In this article arises the question of the loss of young people involved in the kernel development. Ok the problem has been half broken already in the arguments, as you noticed: in fact these people are there already.

Being one of them, I pay attention to such folks. Even if the age doesn't appear to their email headers, you just figure it out :)
They are here in different ways, knocking for time to time, hesitating or being radically involved, depending on the degree of their shyness and experience. And they are here everywhere: arch/, kernel/, drivers/, mm/, etc...

And there are very promising people among them. In fact the real problem is not "how to attract fresh blood", it's rather "how to keep them" and how the community should behave in this regard.

Android & Linux

man_ls — Tue, 20 Apr 2010 22:21:54 +0000

Well said. Google has the money, the talent and the goodwill to make it work; they should be the ones setting the way and serving as an example to others, not be caught dragging their collective feet.

Android & Linux

vonbrand — Tue, 20 Apr 2010 20:27:11 +0000

Yep, it's hard being the most visible part of the pack... and so you attract most of the flames.

Some notes from the Collaboration Summit

mjg59 — Tue, 20 Apr 2010 15:18:39 +0000

And thanks to the people from Google for taking the time out to do this!

Some notes from the Collaboration Summit

Trelane — Tue, 20 Apr 2010 15:05:29 +0000

Plus you probably want to get your intended bi-directional flow going *before* development systems have ossified.

Some notes from the Collaboration Summit

Trelane — Tue, 20 Apr 2010 15:04:34 +0000

Glad to hear you got together in meatspace. The problem with online discussions is that it's far too easy to misread something written online, and it's far too easy to hate on someone if you don't have to be physically near them.

Hooray for understanding! :)

Some notes from the Collaboration Summit

lmb — Tue, 20 Apr 2010 14:05:09 +0000

There's absolutely no question that Android developers are doing great things, and Chris is also right that "building a community" always takes some time.

Yet, one wonders how much of this is a "I can't sharpen my axe, I'm too busy felling trees" argument. If no resources are spent on making Android more accessible and easier to accept contributions from the community (note: I am _not_ talking about upstreaming their own work!), the gulf widens all the time, and if the community would be able to contribute even only 5% of the work on bug fixes and features (a not very aggressive estimate), this is now work the Android core team has to do themselves or it doesn't get done. So, the platform loses out and the spiral works downwards.

This is Google. It's not as if they'd be hard pressed to put a team of 1-5 engineers on it to work on improving community interactions, accepting contributions (and perhaps help them get it right), and improving the bi-directional code flow.

And it might be a good way to identify and recruit new talent. This seems to be something Google is willing to invest quite a bit on, so maybe spin it like this? ;-)

Some notes from the Collaboration Summit

swetland — Mon, 19 Apr 2010 22:30:40 +0000

I'd like to say thank you to Jonathan and the other "mainline Linux" folks we (the Android Systems Team) chatted with last week at the Collaboration Summit. It was good getting a bunch of people together face to face, discuss various things, make some headway on figuring out how to work together, and hopefully we'll do this again at future Linux conferences. Also a big thank you to Ted T'so who worked to organize the meeting.

- Brian

Some notes from the Collaboration Summit

smoogen — Mon, 19 Apr 2010 21:58:13 +0000

Maybe Google needs to start a "Summer of Code Management projects". Students work on getting various code bits into upstream projects and learn the love/hate that code submissions have.

Android & Linux

pj — Mon, 19 Apr 2010 21:38:36 +0000

I think the Android guys probably do draw more fire than they really deserve, but at least part of that is the price you pay for being high profile. Personally, I see it as more of 'tough love'; the kernel guys are saying "C'mon, we know you can do better! Live up to your potential! We *want* you to succeed, and you're not going to do that if you keep on as you are!"