Date: Wed, 14 May 2003 13:32:59 -0700 From: Jordan Hubbard <jkh@apple.com> To: John Baldwin <jhb@FreeBSD.org> Cc: hackers@FreeBSD.org Subject: Re: Supposed lack of code from Apple Message-ID: <40E26969-864B-11D7-8900-000393BB9222@apple.com> In-Reply-To: <XFMail.20030514111438.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40E26969-864B-11D7-8900-000393BB9222>