MeeGo : DESTROY your community in 6 Steps

Nokia and Intel finally joined hands @ MWC-2010 to announce MeeGo a merge of Maemo and Moblin. It appears like a strategic move by both the industry giants to stand-up against Google, whose latest product ANDROID is being fast adopted as the OS of choice for Handhelds and Mobile devices [1] [2].

Inspite of this ANDROID stands strong and is pipped to be the replacement on the devices that sport the Symbian series which has become a old fat horse in the present race. Also it has become the platform of choice for the latest smartphones all over the world.

Moreover in the present scenario MeeGo simply can’t compare to ANDROID and is just a feeble stop-gap attempt which will give some time for Nokia & Intel to come-up with proper plans to revive their falling market-revenues.

Projecting MeeGo as an OpenSource replacement is yet another attempt on their part to push for wider adoption

If you are a corporate developer, you’re likely to realize early on that free software development communities are a pain.

They’ll mess up your marketing schemes by, for example, taking the software into countries where you have no presence and no plans. They’ll interfere with product roadmaps with unexpected innovation, adding features which you had not planned for the next few years – or, worse, features which were planned for a proprietary version.

Free software communities are never satisfied; they are always trying to improve things. They tend to redefine partner and customer relationships, confusing your sales people beyond any help. And they bug you all the time: sending email, expecting you to attend conferences, and so on.

Fortunately for NOKIA and INTEL,
there are ways to get rid of this “community menace” (as they see it).

All they need to follow is this 6-STEP-Procedure.


is to make the project depend as much as possible on DIFFICULT TOOLS. Most companies have no real trouble employing this technique, since it makes good use of the tools they have around anyway. Community-resistant projects should, for example, use weird build systems not found anywhere else. A proprietary version control system is mandatory. Even better are issue trackers with limited numbers of licenses, forcing everybody to use the same account. It’s also important to set up an official web site which is down as often as it’s up. It’s not enough to have no web site at all; in such situations, the community has an irritating habit of creating sites of its own. But a flaky site can forestall the creation of those sites, ensuring that information is hard to find.

MeeGo’s Case : The most weak part of moblin IS the development tool.
And MeeGo is based on Moblin. Duh!!


Encourage the presence of POISONOUS PEOPLE and maximize the damage that they can create. There is a special technique to the management of these people which goes something like this:

  1. Take pains to argue with these people at length and to denounce them on the project lists.
  2. Eventually, they should be banned from the community by fiat; it’s important to avoid any sort of community process here.
  3. The banned people will take their flames elsewhere. Follow them and continue to argue with them in those external sites.
  4. Eventually the community will complain about this behavior; respond by letting the poisonous people back in. Then go back to 1. and do it all over again.

MeeGo’s Case : Join the MeeGo-DEV list here. No “Poisonous” people yet.


Provide NO DOCUMENTATION. There should be no useful information about the code, build methods, the patch submission process, the release process, or anything else. Then, when people ask for help, tell them to RTFM.

MeeGo’s Case :


Employ large amounts of LEGALESE. Working with the project should involve complex contributor agreements, web site content licensing, non-disclosure agreements, trademark licenses, and so on. For full effect, these documents should all be changed without notice every couple of months or so.

MeeGo’s Case : Here is an excerpt from the License Page on
“The MeeGo licensing policy in this page is the first and initial version. Changes are expected to take place both during the first months of project formation and over long term resulting from a dialogue between project participants and from reactions to external developments. The Technical Steering Group of MeeGo is responsible of setting the licensing policy…”
More MeeGo legalese here.


Do not allow anybody outside the company to have COMMIT ACCESS, ever. There should be a rule (undocumented, of course) that only employees can have commit rights. Respond evasively to queries – “legal issues, we’re working on it” is a good one. For especially strong effect, pick an employee who writes no code and make them a committer on the project.

