Zatem w porównaniu z ogromem zmian jakie wprowadził Fx 3.0, wersja 3.1 będzie zmianą znacznie bardziej ewolucyjną i spokojną, co nie znaczy, że niepotrzebną

Prawidłowa obsługa profili kolorów ICC, media queries, długo oczekiwany text-shadow,  niezwykle ważna dla przyszłości otwartego Internetu obsługa znaczników <audio/> i <video/>, querySelector,  ustandaryzowany Drag&Drop, API do geolokacji, przeciąganie kart pomiędzy oknami, autotagowanie zakładek, znaczące przyspieszenie aplikacji webowych i samego Firefoksa dzięki Tracemonkey… a to tylko czubek góry lodowej, zapraszam do poczytania Fx3.1 dla programistów, i Fx 3.1 draft plan.

Część to usprawienienia widoczne gołym okiem, inne dadzą nowe możliwości autorom stron i autorom rozszerzeń, wszystkie są “spokojne”. Nie wiem jak to inaczej opisać, ale nie ma tu wielkich, ryzykownych zmian (może poza API do pobierania zdalnych czcionek), dużych przeobrażeń interfejsu czy ogromnych przetasowań w głównych elementach silnika.

Dwa ciekawe elementy, które spokojnie ewoluują w Fx3.1 to obsługa standardów i dodatkowe interfejsy do zarządzania sesjami i prywatnością sesji. I to z tym związane są dwa poniższe screeny:

Session restore updated

Acid 3 w fx3.1 nightly

Pierwszy pokazuje nowe możliwości podczas przywracania sesji, drugi to aktualizacja stanu ACID3 w Firefoksie. Te 93% to to co już wylądowało w głównym repozytorium, bo istnieją też patche poprawiające wszystkie pozostałe błędy, ale nie zostały jeszcze włączone do głównej gałęzi. Z tego co pisał Dbaron, prawdopodobnie na wydanie Fx3.1 uda się podnieść to do 98%.

Czemu nie 100%? Nie ma powodu do pośpiechu. Acid3, jak już wielokrotnie pisało wiele osób, jest testem dość “abstrakcyjnym” w tym sensie, że nie testuje najpopularniejszych elementów standardów, tylko właśnie te, które nie działają np. w Fx. Spełnienie wymagań testu ma sens tylko wówczas gdy jest elementem prac nad ogólnym poprawieniem obsługi standardów, a nie gdy jest sztucznym pompowaniem zmian, aby tylko zapewnić sobie “setkę” w jakimś testowym buildzie, który nigdy nie zostanie wydany i wywala się na wszystkim poza testem Acid 3.

To oczywiście nie wszystko, uważni obsewatorzy planety Mozilli z pewnością zauważyli pracę ekipy od Ux nad poprawkami użyteczności, nie wspominając już o setkach poprawionych błędów.

W tym samym czasie grupa z labs pracuje nad nowymi wersjami Ubiquity, Weave czy Prism, Mozilla Messaging eksperymentuje z UI i pracuje nad wydaniem Thunderbirda 3, a zespół z Mozilla Mobile szykuje się na wydanie Fenneca 1.0.

Ach, zapomniałbym, że także teraz, inna grupa, pod wodzą Brendana Eicha, pracuje nad Mozillą 2 – nową wersją platformy, która wprowadzi naprawde ogromne zmiany w funkcjonowanie Gecko, a wśród zakresu prac Gecko 2.0 pojawiają się takie rzeczy jak wsparcie dla animacji 3D – SVG, Canvas 3D, nowy standard lokalizacji – L20n, instalacja rozszerzeń bez restartu, Compositor – nowy system prezentacji układu strony i wiele innych…

Jeśli jednak tego jest Ci mało, masz poczucie niedosytu, albo uznajesz, że Mozilla to coś więcej niż grupa programistów i ich kod, to… masz absolutną rację Mozilla Foundation oraz Mozilla Europe pracują nad projektem o nazwie “2010 Goals“, który ma za zadanie zdefiniować rolę Mozilli jako aktywatora i uczestnika dyskusji na temat rozwoju Internetu w takich dziedzinach jak edukacja, dostęp w najgorzej zinformatyzowanych regionach świata, czy otwieranie rynku mobilnego tak jak zrobiliśmy to z WWW dzięki Firefoksowi.

Jeśli masz ochotę coś porobić, rozwijać się pomagając w realizacji naszej misji, to otwieramy właśnie dla Ciebie nowy portal – contribute.mozilla.org, który ma na celu pomóc Ci odnaleźć się na początku swojej przygody z Mozillą. Dużo się dzieje i jest mnóstwo miejsca dla Ciebie

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.

ZipWriter just has been included into trunk.

You may say it’s a small thing. Who cares? Opera, IE, Safari lives without it and you can rarely see users complaining that their browser lacks scriptable zipwriter, right?

Hah! Mozilla is a platform, not “a browser”. It *does* influence any effort towards Xul editors, Mozilla IDE’s and… L10n tool