Supposed lack of code from Apple

[Jordan Hubbard]

On Wednesday, May 14, 2003, at 08:14 AM, John Baldwin wrote:

> Just a comment here.  I think this last statement is bull.  Apple
> has made lots of bugfixes to our code available in Darwin.  All it
> takes is for someone to extract their lazy rear from a chair and
> import those fixes.  We don't import our fixes into Darwin, Darwin
> developers do that.  In the same way, it is rather absurd to
> require Darwin developers to backport their fixes to FreeBSD.  That
> is the job of FreeBSD developers.  As an example of how this can
> work, see the recent fixes to smbfs that bp@ imported from Darwin.

Thank you for saying this, and not because I don't think there isn't 
more that Apple can to do communicate and work cooperatively with the 
open source community - I do think so and it's one of the things I work 
almost every day to improve.  I thank you for saying this because what 
you summarize below is a long-standing problem endemic to FreeBSD's 
relationship with almost ALL other open source projects, not just 
Darwin.  As early as 1993, people were meeping about FreeBSD not doing 
enough to track NetBSD changes or how it was gratuitously diverging 
from NetBSD due to NIH syndrome.  The same has subsequently been said 
about FreeBSD and OpenBSD and all the security work which has gone on 
in that project.

All these allegations have also been true to a large extent, and I'm 
sure that "mining" all the good stuff out of OpenBSD, NetBSD and Darwin 
could keep a team of 5 engineers busy for several months, probably to 
the great benefit of FreeBSD.  That would also represent a serious 
amount of drudge work, however, and most of it drudge work of the most 
onerous kind: Sifting through thousands of lines of source code just to 
find the good bits and then hand-merging then carefully back and 
thoroughly testing the result to make sure nothing was broken.

This is why I've been prevailing on Apple (and engineers in general) to 
stop thinking of contributing to the Open Source community as "throw 
lots of code over the wall and hope that it's of use to somebody" since 
that's actually a very limited view of contribution and, sadly, how 
most people measure it.  Anyone going to 
http://www.opensource.apple.com/darwinsource/10.2.5/index.html will 
find, for example, tons of software freely available, anything marked 
"Other" being truly easy to deal with and the APSL stuff somewhat less 
so but still obtainable (and I'm working on streamlining all the 
licensing issues), but guess what:  It doesn't really matter all that 
much anyway since very very few people even bother to look at it and 
wouldn't even if the licenses said nothing more than "Free!  Take me!  
Take me!"  Merging code is boring drudge work, particularly when you 
have to merge it in "polling mode" where you're coming along after the 
fact and trying to reconstruct a history of events between now and 
whenever you last looked.

What's missing isn't code.  What's missing, in all of these cases, is 
sufficient COMMUNICATION about what's going on or where the cherries 
are to be picked.  If people from the NetBSD project, for example, came 
by frequently with little gift-wrapped bundles of code and offers to 
help anyone willing to integrate it by answering questions or working 
cooperatively on any changes necessary to make it applicable to 
multiple projects, we'd be talking a completely different game entirely 
(not to say that this never happens, but certainly not frequently).  
That would truly be collaborative development in action and, sadly, 
there's generally very little of it which crosses project lines.  There 
are a few stalwart individuals who try to maintain a presence in 
several projects simultaneously and act as message-bearers when any 
technology suitable for merging goes by, but that's also not easy work 
and the people in this project should go out of their way to thank 
anyone for trying to do that and encourage more of it.  I've also been 
putting steady pressure on Apple's engineers to overcome their 
traditional aversion to sticking their necks out in public (an aversion 
which is sadly well-justified) and start trying to work more "shoulder 
to shoulder" with engineers in the Open Source community, making the 
point over and over that steady communication trumps throwing code over 
the wall every single time.  Progress has been slow but it's being 
made, and if anyone wants to yell at Apple or any other company for not 
"contributing" to the open source community, they should take a step 
back and wonder if maybe they're truly yelling about the right problem.

--
Jordan K. Hubbard
Engineering Manager, BSD technology group
Apple Computer