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  .
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:
- Take pains to argue with these people at length and to denounce them on the project lists.
- Eventually, they should be banned from the community by fiat; it’s important to avoid any sort of community process here.
- The banned people will take their flames elsewhere. Follow them and continue to argue with them in those external sites.
- 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 MeeGo.com
“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.
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 linux.conf.au 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.