<Glazblog/>

Mozilla

Warning Bill, the lizard still bites

Entries feed

Saturday 28 July 2018

Gerv, oh Gerv :-(

Gervase Markham

Thursday 23 November 2017

XUL, Mac Touchbar, BlueGriffon

The title of this article says it all. First attempt, works fine, trivial to add to any XUL window. This is a code I wrote for Postbox, used here with permission.

BlueGriffon with Mac Touchbar

Thursday 16 November 2017

BlueGriffon 3.0

I am insanely happy (and a bit proud too, ahem) to let you know that BlueGriffon 3.0 is now available. As I wrote earlier on this blog, implementing Responsive Design in a Wysiwyg editor supposed to handle all html documents whatever their original source has been a tremendous amount of work and something really painful to implement. Responsive Design in BlueGriffon is a commercial feature available to holders of a Basic or a EPUB license.

BlueGriffon Responsive Design

/* Enjoy! */

Friday 3 November 2017

Responsive Design in BlueGriffon

After nearly two years of failed attempts and revamped algos, it's finally time to shout that Wysiwyg Responsive Design in BlueGriffon is ready to ship, and that deserves a major version number for BlueGriffon :-) It was really, really painful and hard to implement given the fact BlueGriffon is and must remain a Wysiwyg editor able to edit any arbitrary document, whatever its source. It means being always able to add styles as requested by the user : « I want this element to be bold when the viewport's width is between 400 and 500px and I don't care if it's simple or hard because the Media Queries in that document are a real mess, just do it ». Most editors can't do that. They let you create and edit only "Mobile First" or only "Desktop First" media queries, or they're a source editor. With BlueGriffon, even a site that is pure Media Queries' hell like http://cnn.com can be modified...

Responsive Design will be available soon at no extra cost to Basic and EPUB license holders.

/* Enjoy! */

Tuesday 4 April 2017

XUL-based OS X TouchBar #2

Done. I have added XUL-based support for OS X Touchbar to Postbox and that will certainly ship soon. It's then probably the first Gecko-based application with OS X Touchbar support... All in all, it was quite easy. I only regretted some very strange or sometimes inconsistent design choices on Apple's side. But let's get back to the results... In the code, we have for instance:

code in Postbox's main window

And the result is:

Postbox's main window and touchbar

All in all, quite cool, simple to understand, manipulate, and even extend (on both the XUL and Cocoa side). Was fun to implement :-)

Friday 10 March 2017

OS X TouchBar

Currently adding OS X TouchBar support to XUL :-) So far so good. Should be trivial to add multiple touchbars to a given XUL window when it's done.

Monday 6 February 2017

Dual View in BlueGriffon

Long, long ago, one of the dreams of the manager of the Editor's Team at Netscape, Beth Epperson aka beppe, was a dual Source+Wysiwyg view, with Source and Wysiwyg kept in sync. And to do that, a few on the team (beppe, cmanskey and myself) were hoping to use the following:

  • in full theory, the CSS Object Model was made to allow different Views on each document. That's the reason why we have a getDefaultView() when we query a computed style... Unfortunately, rendering engines never really allowed that.
  • we hoped to use that mechanism to create a Stylesheet that would precisely and exactly render the source of a document. We missed a few things, of course: a value for the content property serializing the start tag of an element with all its attributes, another one for the end tag, possibly a property to control entity output and we had of course a problem with all the stuff a CSS rule cannot select (comments, PIs, prolog, cdata sections)

It never worked that way, unfortunately. We tried and had to declare failure. We also briefly tried another approach, classic, of keeping in sync a real source view and a real Wysiwyg view. Unfortunately, Gecko was rather slow on slow computers at that time and the performance hit was too high. But modern engines with super-fast JS and much better CPUs changed all of that.

I'm then glad to report a Gecko-based Wysiwyg editor finally has a sync'd Dual View: BlueGriffon. It will ship with forthcoming version 2.3.

Dual View

Tuesday 3 January 2017

One BlueGriffon

