“The main reason we can’t release Flash Player as open source is because there is technology in the Player that we don’t own…”

Sounds reasonable except that developers know it is BS. Just open source the unencumbered parts and let the community help you both maintain and improve your platform, as well as engineer around the encumbrances. A typical comment, repeated by many:

“You can open the source code to the parts of the Flash Player you do own. Your commitment to openness sounds imaginary.”

The moral of the story… tell the truth, even if it hurts. There must be some real reason why Adobe doesn’t open source Flash Player. No matter what the reason it would be better to just own up to it. Even if the community disagrees with Adobe’s reasoning, they’ll at least respect the company for being transparent. Read the comments! The alternative is very bad karma!

• 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!

“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.

• 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.

Want to know how to send your karma quotient into the cellar? Turns out it is startlingly easy to blow your foot off.

Case in point: the Symbian Foundation, established by Nokia as an independent entity to manage the open source Symbian mobile OS code base. Back in June 2008, Nokia bought Symbian, Ltd. and the OS, and simultaneously, they, along with several other OEMs and carriers, started the Symbian Foundation, announcing a project to open source the whole platform under the Eclipse Public License. Fast-forward to October 26, 2009, when the foundation announced the microkernel source code’s release as open source:

The kernel release is nine months ahead of schedule and reflects the positive momentum behind Symbian’s ambitious platform migration plan, which began with the release of security code under EPL.

16 out of a total 134 platform packages have now been released into open source since the code was first made available on the Symbian Foundation servers in April 2009.

Wow. 16 months after announcing they’re going to open source the platform, they’re up to almost 12% of the modules and ahead of schedule! Sure, it is hard to open source previously closed source code. Sifting through all that code, figuring out who owns the copyright, and cutting licensing deals for these encumbered bits of source or writing clean-room replacements is a thankless and difficult task. But have the stewards of Symbian noticed that they’re in a white-hot competitive market for pride of pocket in smartphones vs. the likes of Apple, Google, RIM, Palm, Microsoft, and a host of other competitors? The Symbian OS has the market-leading position today thanks to Nokia’s market share outside of North America – 48% worldwide. But Android and iPhone are growing by leaps and bounds, largely at the expense of Symbian and Microsoft’s Windows Mobile. Actually, this fact is not lost on Symbian’s backers. Sony Ericsson is launching the Xperia X10 Android-based multimedia smartphone in early 2010. Samsung, according to Korean investment house HTC Investment Securities, is going to ditch Symbian completely, focusing on Android and their own Bada platform, announced today. Even Nokia is hedging their bets, with their new, hotly anticipated N900 tablet running the Maemo mobile Linux platform, and not Symbian OS.

Not pretty. What to do? Savage your competition – another open source project (and a very popular one at that!) … well, perhaps thats not the best strategy but it is what Lee Williams, Symbian’s executive director chose to do on October 23, in this interview with Om Malik of GigaOM. You know you’re in rough water when your interviewer interjects “you know you are on camera?” to throw you a life ring.

The funny thing is – Williams is right. Google is so hands-off with how Android is being deployed, that the parochial interests of handset vendors are trumping the need for consistency, creating fragmentation that could derail Android’s platform adoption momentum just as it is gathering speed. But for Williams to poke at Android’s multiple UI skins when Symbian has S60, UIQ, and MOAP interfaces requiring developers to port across these interfaces and also across carrier and handset differences is a case of throwing stones in a glass house. A few lessons:

1. Don’t diss other open source communities. Developers are looking for signs of cooperation and community, not corporate style competitive trash talk. Even if you’re right, you don’t win respect with such tactics, you just look desperate.
2. Don’t blast others for issues on which you are as bad, or worse. You just look silly, and developers lose respect for you, because they know you’re trying to pull the wool over their eyes.
3. Don’t announce a grand gesture aimed at securing developer interest, and then drag your feet, or even worse, renege on your promise. Developers don’t care about your excuses. They know things are hard – so what? As Yoda said, “Do, or do not. There is no ‘try’.”

Is Symbian a lost cause? Not at all! They have the largest market share of any smartphone platform, and outside of North America the OS is a strong player. Here are some headlines that the Symbian Foundation could deliver that would create good karma:

“Symbian revamps tooling, SDK, simplifies development model, based on community input and contributions.”

“Symbian Foundation funds accelerated open source project to build automated Android to Java ME porting framework, adopts Android API as alternative programming model.”

“Low-cost embedded device manufacturers standardize on Symbian on a chip design; create ultra-high volume ‘brain’ to add intelligence and style to everyday products.”

“Symbian Foundation eliminates ‘Symbian Signed’ program, creates industry leading free application QA process with guaranteed 7-day approvals, transparency.”

“Symbian Foundation completes open sourcing of the Symbian platform through unprecedented community contributions of unencumbered APIs; surprising shift to cooperation praised by enthusiastic developer community.“

