Thunderbird and Institutional users

Standard

During my trip to Paris last week, I met with a set of representatives from public sector institutions which are deploying Thunderbird to large sets of users, as part of a larger (and long-term) move towards open source and open standards. It was fascinating to find out what their goals were, what they’d been able to achieve, what hurdles they were still facing, and how we might be able to work together.

User control vs. centralized responsibility

In enterprises, people expect their IT department to help them if they have problems using the software they use for work. Especially if the IT told them to use Thunderbird, that means that the same IT department has to be able to support it, in the local language, using customized, organization-specific documentation. In that kind of scenario, it’s seen as important that the IT department has the right level of control over exactly what version of Thunderbird is in use. Many of the things that make both Firefox and Thunderbird wonderful consumer products end up inadvertently making it harder for those IT administrators to support it. Auto-update, which is key to keeping the web safe and any desktop application up to date especially with security fixes but also with continuous improvement, is a possible time-bomb for the people handling support in large installations. The ability for end-users to install extensions which solve a need they have as individuals, if it breaks core functionality in the product, and results in calls to tech support, end up hurting the product.

I like these topics because I think that while on the surface they seem like points of conflict between the end-user focus of Mozilla products and enterprise deployments, longer term I see opportunities for progress on both “sides”.

  • The AUS technologies that Mozilla built to support updating hundreds of millions of users at once can be redeployed inside enterprises to give them the control they need and facilitating faster update cycles.
  • The support concerns that IT managers have about extensions aren’t that different than the concerns the Firefox team probably has about possible “rogue” extensions, and together I suspect both groups can help each other.
  • Improving the configuration experience for Thunderbird will help the home user as much as the IT administrator.

Annoyingly for me, when these institutions distribute Thunderbird, the update-checking mechanism is deliberately disabled as part of a global security policy, meaning that not only do bug fix releases like last week’s 2.0.0.9 don’t reach those users, but I have no way of even guessing how many such users there are! This makes understanding user trends like total user population, the speed at which users upgrade, etc., much harder.

The power of extensions

Extensions are great. Everyone says it, and they’re usually referring to Firefox extensions. But I believe the potential power of extensions is even greater in the world of messaging than in the world of the web. Browsers are made to interact with websites, most of which try very hard to make the experience be the same across browsers. Firefox extensions, in some way, fight the dominant mode of the web. In a messaging client, however, extensions can work hand-in-hand with server-side technology, or the sometimes very idiosyncratic needs of a specific organization. I was shown several fascinating Thunderbird extensions implementing CRM-like features, global account management features, integration with custom calendaring software, specialized mail handling, etc. In these organizations, the email client is deeply customized to fit the local needs, and the Mozilla platform’s story on extensibility is unbeatable. There are definite issues in the Thunderbird extensions story, but there are also low-hanging fruit there.

Pre-configuration and mass deployment

If you think Thunderbird is hard to configure right now (I do), imagine being responsible for configuring 80,000 desktops for non-technical users! There are some systems in place already, but I understand there are still issues that make it a challenge to deploy Thunderbird in such large installations. This is likely more problematic for Thunderbird than for Firefox, as there are more environmental settings involved in email than in web browsing. Indeed, several of these enterprises deploy Thunderbird but not Firefox, countering the notion that Firefox is always the “lead”.

Opportunities for peer-help and a Thunderbird consultant market

If last week’s conversations are any indication, there are likely hundreds of individuals responsible for hundreds of thousands and maybe soon millions of Thunderbird installations, and yet they likely don’t know each other. One of them may even have solved a problem that the others are struggling with, or don’t yet know they’ll have. Today, it’s hard for these people to find each other. That’s a problem we should be able to solve, using basic tools like Wikis and a dedicated mailing list/newsgroup.

Another opportunity is that institutional users tend to have core competencies which don’t include writing Thunderbird patches or extensions. There are, however, a growing number of small and not-so-small service companies which are learning how to do that better and better. There’s a market gap there, especially as MailCo itself is not likely to build custom extensions, for example. Given that my number one goal is to facilitate adoption of Thunderbird, I want to facilitate the creation of a market for custom Thunderbird extensions, and for fixes to bugs which may be urgent for some but which we may not get to soon enough. If you’re interested in either side of that marketplace, let me know.

The debate is different

More specifically, the people I talked to represent a new type of customer for me. Thanks to years of evangelism by people like Tristan Nitot, I didn’t have to argue for releasing code under compatible open source licenses, or for working hard to avoid the need for forks. Even more interesting is the fact that in North America, when I describe what I’m up to, the most common first question is “but how will you make money?”, while at least in one big meeting with lots of people, no one asked. The people I talked to were more interested in the non-financial aspects of the Mozilla endeavor. That money is being made is fine, but one gets the feeling that it’s not a particular point of interest by users or pride by community members. Knowing that Mozilla is willing to take on fights that no one else is willing to take on, that’s inspiring and exciting, and worth taking some risks for.

Next Steps

The single most common complaint I heard regarding Mozilla’s handling of Thunderbird is not enough communications. Communications about everything from the roadmap (on my plate), the APIs for extensions (FUEL for Thunderbird anyone?), the wiki, the strategy to change the world, and more. I agree wholeheartedly, even with the criticism that I should blog more. Mea culpa, will try to do more in the coming weeks.