There are - there were - two BlueGriffons: the Web Editor (aka BlueGriffon) and the EPUB2/EPUB3 editor (aka BlueGriffon EPUB Edition). With forthcoming v2.2, these are going to merge into a single product so they will never be out of sync again. Technically, the merge is already achieved and the next days will be spent on testing/ironing. Licenses for each product will work with that v2.2. BlueGriffon licenses will, as before, enable the commercial features of the product while licenses of the EPUB Edition will enable the commercial features AND EPUB2/EPUB3 editing. We'll also add an upgrade at special cost from the former to the latter. Stay tuned!

BlueGriffon 2.2

Wednesday 1 June 2016

BlueGriffon 2.0 released

I am happy to announce that BlueGriffon 2.0 is now available from http://www.bluegriffon.org

Screenshot of BlueGriffon 2.0

Sunday 22 May 2016

CSS Variables in BlueGriffon

I guess the title says it all :-) Click on the thumbnail to enlarge it.

CSS Variables in BlueGriffon

Thursday 12 May 2016

BlueGriffon 2.0 approaching...

BlueGriffon 2.0 is approaching, a major revamp of my cross-platform Wysiwyg Gecko-based editor. You can find previews here for OSX, Windows and Ubuntu 16.04 (64 bits).

BlueGriffon 2.0

Warnings:

  • it's HIGHLY recommended to NOT overwrite your existing 1.7 or 1.8 version ; install it for instance in /tmp instead of /Applications
  • it's VERY HIGHLY recommended to start it creating a dedicated profile
    • open BlueGriffon.app --args -profilemanager (on OSX)
    • bluegriffon.exe -profilemanager (on Windows)
  • add-ons will NOT work with it, don't even try to install them in your test profile
  • it's a work in progress, expect bugs, issues and more

Changes:

- major revamp, you won't even recognize the app :-)
- based on a very recent version of Gecko, that was a HUGE work.
- no more floating panels, too hacky and expensive to maintain
- rendering engine support added for Blink, Servo, Vivliostyle and
Weasyprint!
- tons of debugging in *all* areas of the app
- BlueGriffon now uses the native colorpicker on OSX. Yay!!!
The native colorpicker of Windows is so weak and ugly we just can't
use it (it can't even deal with opacity...) and decided to stick
to our own implementation. On Linux, the situation is more
complicated, the colorpicker is not as ugly as the Windows' one,
but it's unfortunately too weak compared to what our own offers.
- more CSS properties handled
- helper link from each CSS property in the UI to MDN
- better templates handling
- auto-reload of html documents if modified outside of BlueGriffon
- better Markdown support
- zoom in Source View
- tech changes for future improvements: support for :active and
other dynamic pseudo-classes, support for ::before and ::after
pseudo-elements in CSS Properties; rely on Gecko's CSS lexer
instead of our own. We're also working on cool new features on
the CSS side like CSS Variables and even much cooler than that :-)

Monday 2 May 2016

BlueGriffon officially recommended by the French Government

en-US TL;DR: BlueGriffon is now officially recommended as the html editor for the French Administration in its effort to rely on and promote Free Software!

Je suis très heureux de signaler que BlueGriffon, mon éditeur Web cross-platform et Wysiwyg, est officiellement recommandé par le Socle Interministériel de Logiciels Libres pour 2016 !!! Vous trouverez la liste officielle des logiciels recommandés ici (document pdf).

Tuesday 26 April 2016

First things first

Currently implementing many new features into Postbox, I carefully read (several times) Mark Surman's recent article on Thunderbird's future. I also read Simon Phipps's report twice. Then the contract offer for a Thunderbird Architect posted by Mozilla must be read too:

... Thunderbird is facing a number of technical challenges, including but not limited to:

  • ...
  • The possible future deprecation of XUL, its current user interface technology and XPCOM, its current component technology, by Mozilla
  • ...

In practice, the last line above means for Thunderbird:

  1. rewrite the whole UI and the whole JS layer with it
  2. most probably rewrite the whole SMTP/MIME/POP/IMAP/LDAP/... layer
  3. most probably have a new Add-on layer or, far worse, no more Add-ons

Well, sorry to say, but that's a bit of a « technical challenge »... So yes, that's indeed a « fork in the road » but let's be serious a second, it's unfortunately this kind of fork; rewriting the app is not a question of if but only a question of when. Unless Thunderbird dies entirely, of course.

