The OpenDocument XML.org web site is not longer accepting new posts. Information on this page is preserved for legacy purposes only. For current information on ODF, please see the OASIS OpenDocument Technical Committee.
Welcome to the July installment of Eyes & Ears. This month we have quite a long mix by Chicane. I love most of the tracks released by what was at first a collective and is now one DJ. It seems there were a few years of inactivity in between their three main releases (Far from the maddening crowds, their best one I think, Behind the Sun and the Somersault); now Chicane is back, most notably with its Sun:Sets sessions.
Here’s the volume 1, but you can directly access to the other 7 volumes on SoundCloud:
Another great release of this month is the latest album of the Russian wonder DJ Moko, Future Hope. I’ve got the full album below:
An Eyes & Ears session would not be complete without at least one book suggestion. This month I’m reading the White Dominican by Gustav Meyrink. It’s an intensely spiritual story about an orphan boy with a deep sense of spirituality and mystery in Germany who meets a Dominican monk, and how he will come to travel along a few paths less travelled.
Enjoy the beginning of the Summer Season!
It has been a while since I have discussed open standards here, even though I have alluded to them in passing. There are currently a number of initiatives and policies ongoing at the European level that are bringing this topic back on the table, especially with regard to public procurement practices. Why does it matter? Because it shows that beyond any kind of advantage, convenience, or the mere ability to have a real choice of IT solutions suppliers, open standards are considered by much of the private and public sectors as some sort of nuisance.
Depending on how you see it, the “battle” for open standards is either won, or it is still ongoing at the normative level (think about the DRM injection in HTML5 that happened at the W3C). Open Standards, more than ever before, rule the IT industry and the Internet. Cloud technologies rely on open standards to a large extent; purchasing music tracks online lets you increasingly download open file formats that, while they may not be exactly standardized themselves, have open specifications and are unencumbered wiith digital restrictions management (yes, that’s how DRM should really be called).
On the other hand, desktop technologies are still a major issue. One could assume it is because of the stranghold of an entrenched monopoly, and perhaps it is, to some extent. We are in 2014 however, and both open standards and FOSS desktop offerings (LibreOffice, Firefox, Linux distributions for the desktop) are legion. These have a real uptake among what is often referred to as the consumers’ market and that’s great news, but when it comes to what’s going on in the workplace, there seems to be little choice aside the MS Office + Outlook + SharePoint on Windows stack. Why is that the case? Why is the European Commission still trying to tackle the problem in 2014?
The Desktop is traumatizing
And more exactly, change is traumatizing. Technology changes very quickly, but the more structured the workplace you have, the less adaptative it will be for IT solutions. If you add the specific culture of the organization that can sometimes be more or less rigid and centered on one vertical industry, you will find long cycles of deployment for any kind of IT technologies and a reluctance to “switch” to a new brand or a new kind of software. This could not be more true on the desktop. I’ve been writing this for years here, but there are reasons for that: the desktop is used by pretty much everyone in the organization. While it is somewhat changing with the arrival of tablets and smartphones, desktops are here to stay. The problem is that desktops are very complex systems -offering a graphical interface and tools for pretty much every kind of uses and situations one can imagine- and as such come with more quirks than other devices and other software platforms. These quirks end up being noticed by the users, who most of the time are not computer-savy and will be reluctant to change. Worse, their skills will directly or indirectly be challenged by the change. This fear of change ends up being passed on to the CIO level, who has to make the purchase decision, and does not want to be hold liable for having chosen that “weird, so called innovative solution no one gets”.
Just like with any fear, we are not talking about rationality. In 2014, people who use Twitter on a daily basis will shout if their desktop has changed overnight. It is not a good practice to do that kind of brutal change anyway, but the very concept of microblogging was unknown to them 5 years ago. They embraced it with no trouble at all. Their desktop, however, is a holy land, the solitaire game and their office suite their hallowed relics.
Open Standards can sometimes be hard to understand
It is hard enough for people to understand what protocols such as TCP/IP do. These open standards however are invisible to most of them, even if they’re using them on a daily basis. Other open standards, such as OpenDocument Format, are probably not conceivable by some people, who think that an office document is “an extension of Microsoft Office”. I have even heard of teachers, here in France, who refused to even mention ODF because such a thing “could not possibly exist”. The conceptual distinction between a file and an application has not permeated much, even in the twenty first century.
Yet, open standards are the way to go. They may not always be the superior technology, but they offer a level playing field for the industry to build on and innovate with. The Internet has been built on this, so does cloud computing. Desktop solutions are no different. Using open standards brings you back in control of your suppliers and IT infrastructure; it ultimately helps reducing costs and keep your data safe, reusable and sustainable for dozens of year to come. You can read more about it in the excellent article by Bjorn Lundell published here. Ultimately, the lock-in of the desktop solutions will stop being meaningful as the state of the art will change so much the solutions that are seen as essential today will stop being that important. But the documents, the images, the data, all your content will still be locked in undocumented file formats that need to be reverse-engineered in order to edit them. No one should build such a silo for the future and then throw away the key. That’s what has been happening for more than a decade on the desktop, unfortunately. Where does that lead us? I think we can already see where: vendor lock-in is here to stay on a more or less large extent; but so are open standards. There will then be people who are stuck with their vendors and constantly handle the legacy; there will be the others, who actually enable information technologies to help them innovate. For them, the story has only started.
If you were to count up all of the earnest articles, blog entries, and even Colbert Report routines that have been dedicated to the Amazon vs. Hatchette dispute, well, you wouldn't have an accurate number, because more would have been written while you were counting. Curiously enough, al...
Friday and Saturday were great days of excitement: The LibreOffice Hackfest in Montreuil, organized by the Document Foundation and Simplon.co, a “startup factory” born in a large struggling -yet charming- urban neighbourhood next to Paris, gathered active developers of the project and members of Simplon Co. The hackfest was a success and a great opportunity to work together on various tasks.
Developers were able to work on OOXML filters, performance improvements, hacking on the integration of the Firebird as the database behind the Base module…
…. as well as interacting with members of the french community and students from Simplon Co.
Less technical particpants (such as yours truly) had the opportunity to work on the Bern Conference planning, the messaging of the upcoming LibreOffice releases, and explain how the LibreOffice project works to our guests. And of course, food and drinks were not forgotten during the Friday evening…
Thank you everyone who participated, to Simplon Co. for their hospitality, to our dev team, to Collabora, and to the volunteers who made this event possible. Santé!
As a developer who makes heavy use of HTML5, what immediately struck me was this statement, made starting at about 20:20 into the video:
"Last year at I/O we announced Polymer, which is a powerful new UI library for the web.
Today, we're bringing you all of the Material Design capabilities to the web through Polymer. [Applause] As a web developer, you'll be able to build applications out of Material Design building blocks with all of the same surfaces, bold graphics, and smooth animations at 60 frames per second. [More applause, followed by the speaker smiling and ad-libbing: "That was good..."]
So, between the L preview and Polymer, you can bring the same, rich, fluid Material Design to every screen."
Wow, I thought, Google not only designed a mobile UI for their Java-driven devices, they went to the trouble of also then building it in HTML5 for web apps (mobile and desktop).
I was wrong. I did some looking at the documentation for Polymer, and in the FAQ I found this (emphasis added):
How is Polymer related to material design?
Polymer is the embodiment of material design for the web. The Polymer team works closely with the design teams behind material design. In fact, Polymer played a key role in material design's development: it was used to quickly prototype and iterate on design concepts. The material design components are still a work in progress, but will mature over the coming months.
So, the HTML5 version wasn't created after the native versions. It was the prototyping environment before the native code.
This is a great model to follow: Prototype, iterate, and even first ship, in HTML5. Once you know what you need, if necessary, take the time to do native code. This doesn't just apply to the old desktop (as it has for years). It also applies to today's polished, fluid mobile world.
As a developer who is closely connected to a system that produces HTML5, and that aids in rapid prototyping, I was delighted. Here are some of the leading-edge mobile developers, and they found that HTML5 has the power to do what they want, and do it quickly enough for the demands of the iterative design and testing that is so important in the mobile world. After hearing so many people claiming that "they hear" that HTML5 doesn't have the power for serious mobile applications, it was vindication to hear of people who actually build things choosing to go the HTML5 route, even when cost clearly wasn't the object, and succeeding.
I guess it's time for a new moble-related tag: #HTML5first.
There is something truly comforting in observing vibrant communities such as the one of LibreOffice. The project is growing, not just in developers but in adoption as well: more users as well as more localizations are a visible sign inside the project. All this is not only thanks to our good name and reputation; it is because as we are well into our fourth year of existence, it is important to realize that communities scale as much as their production and communication infrastructure is able to grow and perform its duties. Two words are of peculiar importance here: Production & Communication. In a Free and Open Source Software project, these two functions are tightly connected. The project enables the software production at the same time it enables communications between its members. Conversely, you cannot have a developers, users, or QA mailing list for instance, without relying on an existing code repository of some sort, otherwise you’re only doing vapourware (and vapourware only needs a database of press contacts, but no real mailing list).
Scaling up the production and communication infrastructure ultimately amounts to improve the software quality, featureset or both, and making the project contributors communicate more effectively, in between themselves and outside of the project as well. We have entered a period of fast growth inside LibreOffice; growth in terms of quality improvement, in terms of features, but in terms of what the Document Foundation can do, thanks to broader resources than when it first started. What this does not mean however is that our infrastructure team has free time available; but it means it can do more and accomodate more needs than previously. Here are a few concrete actions the project has been deciding recently and/or committing itself to in a systematic way since a few months:
- Hackfests: Of course these are not new, but looking on this list you will notice that they do now happen on regular and close intervals. These are actually very inclusive events and are open to anyone who wish to learn development on LibreOffice as well as joining the QA team and even how to contribute designs to the project. The next step being to go “transcontinental”, with hackfest taking place in the Americas, Europe, and Asia for instance. And for what it’s worth, we are having our hackfest in Paris this Friday…
- More localizations: more and more teams of localizers apply to have LibreOffice localized in their own language. It does not stop there though, as we also see an increase in new openings for native-language projects, meaning that these teams will go beyond localization to serve users in their native language, promote LibreOffice locally, etc.
- RedMine. Everywhere. All the time. With various teams come various needs, many different habits. Some will use wikis extensively, some others won’t. But many of them, when they’re not developers, have trouble actually coordinating and keeping track of their own project. After extensive tests the answer is RedMine. The Infra team has a dedicated RedMine instance for anything such as events planning to website management. As a side note, our Bugzilla is now used only for LibreOffice development and not anymore for the website, infrastructure or project management. RedMine tends to be easier to use, more adapted to a range of uses broader than software development, and bundles several tools such as wikis, gantt chart, issues tracking, etc.
- Sane files repository with OwnCloud. We now have our own. Enough with files lost on the wiki….
- A project-wide newsletter, gathering the quality throughout the project, dubbed LOWN (LibreOffice Weekly Newsletter) has been started and will now become a collaborative, online effort that will help circulate information around the community.
- Soon, we will have a multilingual blog planet derived from the one used by OpenSuse.
In terms of processes, two specific improvements must be listed:
- Regular QA bughunting sessions, allowing not just to tackle quality issues but to attract newcomers to the project -thanks Robinson!
- Regular release coordination and readiness for localizers and native-language projects – thanks Sophie!
All this ultimately leads to a breadth of improvement, in the community and in the final stages of the 4.3 release, a major one to date. Check out the first draft of the release notes here.
Ultimately however, all this would not work without the team of LibreOffice contributors who help make LibreOffice what it is today: a fun project, fantastic people, and a free office suite that is the best productivity tool you can find around.
Where were you when you first learned about open source software? If you’re under, say, the age of 40, your answer will probably be, “Come again? I’ve always known about it!” But if you’re older, you may recall the first time you ever heard the phrase. Maybe it was when Netscape announced it was going to “open source” its Navigator Browser, or perhaps when you heard the name Richard Stallman for the first time. It may also be the case that it was some time before you really got your arms around what open software (or Stallman’s Free and Open Software) really meant in all of its various connotations – license-wise...
One area on the Linux desktop that remains surprisingly conservative is email – email clients and webmail alike. While most if not all of the formats and protocols used are true open standards, you would think there could be a broad range of clients and webmails for Linux out there. Let me correct that: webmails are in a league of their own and I will not enter the webmail vs. email clients discussion. Many things are changing in that field, but one must differentiate between the actual email service, like GMail, your corporate mail, the webmail software (Roundcube, Horde, Citadel, Squirrel, etc.), the groupware platform (Kolab, Blue Mind, OBM, eGroupWare, and many others) and what lands and gets edited, if you’ve chosen so, in your email client, meaning the actual software program running distinctly from your web browser and handling anything from emails to calendars and contacts. Today I will focus on the email clients on the Linux desktop. I do not pretend that my list is exhaustive; it is but a personal selection; I have also excluded email client such as Mutt, mu4e, VM, RMail, Ner, Wanderlust, etc. as I will only be speaking of graphical email clients on Linux, at least the ones I’ve tried.
Let’s face it: Mozilla Thunderbird is unavoidable. The reason it is so popular is that the choice of an actual email client other than Outlook or perhaps Lotus SameTime on Windows is actually quite reduced, aside the blue bird and perhaps the Pegasus mail. Anyway, Thunderbird occupies a strategic segment, so to speak, in that it is really multi-platform and caters to most peoples’ needs. I did use Thunderbird and in many ways I really like it. I do have two real issues with Thunderbird though. The first one has nothing to do with the software itself: It is that we -and by we I mean almost everyone I turn to- don’t know anything about the future of Thunderbird. What Mozilla plans to do with it, how the project works, where it goes is unclear. Thunderbird is being maintained, and before you ask, no, the Document Foundation will not develop Thunderbird in the future.
The second issue I have is that because of some subtle combination of factors mostly related to the mbox implementation in Thunderbird and the general application performance, the email client can be an absolutely awful resources hog. In fact, for anyone relying on email client with large or even huge email boxes, I would argue that Thunderbird is not the best option, even if its extensibility seems to keep some portion of its user base happy. Basically, Thunderbird will do the job but if you’re down to three different emails and a few gigabytes of inboxes your computer will turn into an oven, and a slow one at that. Be it as it may, Thunderbird’s value, I think, lies in its ability to address almost everybody’s needs without being “feature complete” in any way.
At this stage you may be thinking that if I call Thunderbird a resources hog then Evolution must feel like crushing an ipad under a truck. Well, I have used Evolution intermittently since 2003(!) and I have seen it, er, evolve. Yes, Evolution was terrible for years in terms of resources and stability, although the features it offered and still offers are unique on Linux. After Gnome switched to its 3.x.x branch however, Evolution started a major rewrite and things improved considerably. I have been using Evolution for over a year in 2013. I know that Red Hat invested more resources in it after a few other hackers left. Surprisingly enough Evolution is faster and lighter than Thunderbird for large inboxes and multiple accounts. It also handles all sorts of mailbox formats and relies on the maildir format as a default, which does make a difference with large inboxes compared to mbox. One misconception I have also seen is that Evolution only handles one inbox. It is not true, you do have one global inbox for POP and local email accounts and inbox folders but if you use IMAP on several of your emails you will use several inboxes and of course several accounts. Feature-wise, Evolution offers what you expect for a corporate environment, meaning not just mail, but an actual working calendar, contacts management, tasks, memo, meeting planning, etc. If you do not have specific needs for calendaring and do not handle a lot of emails, then Thunderbird might become a more compelling option, although that is not really a really clearcut choice.
Readers of this blog will remember that Claws is my main email client, so don’t expect me to criticize it… or wait. I love Claws. It handles my gigabytes of email graciously, has built-in search that’s faster than anything I’ve witnessed (Thunderbird does not come close to that), handles the MH and the mbox formats like a charm… what’s not to like? Indeed, not much. True, the interface is not the most modern although a careful choice of iconsets can definitely improve the looks of Claws. On the other hand the interface is not antique and is very clear. Where I see limits is not in Claws’s mail handling but on pretty much everything around it. For email clients, this means at least contacts management and calendar. On these two fronts, Claws Mail is not on par with Evolution or Thunderbird. Let me explain.
When it comes to contacts and addressbooks, claws is doing relatively fine, especially on fields completion and contacts search; but the actual interface of the addressbook and the management of contacts is rather poor, so poor in fact that the Claws Mail project has started a rewrite (the first one since their fork off Sylpheed) of the contacts management module. The other area is the calendar. There is no calendar in Claws officially but there’s the vcalendar plugin. Help is very welcome in improving it feature-wise, but in making it actually usable. There’s a bug with recurring appointments that’s been driving me crazy for something like 3 years now. What can you do with this calendar? Receive invitations, send them, getting notifications. All this works if they’re not set as recurring events and if you like austere interfaces. Do not expect more from vcalendar though.
It is not entirely clear what is Kontact and what is Kmail because these two are very well integrated. I do not use Kontact on a regular basis: I’ve tried it and tested it several times. It has a very broad range of features which sets this KDE email client somewhere on par with Evolution but I have not tested its performance entirely. My problem with it? I don’t have a problem per se, I have seen Kontact working in conjunction with the Kolab plugin and the data sync is impressive. But I don’t use KDE regularly, and don’t intend to use it in the forseeable future.
I have either given a few of them a try, or not at all, but it does not mean I am not interested or that they’re not good. Here are three of them with cursory notes:
- Geary: I like its slick look but as far as I can see, the scope of features is just not what I’m looking for. It must be stressed, however, that Geary is currently undergoing heavy development, so who knows what will be the outcome in, say, one or two years.
- Balsa: a very old email client, a bit like Claws. I’ve never tried it though, but I’m interested in opinions on the subject.
- Trojita: I’ve heard really good things about this Qt email client; I’ve never used it though but I’ll give it a try soon.
What’s your take on email clients on Linux? I love the diversity and range of choices available, but feel a bit disappointed by the lack of awareness coming from Linux users about these projects. I hope this post can help improve things a bit!