9 thoughts on “Thunderbird and Institutional users

  1. Patrick

    > Even more interesting is the fact that in North America, when I describe what I’m up to, the most common first question is “but how will you make money?”, while at least in one big meeting with lots of people, no one asked.

    Man, I adore this sentence. It’s my headline on various social networks now :)

  2. I asked a the mailnews hackers and extension authors I met last FOSDEM about a FUEL-for-Thunderbird, there wasn’t anything canonical. But maybe that was because there wasn’t too much experience with FUEL yet. I had THULE as name, just to replace F with TH and randomly reorder ;-)

  3. Member of one of these public institutions, I am also very concern about not applying security updates.

    Unfortunately, security updates do not really exist. Instead it exists Thunderbird updates coming with a set of new features, bug fixes and security updates. It means that these releases may bring new behaviour that break your information system. Example : Thunderbird v1.5.0 comes with a modified LDAP search system that breaks our LDAP queries … on a set of 80 000 PCs !

    May we think about an EMMERGENCY security channel updates for ABSOLUTLY required security updates and a common purpose update channel that can brings new features or features evolution.

  4. Well…there’s something else to keep in mind about updates via AUS – you have to have admin rights to install updates. Mozilla seems to forget about this, in a large pursuit of home users. There is currently *no* Mozilla-documented way to update Firefox or Thunderbird system-wide on a managed network. (That is, unless a daemon was running on the computer, it’s obvious there’s little way for a non-admin user to install the update, but there should be some way for the sysadmin to apply it to his or her network’s computers.)

    Seemingly, the logical way to do this would be MSIs, but this has been thoroughly ignored for the last few years, much to my embarrassment when I said “Oh, they’re supposed to be coming out with that in 1.5.” (Fx) Is it there yet? No! Is there a way to manage settings across a network? Not easily. (There’s some things on the wiki.m.o/Enterprise page, but this is for /large/ departments who are happy using cryptic tools and repackaging Firefox — and there’s *no* discussion of Thunderbird.) Also, it may be a monopoly situation, but one thing M$ has decidedly in its favor is that WSUS updates IE & Outlook/OE.

    So…that may have been a bit of a tangent about updating…but please consider it as a bit of background from someone ‘in the trenches’ on the reasons why some Mozilla products aren’t implemented or updated on an Enterprise level. Thanks for your thorough review of Thunderbird matters – it’s good to see one of my favorite apps getting some good care. :-)

  5. This is just a random idea. What if the installer looked for a file, say tbinstall.ini. If it does not find the file then it just installs like normal. If it does it reads the config options and installs based on those configs. The configs could do things like turn off autoupdate, disable extensions and/or themes, etc. This would allow deployment with specific department specific options easier.
    Extensions that allowed remote functionality, such as remote updates pushed out and remote extensions/themes pushed out, could also be very usable for large organisations deploying and maintaining TB.
    One of the advantages of maintaining TB on Debian based systems is that updates can be pushed out by IT through package management, allowing centralised control.

  6. We appreciate the updates. Here in Japan we have a number of large corporations and universities who have deployed TB to user bases in the high 4 and 5 digits. Communication about Thunderbird in Japanese is even harder to find than it is in English, fwiw.

    I agree that some new way for TB users to communicate with each other, especially around large deployments, would be valuable.

    We look forward to your visit to Japan :)

  7. My insisting on home vs business market was exactly because of this. Unfortunately, our communication didn’t go that far, otherwise you wouldn’t have to travel to Europe just to hear that ;).

    I would like to bring some more issues. Auto-update is not that bad thing, it is just bad thing as it doesn’t work on limited accounts. Small and medium business may actually prefer auto-update to some custom AUS solution.

    But there is a catch, for small and even more for big businesses. Platform needs to stay compatible over the time. Extensions once build must work for ever and not break every once a year. It is too expensive for businesses, specially if they have custom built extensions. Unfortunately Firefox is developed other way, which makes me wonder whether Firefox and Thunderbird could have shared code at all…

    Other than that there are also some catches:
    * msi installer needed for medium and large business, never really made into firefox
    * extensions deployment solution needed
    * some policies to lock some options centrally

    What is the worse, completing this list won’t take Thunderbird into the enterprises. It is just the list that must be completed in order to make IT people even seriously look at Thunderbird.

  8. On communications: a while back you blogged that you were going to concentrate on employing developers, not non-developers. I see this as a bit of a reflection of Mozilla’s developer-led culture. It’s fine in the beginning, but there are other skills and other needs, and without them, developers as well as others suffer. Communications will be just one of them. All IMHO!

  9. on markets for code, or task markets: there are some enabling technologies needed for markets to emerge. One is “the money.” There needs to be a common money that is fixed and worldwide. It might be Paypal for example, but bank dollars aren’t fluid enough.

    Next issue is dispute resolution. There will be needed a way to deal with the subjective question of “I delivered, no you didn’t, did, didn’t …”

    Another requirement is a templating system for creating the specifications or requirements for the code required. This needs to be common so that people can search (both sides of the market) and also open enough to allow the wide range of software needs to be expressed. It is a little bit like bugzilla, tuned to a different purpose.

    Another element is a legally binding contract formation. This requires both a user agreement of some form, and a contract formation signal. That is, at some point the music stops, the dancing stops and work begins. That has to be very clear and also very efficient. See also dispute resolution :)

    Normally these elements and the market built out of them emerge out of strange and unpredictable beginnings. There are ways to create them (we call this financial cryptography), but because of the needs to introduce such big and life-changing elements all at once, most efforts to build “task markets” have failed. OTOH, it is definately one of the more fun things to try!

Comments are closed.