Neary: The Cost of Going it Alone [LWN.net]

On his blog, Dave Neary has written up the notes from a talk he gave at the Desktop Summit on the costs of working with community to get code upstream vs. the costs of not working with the community. The article (and talk) have several real-life examples of those costs. "To avoid missing out on this work, it's recommended to merge regularly changes from upstream into your local copy of the upstream package. But this merge is typically not free — and the bigger your changes, the more likely it is you will find significant conflicts between upstream and your local copy. There is also an additional, often-forgotten overhead involved with regression testing and validation post-merge. Every time I upgrade a component to a new version, I need to verify that it hasn't broken anything, either because of changed behaviour at integration points I'm using or simply because some regressions were introduced when fixing other issues."

(Log in to post comments)

Neary: The Cost of Going it Alone

Posted Sep 2, 2011 11:29 UTC (Fri) by sumanah (guest, #59891) [Link]

Do check out the comments on his piece, where people are recommending related papers and talks. My own The Second Step: HOWTO encourage open source work at for-profits might be of interest.

Dave's examples include GCC, GTK+, and the Linux kernel. How do the costs of going it alone vary either as you move up the stack or move to smaller upstream communities?

Neary: The Cost of Going it Alone

Posted Sep 2, 2011 13:51 UTC (Fri) by marduk (subscriber, #3831) [Link]

I thought it was a good write-up. I'm going to sound a bit negative when I say this, but some of the "realities" make it seem like one has to have a core developer in one's pockets (either financially or otherwise) for a good chance of having a merge upstream accepted. To me, this seems more like a good ol' boys network than an actual meritocracy (as sometimes free software world is claimed to be).

Neary: The Cost of Going it Alone

Posted Sep 2, 2011 13:54 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

Meritocracy doesn't mean that everyone's patches has a equal chances of getting merged in. If you are a experienced contributor with a history of contributions to that project, it certainly helps accelerate development.

Neary: The Cost of Going it Alone

Posted Sep 3, 2011 7:14 UTC (Sat) by rodgerd (guest, #58896) [Link]

In an actual meritocracy, it would mean that everyone's patch is indeed accepted on its merits. The minute the "history" of the contributer comes into play you are, in fact, heading down the good ol' boys path.

Neary: The Cost of Going it Alone

Posted Sep 3, 2011 8:17 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

If that is your assertion, then your ideal form of meritocracy simply does not exist anywhere in the real world. Patches are accepted on merits but history of contributors is certainly a factor. A very important one for major patches. People want to know this person will correct bugs found in the code etc.

Neary: The Cost of Going it Alone

Posted Sep 3, 2011 9:29 UTC (Sat) by niner (subscriber, #26151) [Link]

There may be a misunderstanding of the word "meritocracy" here.

If I may quote Wikipedia on this:
"Meritocracy, in the first, most administrative sense, is a system of government or other administration (such as business administration) wherein appointments are made and responsibilities are assigned to individuals based upon their "merits", namely intelligence, credentials, and education,[1] determined through evaluations or examinations."

And especially with regard to Open Source:
"Technically, the more proficient the developer is in contributing towards the project - developing new features or maintaining existing code - the more they are required or the more the project necessitates their contribution, and thus the more senior their informal position becomes. Those who contribute more code, and have more of an effect on the direction or status of the project, will tend to have more seniority and influence."

So it's the developer's merits, not the individual contribution's that count. This is at least how I've always understood the word.

Neary: The Cost of Going it Alone

Posted Sep 2, 2011 15:38 UTC (Fri) by pabs (subscriber, #43278) [Link]

Not everyone agrees with this, I was chatting with a developer in the periphery of the Nokia/Maemo/MeeGo ecosystem and his position was basically "Upstream is no go for a serious company project", due to stuff like feature removal and lack of control.

From my personal experience working in a startup, it isn't feasible to upstream everything while working on it, there will always be higher priority things to do, like the next must-have feature or that bug that affects N people. Of course once the business is better established there might be that possibility, or once the startup is dead if the ex-managers are sympathetic and ex-developers are sufficiently motivated. There is major pain associated with this way of working, but I think might just be necessary.

Neary's article is an important thing to show bosses to get their priorities changed. Everyone go do it now.