Evaluating potential hosts for Thunderbird and a fortiori chosing one seems to me rather difficult without first discussing the XUL/XPCOM-less future of the app, i.e. without having in hands the second milestone delivered by the Thunderbird Architect. First things first. I would also be interested in knowing how many people MoCo will dedicate to the deXULXPCOMification of Firefox, that would allow some extrapolations and some pretty solid requirements (and probably rather insurmountable...) for TB's host.

Last but not least and from a more personal point of view, I feel devastated confronting Mark's article and the Mozilla Manifesto.

Monday 8 February 2016

Inventory and Strategy

“There’s class warfare, all right, but it’s my class, the native class, that’s making war, and we’re winning.” -- Android and iOS, blatantly stolen from Warren Buffet

Firefox OS tried to bring Web apps to the mobile world and it failed. It has been brain dead - for phones - for three days and the tubes preserving its life will be turned off in May 2016. I don't believe at all myself in the IoT space being a savior for Mozilla. There are better and older competitors in that space, companies or projects that bring smaller, faster, cleaner software architectures to IoT where footprint and performance are an even more important issue than in the mobile space. Yes, this is a very fragmented market; no, I'm not sure FirefoxOS can address it and reach the critical mass. In short, I don't believe in it at all.

Maybe it's time to discuss a little bit a curse word here: strategy. What would be a strategy for the near- and long-term future for Mozilla? Of course, what's below remains entirely my own view and I'm sure some readers will find it pure delirium. I don't really mind.

To do that, let's look a little bit at what Mozilla has in hands, and let's confront that and the conclusion drawn from the previous lines: native apps have won, at least for the time being.

  • Brains! So many hyper-talented brains at Mozilla!
  • Both desktop and mobile knowledge
  • An excellent, but officially unmaintained, runtime
  • Extremely high expertise on Web Standards and implementation of Web Standards
  • Extremely high expertise on JS
  • asm.js
  • Gaia, that implements a partial GUI stack from html but limited to mobile

We also need to take a look at Mozilla's past. This is not an easy nor pleasant inventory to make but I think it must be done here and to do it, we need to go back as far in time as the Netscape era.

