I want to write a bit on what Ian McKellar, my old fellow from Flock, and now a proud member of the Songbird team, called Not Invented Here attitude.

Actually, NIH syndrom is well known and described in the memoirs of Wikipedia. It’s a persistent sociological culture that prevents the organization from using existing knowledge, code or research because it has different origins.

While this topic has been widely discussed all around the globe, and even in open source world, it has never been a topic in a Mozilla ecosystem debate.

Pity, since there is an elephant in the room, I can swear.

Flock developers, Songbird developers, Miro, Joost, Disruptive Innovations (time to update the website Daniel), AllPeers, and developers from many other projects contributed to Mozilla source code in many different ways – look at the very rough bugzilla search that displays bugs that were reported or assigned to one of the developers from the projects listed above during last 2 years. Over 600 bugs! And only 22 of them are INVALID – pretty damn high signal/noise ratio. Those are much above average quality bugs, with higher chance to be valid, and fixed.

We have a lot of references to Flock on wiki.mozilla.org. Most of them refer to Flock’s UI on the UI draft list, which is obvious. Hey, we’re not talking about “stealing” ideas. We have two open source browsers that can exchange ideas, code etc. Flock is smaller, focused on people using web more than an average, it has a Bigger Brother, who has to move more carefully and be more responsible, while Flock can move faster experimenting with features from the new areas of the web usage. It’s obvious and natural that other browsers should look at what Flock is experimenting with. Same with Songbird. It’s an multimedia center that uses Gecko. If Gecko is about to add support for a media, the natural first look should be at how Songbird did that. I remember trying to get Termie to work on Places (it was before Fx 2.0 times! Ben Goodger was working on the Firefox UI), hey! Termie even was granted by his manager quite a lot hours per week to investigate and work on Places for Firefox. It was also an obvious decision from Flock. Flock will switch to Gecko 1.9. The better the places are, the easier it’ll be to use them.

So instead of Mozilla leveraging from this community,  it often does nothing to use their knowledge, energy and code to make Mozilla better. At the same time, the companies around Mozilla are so focused on their own products, and are rarely doing anything more than minimum to contribute to Mozilla.

My best memorized case is bug 302387 from b.m.o. which is waiting for way too long lacking energy to push it through. On the other hand we have bug 2894 from Flock’s bugzilla,  filed almost 2 years ago by Gerv. I can imagine how demotivated Gerv can be after waiting for so long, feeling that actually everyone is positive, but no one will take care to finish the procedure. There are many more bugs in both bugzilla’s, but of course majority is in b.m.o. Everyone is positive, no one complaints, but also no one does the work of the doorkeeper who helps an external guy make his patch through the system. (maybe I should get used to that, all in all, it’s exactly the same with MediaWiki for example). As you may expect, in the example above, Termie did not work on Places, and I believe the reason was because Flock did not encourage him too much, while Mozilla was not too much interested in getting help from a Flocker.

While it may seem like the guilt is divided, I believe that the stronger and bigger player keeps more responsibility for making the environment non-NIH.

So the first problem with this is that Mozilla community did not grew it’s doorkeepers. Wikipedia is a great example of a project where such people are grown naturally. In each and every Wikipedia community I tracked there are people who are specializing in greeting new ones and helping them skip the entry barrier.  In case of Mozilla we should probably simply grow a culture of such attitude instead of separate group of people.

If we accept the fact that it’s really hard for an external person to understand and suit to Mozilla environment architecture and that once he did it (usually without much time granted by his manager) he faces extreme amount of passive slowdown. People are smiling, do the minimum they need when pointed, but nothing more, not a single step beyond. And in result I promise that without a deep sense of understanding, such person will never ever again want to go through this. He’ll just stick to he’s work.

Instead of the “Hey! Great you want to help us, let me help you” message, he gets “If you want to support us, prove that you have motivation to go through meanders of our policies, because we don’t trust the ones who can’t spend single 15 work hours looking for a super-reviewer.” – I understand that such policy raises the chance that the ones who actually will escape the pitfalls will contribute in a better way, but beside of that, it rejects a lot of valuable contribution. Too much comparing to what we win this way.

But even after fixing this we’re still not ready with the NIH problem. We’re still talking about the cases when a member of smaller Mozilla based project comes to the Mozilla bugzilla, files a bug and even spends some time to try to get it into the system.

The next step should be for the Mozilla to look around and accept the fact that in the open source world Mozilla built not only Firefox, not only Thunderbird, Seamonkey, Camino, Bugzilla and a community around itself. It also built many external projects, that are worth cooperating with. Not querying Songbird about audio/video, not querying Flock about starring, search bar, those are a cases when something went wrong. I’m not sure if that happened, but I can imagine that AllPeers members were not actively involved in download streaming upgrade for Gecko 1.9 (didn’t found any evidence of that in b.m.o). As Matthew stated, Flock has been never asked by Mozilla to tri-license any part of the code base.  Even, when Firefox 3 “starring” system is strongly affected by the Flock approach.

Mozilla should get used to actively involving external project members into work on the topics which are affecting them. It requires a lot of groundwork, and is probably hard to do, but I believe it’s worth trying.

Let me state that it’s not about political issues. It’s about from-the-bottom attitude. It’s not happening always, but it happens often. It’s not a result of conscious effort, it’s rather a result of lack of effort that can be eventually strengthen by ambivalent  reactions from managerial staff to the idea of using external support.

I can assume that NIH syndrome is  a natural drift of most work environment. We have to put a pressure to avoid it, and to minimize the pressure, we have to be aware that we’re affected by this problem, plus agree that we all want to solve it.