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.
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!
Unless you’ve been taking a holiday from the news for the past month, you are already aware that Amazon is in the midst of a very nasty negotiation with Hatchette, one of the “Big Five” U.S. publishers. Together, as a result of a decades-long series of acquisitions, these five companies have consolidated virtually all of the most-revered, but now conglomerate-owned, publishing houses in the U.S. Given the degree of respect that books still command, the dispute has attracted far more public commentary than commercial disputes in such a narrow market usually attract.
On a visit to Scotland, it’s impossible to avoid the issue of the referendum on Scottish Independence, due to take place in September. The media explore endlessly every possible ramification of a ‘Yes’ vote. It all feels very odd – is this really what the birth pangs of a new nation should feel like?
When my grandparents’ generation set up the Irish Free State, they didn’t debate endlessly whether cross-border issues might work for or against their advantage. For them, it was simply a matter of “It’s our country. Give it back”.
I’m sure the same is true when the people of India gained their independence – they didn’t agonise over the pros and cons to their economy of membership of the British Empire. No, they simply said “It’s our country. Give it back”.
If the people of Scotland truly wish to join the independent nations of the world, then on September 18th, all it needs is for enough people to put their hands on their hearts and say: “It’s our country. Give it back”. Everything else can be worked out afterwards. In fact, for Scotland to earn its place as an independent nation, nothing else should matter.