Technology Year(s) Result
Anya 2003 AOL (Netscape's parent company) did not want of Anya, a remote browser moving most of the CPU constraints to the server, and it died despite of being open-sourced by its author. At the same time, Opera successfully launched Opera Mini and eventually acquired its SkyFire competitor. Opera Mini has been a very successful product on legacy phones and even smartphones in areas with poor mobile connectivity.
XUL 2003- Netscape - and later Mozilla - did not see any interest in bringing XUL to Standards committees. When competitors eventually moved to XML-based languages for UI, they adopted solutions (XAML, Flex, ...) that were not interoperable with it.
Operating System 2003- A linux+Gecko Operating System is not a new idea. It was already discussed back in 2003 - yes, 2003 - at Netscape and was too often met with laughter. It was mentioned again multiple times between 2003 and 2011, without any apparent success.
Embedding 2004- Embedding has always been a poor parent in Gecko's family. Officially dropped loooong ago, it drove embedders to WebKit and then Blink. At the time embedding should have been improved, the focus was solely on Firefox for desktop. If I completely understand the rationale behind a focus on Firefox for desktop at that time, the consequences of abandoning Embedding have been seriously underestimated.
Editing 2005- Back in 2004/2005, it was clear Gecko had the best in-browser core editor on the market. Former Netscape editor peers working on Dreamweaver compared mozilla/editor and what Macromedia/Adobe had in hands. The comparison was vastly in favor of Mozilla. It was also easy to predict the aging Dreamweaver would soon need a replacement for its editor core. But editing was considered as non-essential at that time, more a burden than an asset, and no workforce was permanently assigned to it.
Developer tools 2005 In 2005, Mozilla was so completely mistaken on Developer Tools, a powerful attractor for early adopters and Web Agencies, that it wanted to get rid of the error console. At the same moment, the community was calling for more developer tools.
Runtime 2003- XULRunner has been quite successful for such a complex technology. Some rather big companies believed enough in it to implement apps that, even if you don't know their name, are still everywhere. As an example, here's at least one very large automotive group in Europe, a world-wide known brand, that uses XULRunner in all its test environments for car engines. That means all garages dealing with that brand use a XULRunner-fueled box...
But unfortunately, XULrunner was never considered as essential, up to the point its name is still a codename. For some time, the focus was instead given to GRE, a shared runtime that was doomed to fail from the very first minute.
Update: XULRunner just died...
Asian market 2005 While the Asian market was exploding, Gecko was missing a major feature: vertical writing. It prevented Asian embedders from considering Gecko as the potential rendering engine to embed in Ebook reading systems. It also closed access to the Asian market for many other usages. But vertical writing did not become an issue to fix for Mozilla until 2015.
Thunderbird 2007 Despite of growing adoption of Thunderbird in governmental organizations and some large companies, Mozilla decided to spin off Thunderbird into a Mail Corporation because it was unable to get a revenue stream from it. MailCo was eventually merged back with Mozilla and Thunderbird is again in 2015/2016 in limbos at Mozilla.
Client Customization Kit 2003- Let's be clear, the CCK has never been seen as a useful or interesting project. Maintained only by the incredible will and talent of a single external contributor, many corporations rely on it to release Firefox to their users. Mozilla had no interest in corporate users. Don't we spend only 60% of our daily time at work?
E4X 2005-2012 Everyone had high expectations about E4X and and many were ready to switch to E4X to replace painful DOM manipulations. Unfortunately, it never allowed to manipulate DOM elements (BMO bug 270553), making it totally useless. E4X support was deprecated in 2012 and removed after Firefox 17.
Prism (WebRunner) 2007-2009 Prism was a webrunner, i.e. a desktop platform to run standalone self-contained web-based apps. Call them widgets if you wish. Prism was abandoned in 2009 and replaced by Mozilla Chromeless that is itself inactive too.
Marketplace 2009 Several people called for an improved marketplace where authors could sell add-ons and standalone apps. That required a licensing mechanism and the possibility to blackbox scripting. It was never implemented that way.
Browser Ballot 2010 The BrowserChoice.eu thing was a useless battle. If it brought some users to Firefox on the Desktop, the real issue was clearly the lack of browser choice on iOS, world-wide. That issue still stands as of today.
Panorama (aka Tab Groups) 2010 When Panorama reached light, some in the mozillian community (including yours truly) said it was bloated, not extensible, not localizable, based on painful code, hard to maintain on the long run and heterogeneous with the rest of Firefox, and it was trying to change the center of gravity of the browser. Mozilla's answer came rather sharply and Panorama was retained. In late 2015, it was announced that Panorama will be retired because it's painful to maintain, is heterogeneous with the rest of Firefox and nobody uses it...
Jetpack 2010 Jetpack was a good step on the path towards HTML-based UI but a jQuery-like framework was not seen by the community as what authors needed and it missed a lot of critical things. It never really gained traction despite of being the "official" add-on way. In 2015, Mozilla announced it will implement the WebExtensions global object promoted by Google Chrome and WebExtensions is just a more modern and better integrated JetPack on steroids. It also means being Google's assistant to reach the two implementations' standardization constraint again...
Firefox OS 2011 The idea of a linux+Gecko Operating System finally touched ground. 4 years later, the project is dead for mobile.
Versioning System 2011 When Mozilla moved to faster releases for Firefox, large corporations having slower deployment processes reacted quite vocally. Mozilla replied it did not care about dinosaurs of the past. More complaints led to ESR releases.
Add-ons 2015 XUL-based add-ons have been one of the largest attractors to Firefox. AdBlock+ alone deserves kudos, but more globally, the power of XUL-based add-ons that could interact with the whole Gecko platform and all of Firefox's UI has been a huge market opener. In 2015/2016, Mozilla plans to ditch XUL-based add-ons without having a real replacement for them, feature-per-feature.
Evangelism 2015 While Google and Microsoft have built first-class tech-evangelism teams, Mozilla made all its team flee in less than 18 months. I don't know (I really don't) the reason behind that intense bleeding but I read it as a very strong warning signal.
Servo 2016 Servo is the new cool kid on the block. With parallel layout and a brand new architecture, it should allow new frontiers in the mobile world, finally unleashing the power of multicores. But instead of officially increasing the focus on Servo and decreasing the focus on Gecko, Gecko is going to benefit from Servo's rust-based components to extend its life. This is the old sustaining/disruptive paradigm from Clayton Christensen.