All of these possible headlines have one thing in common: achieving them would require real commitment, investment, and hard work. It isn’t just what you do, its how you do it that generates good karma. Including developers in decision making, valuing their contributions, and leveraging their goodwill are vital. Solving real-world problems facing developers and helping them innovate and succeed are essential. If you do not do these things, your competition will.

How obvious! And yet how hard to put into action. Why? Because trust is earned over time, with consistent, principled behavior that values long-term success over short-term profit. And trust is so easily trashed – one shortsighted decision, a few ill-conceived words, and you’re in the doghouse. Wreck your karma and you’ll be rebuilding that trust you so swiftly demolished, and maybe never getting it back.

I hear you saying “Yeah yeah of course! Developers trust us! We’re the good guys!” But are you? Turns out that the very things that developers look for as markers for mistrust are often the things you do to make money. And actions speak louder than words.

Remember Movable Type, the once popular blogging platform from Six Apart, Ltd.? Back in the day, MT was the bee’s knees. Six Apart had always offered a free version, allowed users to modify the code, hosted a public repository, encouraged contributions, patches, and plugins. They built a community of passionate developers and users who enthusiastically recommended MT to their friends, and helped create a groundswell of adoption. That is how it is supposed to work! Six Apart was the leader in blogging tools, launching TypePad (hosted blogging) and with leading market share in both self-hosted and hosted service blogs, because they were the good guys. Because they painstakingly had built their good karma.

Then on May 13, 2004, developers and users woke up to discover they’d been fooled. MT 3.0 was still free for one author and up to 3 blogs. More than that, and you had to pay. Whats wrong with asking for money for something valuable like blogging software? Nothing, unless you have built your large, enthusiastic developer and user base on a promise to make MT free, with source code, and then once they’ve adopted your platform you renege on that promise. MT 3.0’s passionate community felt duped. Their passion turned to scathing anger and disgust. They had trusted Six Apart, and that trust was destroyed with one ill-conceived decision, born of the need for Six Apart to monetize their hard work.

That’s bad karma.

With the 3.2 release, Six Apart restored an unlimited number of blogs for all licenses. With 3.3, MT was once again free for unlimited non-commercial use. Still not enough…. on December 12, 2007 Six Apart relicensed MT as Free Software under the GPL. But the damage was done.

Where did MT’s community go? Mostly to WordPress, which was far behind MT but rapidly caught up in features and sophistication. WordPress has been under the GPL license from day one. There are over 7000 plugins that extend it in almost any way imaginable. All plugins in their repository are GPL or compatible with GPL and open source. The WordPress community is enormous. Customizable themes can make WordPress sites look like almost anything you want (disclosure – I use WordPress for this site). WordPress is Free Software but the leading hosted WordPress service – wordpress.com – is run by Automattic, Inc., who’ve established a fast growing business built on making WordPress effortless for the non-technical blogging world. Automattic is a key contributor to the WordPress project itself which, with three releases/year is accelerating its innovative pace and developing an aura of cool as it is used by marquee Web 2.0 commentary sites like GigaOm and TechCrunch.

How is Six Apart doing now with their karma? A blog back in March 2008 by their chief evangelist, titled “A WordPress 2.5 Upgrade Guide” opens with the line:

As you might know, WordPress 2.5 is about to be released, and we wanted to encourage WordPress users to upgrade. To Movable Type.

More bait and switch. This time, baiting WordPress users trying to upgrade with an article bound to pop up in search results. That kind of bare knuckle competition may seem like business as usual but in the developer world, where cooperation and community are valued above all else, it generates more bad karma. Many comments to the post had this flavor:

Comparing your product to a competitors by putting them down is not going to hold you in good stead (as I’m sure you’ve seen by now by the posts on TechCrunch and Twitter conversations), even though you might feel the need to make direct comparisons to pull people.

Another example, this time about Six Apart’s hosted service, TypePad in a comment to Mashable’s October 2009 “Blogging Faceoff: WordPress vs. TypePad” article (in which WordPress got an overwhelming 87%, TypePad 9%, and 4% called it a tie):

My big beef with TypePad is that, when I switched to WordPress, TypePad held my graphics hostage. They would not allow me to transfer them with the other content in my blog.

More bad karma.

But what does all this have to do with adoption? Does it really make a difference? See for yourself:

TypePad vs. WordPress.com (hosted blogging)

Movable Type vs. WordPress.org (blogging platform)

Ok, visitors doesn’t equate to platform adoption. But even the most jaded metrics maven would likely conclude from these statistics that WordPress in both cloud and platform versions is trouncing Movable Type.

If you think that platform adoption is critical to your ability to make money, you ignore your karma at your peril.

Thanks to Dalibor Topić for the example idea used in this post. Now there’s a dude who really has good developer karma!