SOGo: Thunderbird-inspired and Thunderbird-compatible Groupware

I’m slowly learning about the world of groupware, which I’m thinking for the moment as access to shared resources (folders, address books, calendars) and coordination features like meeting scheduling. It’s a world which is dominated by Exchange, especially in North America and especially in companies, especially in larger companies. There are alternatives, however, including some which have some interesting ties to Thunderbird. One notable such project is SOGo, which stands for Scalable (not a great name IMO, but let’s judge a book by its title😉. SOGo came to my attention for a couple of reasons — first, because they built a web front-end to their system which is a fairly close clone of the Thunderbird UI, second, because the same team built an extension to Thunderbird and Lightning to add support for more groupware-ish features like access to free-busy information. I’m hoping that the SOGo team and the Calendar team will be able to join forces to make both projects stronger. They’ve just announced their second RC of version 1.0, so if you’re interested in this kind of project, do check it out.

Calendar needs you!

As I’ve mentioned before, the Mozilla Calendar project, which includes the Lightning calendar extension to Thunderbird, is moving right along. It’s currently at version 0.7, heading towards a 0.8 release ASAP. I’ve asked the Calendar team how I can help, and the answer has been clear — they need more developers. So if you’ve been sitting on the sidelines of either Calendar or Thunderbird and you want some suggestions as to where you could help, check out this bug list. Moving Lightning forward is one of the easiest ways to help move Thunderbird forward — the codebase is in quite a healthy state, there’s an active group of daily contributors (check out the #calendar IRC channel to meet them), the roadmap is clear, and the bugs are clearly marked.

Request for Comments for Thunderbird’s FUEL equivalent, STEEL

One of the big topics that I’m planning to devote a fair bit of MailCo energy towards is to help the Thunderbird extension “scene”. Part of that is making it easier to make extensions for Thunderbird, with better docs, cleaner APIs where necessary, etc. One of the dreams that people have mentioned repeatedly was “wouldn’t it be great to have a FUEL for Thunderbird”, referring to John Resig & Mark Finkle’s library that makes writing extensions for Firefox much easier.

Well, imagine my joy when Joey Minta posted on the newsgroup that he’s started just that. He’s looking for comments on the API, so check it out and pitch in!


As soon as possible I’d like to post something like this post by Mark Hamburg, about Adobe Lightroom’s goals. My challenge of course is that I’ll have to make those goals public before shipping, not after, and I’ll have to work out what those goals should be in a transparent global room with thousands of interested onlookers.

I wonder how many of Lightroom’s goals as stated by Mark should be Lightroom specific, and how many are true of any piece of software.

Thunderbird and Institutional users

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 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.

Open source peer-to-peer transportation systems

.flickr-photo { border: solid 2px #000000; }
.flickr-yourcomment { }
.flickr-frame { text-align: left; padding: 3px; }
.flickr-caption { font-size: 50%; margin-top: 0px; }

I’m building a list of reactions to my Paris visit, touching on cultural differences in the world of email, open source, the fascinating things that various folks have done with Thunderbird in France, imperialism, and other topics, but I wanted to make sure to show this picture. There’s a transportation strike in Paris this week (great timing on my part, as usual), which makes getting around a bit harder than usual, although I tend to walk around as much as is reasonable anyway given how nice it is to do so in Paris.

Today though, I was running late for an appointment, so I hopped on one of these puppies:

These slightly frumpy 3-gear city bikes are some of the 20,000 “Velib” that a company has placed in 1000 different locations throughout Paris in exchange for advertising rights. The system is optimized for using bikes as a quick and easy way to move around short distances. With a subscription (ranging from 1 euro for a day to 29 euros for a year), trips of 1/2 hour or less are free, with costs climbing for longer rentals, thereby ensuring that people don’t hog the bikes. Apart from reports of some people using padlocks to “reserve” the bikes in anticipation of the strike, it seems to work great. The stations I see tend to have at least some bikes in them (this one was full, which is actually a problem if you’re trying to return a bike). On Wednesday there were 159,000 trips recorded .

It was a fun bike ride. In addition to the simple pleasure of zipping past cars through sunny Paris streets, there’s something about riding a “Velib” for the first time which reminds me of using open source software for the first time. A joyful personal experience based on a structured shared asset, with positive environmental consequences.