(I hope I did not make too many mistakes in the table above. At least, that's my personal recollection of the events. If you think I made a mistake, please let me know and I'll update the article.)

Let's be clear then: Mozilla really succeeded only three times. First, with Firefox on the desktop. Second, enabling the Add-ons ecosystem for Firefox. Third, with its deals with large search engine providers. Most of the other projects and products were eventually ditched for lack of interest, misunderstanding, time-to-market and many other reasons. Mozilla is desperately looking for a fourth major opportunity, and that opportunity can only extend the success of the first one or be entirely different.

The market constraints I see are the following:

  • Native apps have won
  • Mozilla's reputation as an embedded solution's provider among manufacturers will probably suffer a bit from Firefox OS for phones' death. BTW, it probably suffers a bit among some employees too...

Given the assets and the skills, I see then only two strategic axes for Moz:

  1. Apple must accept third-party rendering engines even if it's necessary to sue Apple.
  2. If native apps have won, Web technologies remain the most widely adopted technologies by developers of all kinds and guess what, that's exactly Mozilla's core knowledge! Let's make native apps from Web technos then.

I won't discuss item 1. I'm not a US lawyer and I'm not even a lawyer. But for item 2, here's my idea:

  1. If asm.js "provides a model closer to C/C++" (quote from asmjs.org's FAQ), it's still not possible to compile asm.js-based JavaScript into native. I suggest to define a subset of ES2015/2016 that can be compiled to native, for instance through c++, C#, obj-C and Java. I suggest to build the corresponding multi-target compiler. Before telling me it's impossible, please look at Haxe.
  2. I suggest to extend the html "dialect" Gaia implements to cross-platform native UI and submit it immediately to Standard bodies. Think Qt's ubiquity. The idea is not to show native-like (or even native) UI inside a browser window... The idea is to directly generate browser-less native UI from a html-based UI language, CSS and JS that can deal with all platform's UI elements. System menus, dock, icons, windows, popups, notifications, drawers, trees, buttons, whatever. Even if compiled, the UI should be DOM-modifyable just like XUL is today.
  3. WebComponents are ugly, and Google-centric. So many people think that and so few dare saying it... Implementing them in Gecko acknowledges the power of Gmail and other Google tools but WebComponents remain ugly and make Mozilla a follower. I understand why Firefox needs it. But for my purpose, a simpler and certainly cleaner way to componentize and compile (see item 1) the behaviours of these components to native would be better.
  4. Build a cross-platform cross-device html+CSS+JS-based compiler to native apps from the above. Should be dead simple to install and use. A newbie should be able to get a native "Hello World!" native app in minutes from a trivial html document. When a browser's included in the UI, make Gecko (or Servo) the default choice.
  5. Have a build farm where such html+CSS+JS are built for all platforms. Sell that service. Mozilla already knows pretty well how to do build farms.

That plan addresses:

  • Runtime requests
  • Embedding would become almost trivial, and far easier than Chromium Embedded Framework anyway... That will be a huge market opener.
  • XUL-less future for Firefox on Desktop and possibly even Thunderbird
  • XUL-less future for add-ons
  • unique source for web-based app and native app, whatever the platform and the device
  • far greater performance on mobile
  • A more powerful basis for Gaia's future
  • JavaScript is currently always readable through a few tools, from the Console to the JS debugger and app authors don't want that.
  • a very powerful basis for Gaming, from html and script
  • More market share for Gecko and/or Servo
  • New revenue stream.

There are no real competitors here. All other players in that field use a runtime that does not completely compile script to native, or are not based on Web Standards, or they're not really ubiquitous.

I wish the next-generation native source editor, the next-gen native Skype app, the next-gen native text processor, the next-gen native online and offline twitter client, the next native Faecbook app, the next native video or 3D scene editor, etc. could be written in html+CSS+ECMAScript and compiled to native and if they embed a browser, let be it a Mozilla browser if that's allowed by the platform.

As I wrote at the top of this post, you may find the above unfeasible, dead stupid, crazy, arrogant, expensive, whatever. Fine by me. Yes, as a strategy document, that's rather light w/o figures, market studies, cost studies, and so on. Absolutely, totally agreed. Only allow me to think out loud, and please do the same. I do because I care.

Updates:

  • E4X added
  • update on Jetpack, based on feedback from Laurent Jouanneau
  • update on Versioning and ESR, based on feedback from Fabrice Desré (see comments below)
  • XULrunner has died...

Clarification: I'm not proposing to do semi-"compilation" of html à la Apache Cordova. I suggest to turn a well chosen subset of ES2015 into really native app and that's entirely different.

Friday 29 January 2016

Google, BlueGriffon.org and blacklists

Several painful things happened to bluegriffon.org yesterday... In chronological order:

  1. during my morning, two users reported that their browser did not let them reach the downloads section of bluegriffon.org without a security warning. I could not see it myself from here, whatever the browser or the platform.
  2. during the evening, I could see the warning using Chrome on OS X
  3. apparently, and if I believe the "Search Console", Google thought two files in my web repository of releases are infected. I launched a complete verification of the whole web site and ran all the software releases through three anti-virus systems (Sophos, Avast and AVG) and an anti-adware system. Nothing at all to report. No infection, no malware, no adware, nothing.
  4. since this was my only option, I deleted the two reported files from my server. Just for the record, the timestamps were unchanged, and I even verified the files were precisely the ones I uploaded in january and april 2012. Yes, 2012... Yesterday, without being touched/modified in any manner during the last four years, they were erroneously reported infected.
  5. this morning, Firefox also reports a security warning on most large sections of BlueGriffon.org and its Downloads section. I guess Firefox is also using the Google blacklist. Just for the record, both Spamhaus and CBL have nothing to say about bluegriffon.org...
  6. the Google Search Console now reports my site is ok but Firefox still reports it unsecure, ahem.

I need to draw a few conclusions here:

  • Google does not tell you how the reported files are unsecure, which is really lame. The online tool they provide to "analyze" a web site did not help at all.
  • Since all my antivir/antiadware declared all files in my repo clean, I had absolutely no option but to delete the files that are now missing from my repo
  • two reported files in bluegriffon.org/freshmeat/1.4/ and bluegriffon.org/freshmeat/1.5.1/ led to blacklisting of all of bluegriffon.org/freshmeat and that's hundreds of files... Hey guys, we are and you are programmers, right? Sure you can do better than that?
  • during more than one day, customers fled from bluegriffon.org because of these security warnings, security warnings I consider as fake reports. Since no public antimalware app could find anything to say about my files, I am suspecting a fake report of human origin. How such a report can reach the blacklist when files are reported safe by four up-to-date antimalware apps and w/o infection information reported to the webmaster is far beyond my understanding.
  • blacklists are a tool that can be harmful to businesses if they're not well managed.

Update: oh I and forgot one thing: during the evening, Earthlink.net blacklisted one of the Mail Transport Agents of Dreamhost. Not, my email address, that whole SMTP gateway at Dreamhost... So all my emails to one of my customers bounced and I can't even let her know some crucial information. I suppose thousands at Dreamhost are impacted. I reported the issue to both Earthlink and DH, of course.

Friday 11 September 2015

Death of XUL-based add-ons to Firefox

I will not discuss here right now the big image of the message sent a few weeks ago (although my company is deeply, very deeply worried about it) but I would like instead to dive into a major technical detail that seems to me left blatantly unresolved: the XUL tree element was introduced to handle very long lists of items with performance. Add-ons touching bookmarks, lists of URLs, list of email adresses, contacts, anti-spam lists, advertisement blocking lists and more all need a performant tree solution.

As far as I am concerned, there is nothing on the html side approaching the performance of the XUL tree for very long lists. Having no replacement for it before the removal of XUL-based add-ons is only a death signal sent to all the add-ons needing the XUL tree, and almost a "we don't care about you" signal sent to the authors of these add-ons. From an ecosystem's point of view, I find it purely suicidal.

So I have a question: what's the plan for the limited number of XUL elements that have no current replacement in html for deep technical reasons?

Update: yes, there are some OSS packages to deal with trees in html, but until the XUL tree is removed from Firefox's UI, how do we deal with it if access to the XUL element is not reachable from add-ons?

Wednesday 4 February 2015

In praise of Tristan Nitot

There's a high probability Tristan and I met when we were kids. We were both hanging around the same places at the same time to have access to computers. We met again during the early years of Netscape, while I was leading everything web-related at Électricité de France. Later, he was of course the first one to greet Peter and I when we joined as sherpas in november 2000.

On the 15th of july 2003, Tristan, Peter and myself were on the "special" conference call about a "reorganization". In the next minutes, all our colleagues from the US sent a farewell message and Netscape was no more. After the summer break, Tristan, Peter and myself met at Peter's apartment in Paris to discuss our future. I suggested to take advantage of the OSS nature of Mozilla and launch a software company, but Tristan and Peter had only one idea in mind and it was already called "Mozilla Europe"... I eventually launched "Disruptive Innovations" alone while they remained focus on their project.

Tristan and Peter worked incredibly hard to achieve that, giving Mozilla a unique and powerful presence on the Old Continent. After the official launch of Mozilla Europe, Tristan became ubiquitous. He was so present in European media I started the Tristant-Nitot-Tracker as a joke. Newspapers, Web magazines, radios, television channels, there has not been a single day between 2003 and 2011 without multiple appearances of Tristan everywhere in Europe, and sometimes beyond. I never understood how Tristan found the time and energy to make Mozilla so visible in the media here.

The face of Mozilla Europe is - we'll soon have to say was - Tristan. There's that classic and completely stupid french proverb that says "nobody is irreplaceable"... If someone you hired is replaceable, it only means you have to improve your hiring process. Successes are built with irreplaceable people.

Tristan is irreplaceable, because he's not only giving work, skills, energy and talent. He's doing it in a way that is from my perspective unique: tons of humor in absolutely all circumstances, extreme dedication, convinced and convincing spirit, ability to discuss with absolutely anyone from geeks to politicians, outstanding spoken and written communication, indisputable loyalty, inspiring everyone.

I'm not a Mozilla employee. But Tristan has been, as Mozilla Europe's leader, a crucial person to my company. So let me thank him deeply and sincerely for all the fish he gave me, all the fish he gave us all.

Tristan, all I can say is that you now have more free time to ride your motorbike to come have lunch with me in Saint-Germain! Best of luck for the future, the coaching and the book!

Tuesday 15 April 2014

Welcome cbeard

Among Mozillians, there is a small (not too small, in fact..) group of people who were already here before 15-jul-2003. After that date, we saw old-time contributors rejoin Mozilla one by one, and new hires too, something we had forgotten about since the 2002 Netscape layoffs. Chris Beard was one of them, at the end of 2004 IIRC (time flies, holy cow, time flies...). If old-time Mozillians saw a necessary little shift in the local culture because of these new hires, it was clearly not the case with cbeard, who adapted so well to Mozilla we immediately used his IRC nick to mention him. Having a vision, dealing very well with the community, always open to discussion, leading new projects, highly respected, I'm glad he was appointed interim CEO. Welcome Chris!

Friday 4 April 2014

Sad day

It's a very sad day. I just landed in San Francisco and learned about Brendan's resignation and I am totally shocked. I have very mixed feelings today about the "Mozilla Community" and I am not sure I like what it became.

Mitchell wrote the following:

We welcome contributions from everyone regardless of age, culture, ethnicity, gender, gender-identity, language, race, sexual orientation, geographical location and religious views. Mozilla supports equality for all.

Yes, we do. But I think we also value democracy, and what happened during the last days seems to be a negation of democracy. One should be able to express legal opinions without having to face a witch-hunt-like repression.

Today, Mozilla is weaker because of this witch hunt. Mozilla, who is standing for the better of everyone on the Web, is weaker because some people thought it would be stronger without Brendan. This is ridiculous, this is a shame, this is a scandal. A small step for a few, a giant leap back for the Web.

Who said "Mozilla Community"? Who said Openness? Pfffff. I've been a Mozillian for fourteen years and I'm not even sure I still recognize myself in today's Mozilla Community. Well done guys, well done. What's the next step? 100% political correctness? Is it still possible to have a legally valid personal opinion while being at Mozilla and express it in public?

Personal message to Brendan : Paris in April and May can be such a wonderful city. Come over here for a break, I have a few good restaurants, bars and unknown superb monuments to show you... With all my thoughts and support.

"I may disagree with what you have to say, but I shall defend, to the death, your right to say it"

(comments disallowed, I still have in mind the hate messages left on this blog last week)

Update: I perfectly understood the fact Brendan resigned because of the external pressure. But that external pressure would probably not have existed at all without the original internal pressure. Reminding Brendan's position was, I already said it, pointing an index at him. Being an employee and explicitly saying in public "I don't support Brendan as CEO because of his prop8 support" triggered the rest. That's where I don't understand the Mozilla Community any more.

Tuesday 25 March 2014

Welcome Brendan!

I could not be happier to see Brendan Eich become the new CEO of Mozilla :-)

