Even the most casual of acquaintances knows that I really, really hate software that doesn't understand how we do things out here in the Open Source world. We have tools, really amazing ones, called ... "Package Managers" which allow us to "Install" software and describe the "Relationships" between elements. Apparently they can't seem to figure out how to deal with software dependencies and instead they opt for the "copy into tree and fork" method:
Google is forking existing FOSS code bits for Chromium like a rabbit makes babies: frequently, and usually, without much thought. Rather than leverage the existing APIs from upstream projects like icu, libjingle, and sqlite (just to name a few), they simply fork a point in time of that code and hack their API to shreds for chromium to use. This is akin to much of the Java methodology, which I can sum up as "I'd like to use this third-party code, but my application is too special to use it as is, so I covered it with Bedazzler Jewels and Neon Underlighting, then bury my blinged out copy in my application.". A fair amount of the upstream Chromium devs seem to have Java backgrounds, which may explain this behavior, but it does not excuse it. This behavior should be a last resort, not a first instinct. What should happen is this:[google] hey, it sure would be nice if we could use sqlite in chromium for our local db needs.[google] hmm, the sqlite API doesn't mesh 100% with how I'd like chromium to use it[google] hey sqlite upstream, there are a few places where we'd like to see API improvements
so chromium can leverage it for our use-case[sqlite_upstream] hey google, so cool that you want to use our code.* sqlite_upstream looks at google's proposed changes to sqlite *[sqlite_upstream] interesting, you could try using the foo_bar function for your camel launching
needs, but the rest of the changes seem okay* sqlite_upstream commits changes to the source tree in commit rev 12345 *[sqlite_upstream] Our next release will support that.[google] yay! we'll tell people to either apply our patch or use commit rev 12345 or newer.
As much as I appreciate Google's attempt at openness documented yesterday - and it REALLY is great and many steps in the right direction, it would be great if they'd also learn some of the process we already use out here. If they think it sucks and want to improve on it, then great - but start from what's there, don't just ignore it and hope we don't notice.