Tom Callaway of the Fedora Linux distribution has a great post on the ins and outs of how a major Linux distro evaluates the inclusion of an important upstream project – in this case, Google’s Chromium, the open source code base for the Chrome browser. Turns out Chromium isn’t yet a blessed package that is part of Fedora. Why? Because the Chromium project isn’t playing completely by the “rules” governing how Fedora expects to collaborate with its upstream components. Tom sums up his long and insight-filled post in the final line:
“I do think that with great power comes great responsibility, and Google could truly be a much better community participant than it currently is.”
Here’s a few of his issues that I’ve spun into recommendations, generalized and refactored:
- Be stable: Establish a release “heartbeat” for your code base, with declared, numbered snapshots that are feature complete for a given version, tested and supported for a reasonable time with patches and bugfixes fixing big bugs or plugging security holes.
- Divide and conquer: Engineer your large project as a bunch of independently developed, valuable piece parts each of which has stable releases (see above bullet). Why is it good for the whole to be built from smaller independent projects? Because those independent chunks might be useful in and of themselves in other FOSS projects, and because the independent project approach ends up being more maintainable, and thus supports more participation by a more dynamic community.
- Participate: If you’re going to use someone else’s code, join their community, participate in their process, and contribute to the overall FOSS ecosystem you’re relying on. Do not take code from other projects, makes custom changes, and include the hacked upstream code without giving back to the upstream project through participation. Bad karma! And doing that also obligates you to maintain your custom hacks – so give back those changes!
There are a ton of reasons you might not want to do all this stuff. It can slow you down. It can cost you $ and resources. It can make your binaries run slower, be bigger, come out later, and be less competitive. Good karma is hard work, and entails compromise. It isn’t a slam-dunk that you should always maximize your community participation at the expense of other objectives. Its a hard decision, with real trade-offs. As Evan, one of the Chromium developers says in a comment to Tom’s blog post:
“I think the shorter answer is: you demand a huge amount of work for minimal benefit for “upstream” (Chrome), so while various bits of the work are underway it’s not going to happen quickly. Each of your bullet points is of the form “X ought to be Y” but none mention why that is useful (or if it is useful, why it merits the amount of work involved). *shrug*”
Ok, so following all the rules to be packaged with Linux distros can be hard to justify, even for a company as culturally committed to open source, and as resource-rich as Google. Why do it then?
- Your business model scales revenue with platform adoption.
- You’re in a market with network effects that make it so only a few competitors at most can survive, and only one really wins.
- Adoption of your platform depends on it “just being there” when sophisticated, influential developers need its features. In other words, when you need to be distributed with Linux distros.
If you don’t have an adoption-led model, if your market values “best” more than “easy” or “standard”, or if your platform is for a niche, a vertical market, or targets a proprietary foundation, then the costs of being a good citizen may outweigh the benefits. Or if you are one of the very few companies like Google with so much market power that rules don’t apply to you, and the community will swallow hard and adopt your platform anyway, you can cut corners on community participation.
Do the analysis, but understand that having good karma is often pretty much a binary thing. Either you are doing the community dance and you’re trusted by developers to be transparent and participatory, or you’re not. Factor in all the costs, consider the opportunity that monetizing your platform offers, and make a decision. Either pursue an adoption led strategy, or don’t. If you decide that you can’t afford community, then make that choice clear to everyone. Developers might regret that you aren’t adopting an open model, but they can respect that decision. What they can’t abide is you trying to fool them that you’re serious about open development - inviting them to participate in your community, but not giving back to theirs. That is the epitome of bad karma.
How does Google get away with it? They’re a very sophisticated community participant and understand all of this in great detail, and make considered choices on just how they’re going to participate, and they invest a lot in community. They get cut some slack because they mostly do the right things, and they listen. Oh, and because, well… because they’re Google.
When is community part of your DNA? No magic here – it is like everything else: when you plan and budget for it, and goal and measure your staff by their participation. There aren’t any shortcuts, and you can’t have it both ways. But once you’ve really thought through your adoption-led strategy and made the decision to see it through, you will wholeheartedly execute that strategy knowing that the rewards justify the costs.