Brendan has a vision, a unique vision that made Mozilla what it is today, and he is a great leader, respected all over the world, all over our geek's world. Reliable, hyper-smart, friendly and knowing perfectly - of course - the organization he co-founded.

But there is one thing I would like to come back to, because I read something too disruptive to me on planet.mozilla.org: yes, Brendan donated to the anti-marriage equality Prop. 8 campaign in California. I don't like, I don't like at all seeing that pop up again in public space because that's pointing an index at someone for his/her beliefs, that's something that should not happen in a community like ours. When Brendan was under attack, two years ago, I sent him my support. Not a support to his opinion, but a support to his freedom of opinion and freedom of expression of that opinion through all legal means. Including a donation.

Seen from Europe with a European point of view, I do not understand how one can complain about it. Mozilla promotes openness and freedom of choice, that's its Manifesto, that's our core values, why most of us contribute to Mozilla. I want that openness and freedom of choice to be a deep, anchored value of the whole Mozilla community. With that in mind, I entirely respect Brendan's personal choice, that was exposed only because of the Californian law and was attached to the name of Mozilla only because that law makes it mandatory to mention the affiliation of the donator above a given level of donation IIRC. I trust - we all trust - Brendan to be able to deal with the whole community - employees or contributors - equally, whatever their own beliefs or personal choices. I met Brendan 14 years ago and have never seen him behave in a different way.

