RSands Consulting

At WordCamp Boston this past weekend there was a great Ignite talk session. The last Ignite speaker was Jane Wells of Automattic, Inc., the WordPress.com folks. She told us in 5 minutes and 20 slides with nary a breath, about the new WordPress Foundation founded as a charitable organization by Matt Mullenweg, the creator of WordPress. I think this is a great thing. A Foundation serves a number of valuable purposes for a FOSS project:

• Protector of the code, if the Foundation owns the copyright and accepts contributions through a contribution agreement.
• Protector of the other IP including patents (but what self respecting FOSS project would own software patents?) and trademarks.
• Sponsor and participant for standardization efforts that dovetail with the project.
• Center of gravity for donations and common community resources such as developer grant programs, legal defense, and project infrastructure.
• Chief cheerleader and promoter, sponsoring events, providing spokespeople, establishing training and certification, and generally making positive noise about the project.

The WordPress Foundation is going to do a lot of this. They’ll own and license the trademark and logo, and sponsor WordCamps and other events. The rationale on the “About” page is surprising, however:

“The point of the foundation is to ensure free access, in perpetuity, to the projects we support. People and businesses may come and go, so it is important to ensure that the source code for these projects will survive beyond the current contributor base, that we may create a stable platform for web publishing for generations to come.”

What is interesting here is the claim that the Foundation will protect the code – presumably against the potential for ravaging by some evil corporation that might acquire the rights to the code base in an acquisition. Need an example? We just saw a nine-month standoff between the European Commission and Oracle over the Sun/Oracle merger and its potential to harm competition from MySQL in the database market. The EC determined ultimately that this merger was not anti-competitive, and it closed earlier today.

So who owns the copyright on WordPress? I asked Matt Mullenweg in a blog comment about this. His reply:

“Copyright is maintained by the original contributors of code, and licensed under the license of WordPress. (Which makes it highly unlikely we will ever change licenses.)”

So, WordPress is not like MySQL. With a code base that is owned by many authors, there is little danger of falling prey to an entity bent on harming the project or community. There is no way for a corporation to gain such control, when they’d have to find all those authors and negotiate copyright assignments with all of them. As Matt says, this also means that WordPress will forever be a GPL v2 project as there is no practical way to re-license the entire body of code.

The WordPress Foundation serves another purpose: it declares to the world that this project is ultimately owned by the community. Not just the code, but the trademark, the PR voice, and all the rest. Why does that matter?

Adoption!

Continue Reading

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.

Continue Reading

Google does open source projects right. Mostly. Their new Go programming language has all the earmarks of a savvy developer initiative:

• Cool technology
• Geek rockstar spokesperson
• Sophisticated PR blitz
• Permissive BSD-style license
• Community development
• Early access with plenty for contributors to do

Lovely! Great example of creating good karma. Except for a little detail – the name. Tsk tsk – they should have googled “Go” before naming their new toy. Turns out that someone else invented a computer language and called it Go! (exclamation point is part of the name). Frank McCabe’s Go! language had its public debut in a research paper published in 2004. He wrote a book on the language, published in 2007. As for Google’s use of the same name, McCabe said:

“It takes a lot of effort to produce a reasonably well-designed language. I am concerned that the ‘big guy’ will end up steam-rollering over me. I do not have resources to invest in legal action; but do not intend to let Google keep the name without them being explicit that they are steam-rollering over us.”

825 comments and counting on Google’s issues forum mostly are in support of McCabe, call for Google to change the name, and are questioning Google’s commitment to their “Do no evil” motto.

A moment of truth for Google – what will they do? Stay tuned, because whatever their choice, the way this plays out is a case study in managing karma.

Continue Reading

Community blog aggregators have become popular features of developer communities for good reason – they make it easy to follow the meatiest technical posts about a platform. Also called “Planets” after the Planet server side software often used to assemble them, these sites bring together blogs written by members of a community in a single spot, usually displaying excerpts in a chronological scrolling list of posts that interleave content from many contributors.  A Planet ideally is a dynamic, ever-changing mosaic that presents a snapshot of the latest and best thinking going on within a community. Some Planets like Planet KDE (http://planetkde.org/) are mostly technical with a smattering of other stuff. Some like Planet Apache (http://planet.apache.org/committers) are more wide-ranging, reflecting a wide breadth of content.

It seems like it ought to be pretty easy to manage a blog aggregator. In practice it isn’t, and the issues you’ll face are a microcosm of the common issues in building a developer community. One such issue is how you decide whose feed is in, and whose is not.

Ed Burnette’s post “Planet Android and the terrible twos” illustrates this challenge: Planet Android is being swamped by duplicative newsy posts as more and more news and info streams get included in the Planet’s subscriptions. So, do you accept everyone’s feed who wants to be included? Or do you actively edit and design a Planet, selecting specific feeds that are known to deliver a high signal-to-noise ratio, be unique and well-written, and cover a range of interests within your community? If you do choose to be selective, you could base inclusion on an editor’s judgement, but you might be seen as overly controlling. You could let the community vote on which feeds to include, but this presumes that community members will be sufficiently active and motivated to vote on something like this. Perhaps the editor could be a respected community member outside of your organization, so that you’re not seen as controlling it, and yet it is still shaped into a high-value resource.

Knowing and respecting your community is the key to figuring this stuff out. Is your community “strictly business”, and readers don’t want exposure to off-topic or personal blog posts? Or are your community members interested in each other’s ideas and experiences whether they’re technical and on-topic or not? One excellent way to find out – ask!

Whatever you decide – edited or wide-open, be consistent with the rest of the content and governance of your community. If everything else is tightly controlled, developers will be comfortable with an edited Planet. If your community is governed by a loose consensus of participants, a tightly edited Planet will seem out of place.

What do you think? How do you manage your blog aggregator, and how’s it working? What do you like to see in the Planets you visit?

Continue Reading