The COMPANY LIASON must be chosen carefully. The optimal choice is somebody reclusive – somebody who has no friends and really doesn’t like people at all. Failing that, go with the busiest person on the staff – somebody with both development and management responsibilities, and who is already working at least 70 hours per week. It’s important, in this case, to not remove any of this person’s other responsibilities when adding the liaison duty. It can also be effective to go with somebody who is unfamiliar with the technology; get a Java person to be the liaison for a Perl-based project. Or, if all else fails, just leave the position vacant for months at a time.

MeeGo’s Case : Here’s wat one of the developers has to say (source Meego-Dev)
“It also has some (let’s call them) grey areas around use in embedded platforms, which are at best open to debate and interpretation, and at worst make it difficult to use GPL v3 software in certain embedded environments.”


Don’t answer queries.
Don’t say anything.

A company which masters this technique may not need any of the others;
it is the most effective community destroyer of them all.

MeeGo’s Case : – – – ( whooosh….)


Josh Berkus is a well known PostgreSQL hacker, but, as it happens, he also picked up some valuable experience during his stint at “The Laboratory for the Destruction of Communities,” otherwise known as Sun Microsystems. That experience has been distilled into a “patented ten-step method” on how to free a project of unwelcome community involvement. Josh’s energetic presentation on How to destroy your community was the first talk in the “business of open source” miniconf; it was well received by an enthusiastic crowd.

“Josh concluded by noting that he saw all of these techniques employed to great effect by Sun. But Sun is far from alone in this regard. Josh has been told by a veteran of the X Consortium that they, too, had made good use of all ten methods at one point or another.

Community-destroying skills are widespread in the industry

Read the Entire Article here.


Related Posts:


~ by CVS268 on Fri, 26 Feb, 2010.

10 Responses to “MeeGo : DESTROY your community in 6 Steps”

  1. what rubbish.

    • @The Crypticum Keeper

      This might sound pretty bad, but its the sad truth.

      Companies often open-source projects to get better PR and generate community interest. But, often later they reduce the open-community’s involvement using techniques mentioned above.

      Lets all take an ACTIVE part in the community development process and not let the TECH giants manipulate the process for their commercial interests!!

  2. I hav enever read such a bullshit!

    • But evidently Companies do Bullshit for commercial reasons.

      And now that You have heard of it, i hope You will spread the word. 🙂

      Lets hope that people do realise that Major Tech Giants almost always have their commercial financial interests in mind. Often they tend to manipulate Open-Communities to achieve their motives.

      Lets hope that doesn’t happen in the case of MeeGo!!
      [ C’mon people!! Lets show NOKIA-INTEL that we mean something!! ]

  3. When I wrote “I have never read such rubbish” I mean this bloody so called blogg !!!
    Wake up and begin to live in the real world or are you so afraid you must live alone in the dark?????

    MeeGo = the best thing ever done in the computer world!

  4. What you don’t seem to understand is the significant overlap between commercial entities and Free Software. Plus – the GPL explicitly allows for the commercial sale and support of GPL’d software. So you are barking up the wrong tree here.

    If Intel and Nokia fail to accomodate the community, they risk a fork. A fork is always bad because it tends to decimate (or worse) the amount of work done on a given project. Furthermore a fork of MeeGo would be really, really bad publicity for both companies, so they have more at stake than just developing software – they have their customers to consider.

    Perhaps the public bits of MeeGo are not being made available as quickly as we’d all like, that is a legitimate criticism, but the rest of your rant is pretty close to a copy of that talk given at Linux Conf AU.

    • @jeremiah Exactly my point!! 🙂

      The Open-Community needs to step-up and play a more active role to…

      [1] Prevent Any FORK due to obvious reasons.

      [2] Rapidly deliver.
      Convert MeeGo from just a Media-hype to the “REAL” thing.

      [3] Not allow any “commercial-interests” to divert the growth of MeeGo elsewhere.

      I hope U too agree that MeeGo is a very crucial step ahead for the Open Community. It must be nurtured and enhanced.
      (And not leave anything to chance.)


  5. […] Call me PARANOID but are U adopting the “STEP#5: The  SILENCE STRATEGY“ […]

  6. […] 2600Hz blog riffs on Josh’s theme with an article specific to MeeGo.  I’ll leave it to the reader to judge the validity of the analysis […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s