The Mozilla community at large represents quite well the diversity of thoughts on the globe. We have people who love fire weapons; I don't like it but that's legal in their countries. We have people supporting death penalty; I hate it but that's legal in their countries. We have people from all political sides, including extremes; I don't understand it but I accept it. We have people based in countries one could easily qualify as antidemocratic and who support their regime; yes, diversity is a marker of the human kind. And we have people who have diverging opinions about major societal issues, within the limits of the law, absolutely. We even have true nerds, barely social, who can't understand what's a private and family life. So what? Again, seen from Europe and with a European point of view, not a problem at all.

Pointing an index at someone of our community for his/her beliefs can only have one side-effect: people will stop expressing their opinions because they will be afraid of the kickback, people will be blamed in public for legal behaviours and that's totally unacceptable to me as a European. That's not the world I want to live in, that's not my concept of democracy and freedom of opinion/speech. That's not the Mozilla I want. Brendan, I value your opinion, and that does not say anything about my agreement or disagreement with your opinion itself.

We, as a community, cannot promote openness and freedom of choice without a deep respect for individual beliefs. A reminder of Brendan's personal choices years ago is unfair and violates too much for me the core values of the Mozilla community. I am writing this article because I want it to be the very last time we read about it in public space. FWIW, and given the long chats we had about it in Europe two years ago, I think the above is a quite widely shared opinion in the European Mozilla community.

Welcome Brendan, and long life to Moz.

Update: following a private message, I want to say that, yes, I carefully read the message that triggered my response above. My take is that even in a positive message about Brendan, reminding the Prop8 story is putting, again, an index at him. And I feel it is just totally wrong because his opinion is not less respectable than others.

Update again: I did not intend to let the comments open here, my bad. What I feared did happen: hate messages. Closing comments then. My blog, my prerogative, and the French law makes me accountable for all comments on this blog. Period. Sorry for the people who left polite messages, agreeing or disagreeing; I hope you understand.

- page 1 of 37