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.
Along with death and taxes, two things appear inevitable. The first is that Internet of Things devices will not only be built into everything we can imagine, but into everything we can't as well. The second is that IoT devices will have wholly inadequate security, if they have any security at all. Even with strong defenses, there is the likelihood that governmental agencies will gain covert access to IoT devices anyway.
What this says...
The following views are mine alone, and should not be read to reflect the expressed views of my firm or any other partner
The following views are mine alone, and should not be read to reflect the expressed views of my firm or any other partner
The drama of President Trump’s ban on immigration played out on multiple levels this past week; legal, as multiple courts weighed in, culminating in one granting an injunction that put the ban temporarily on hold; politically, as protesters clogged city streets at home and abroad; and factually, as the slap-dash way in which the order was implemented became increasingly clear. And then, of course, there w...
When standards developed by the private sector become laws, should anyone be able to download a copy for free? At first blush, the answer seems too obvious to debate. But yesterday, a U.S. district court held otherwise, saying that the developer of a standard that has been “incorporated by reference” (IBR) into a law continues to have the right to enforce its copyright. It also confirmed the right to charge a reasonable fee for an IBR standard.
The ruling (subject to appeal) is less surprising when it is reviewed in detail. The defendant is Public.Resourc...
The following views are mine alone, and should not be read to reflect the expressed views of my firm or any other partner
With the change in administrations, I’ve decided it’s time to revive a series of essays I began posting in 2007. I’ve duplicated the text of that first blog entry below. Sad...
Watch the TED.com video: "Meet the inventor of the electronic spreadsheet".
TEDxBeaconStreet, where I gave the talk, is part of the TEDx program. It is an independently-organized TED-like event, named after "...Boston’s longest street, uniting towns and cities, neighborhoods and businesses, schools and families along the way." After they are given, TED picks up some of the talks at TEDx events and posts video from those talks on TED.com.
As I've often done in the past, I wrote an essay for the Writings Section of my website chronicling the process I went through to turn my long, rambling slide show into a tight, 12-minute TEDx-style talk. Viewers of the video may find the essay of interest. It was really interesting how helpful experience with crafting understandable, 140-character tweets on Twitter were for writing a smooth, short talk. I also found the ease and non-obtrusiveness of using popular recording devices (specifically, a GoPro Hero Session and the Voice Recorder app on my iPhone) for capturing feedback when practicing in front of others to be important.
Read "The story behind my TEDx Talk" in the Writings Section.
There is one particular moment in every Free and Open Source Software project: it’s the time when the software is about to get released. The software has been totally frozen of course, QA tests have been made, all the lights are green; the website still needs to be updated with the release notes, perhaps some new content and of course the stable builds have to be uploaded. The release time is always a special one.
The very day of the release, there is some excitement and often a bit of stress. The release manager(s), as well as everyone working on the project’s infrastructure are busy making sure everything is ready when the upload of the stable version of the software, binaries and source, has been completed. In many cases, some attention is paid to the main project’s mirror servers so that the downloads are fluid and work (mostly) flawlessly as soon as the release has been pushed and published.
The LibreOffice project has released it’s latest incarnation from its Fresh branch, the 5.2.3 somewhat recently and it is amazing to see the pace of improvements and changes that have been taking place not just since the beginning of the project in 2010, but from one major release to another. Needless to say, there’s always much excitement going on on a LibreOffice release day. Recently the project decided to communicate more about the upcoming changes and features in its next majro branch, the 5.3.x. It is a smart move, and it will be useful as it seems that we need to reinforce our message about new features and changes in user interface.
Here again, one is amazed by looking at the sheer amount of changes and improvements brought by one major version to another. It is not only new features, interface changes, it is also an important number of bugs that have been squashed. On a more human point of view, this is also the collective adventure of a community of contributors that culminates the day of a release. To experience such a day is quite unique.
Yet the joys and excitement of releasing a new version are not confined to the LibreOffice project. It really is a shared experience across the Free and Open Source world. This week for instance, the mu email “client” and indexer have been released in a new stable version. Many improvements both in the search and indexing capabilities as well as the interface have been integrated. The release is technically easier than LibreOffice. There is less code and disk space of course, but everything pretty much happens on GitHub. Then it is a matter of publishing the news and the release notes. But the excitement is stil there, still the same for the contributors. And to make before Christmas does also add something special to the season.
“The Release date is coming, let it snow let it snow let it snow!”
This post is a bit of a rant, and I think it will resonate with people who have chosen to use online and shared calendars that are not provided by either Google or Microsoft. I will write it from the beginning: I still cannot believe we cannot achieve proper calendar interoperability in 2016. Again, if you are using Google Calendar or any calendar syncing and sharing technology provided by Microsoft, you may actually ignore this issue.
I have made the choice not to use the services provided by these two vendors, because I wanted to use open standards both for the calendar format and the synchronisation protocol. From the point of view of the Calendar output format, things have petty much settled down: almost any calendar software or service can import and export calendars under the ICal format. ICal is itself a proper open standard that has been developed by the IETF consortium and enjoys a very broad adoption. One of the most famous implementations of this standard is Apple’s Calendar, but as I wrote above, you may also use the ICal standard with Google Calendar, Outlook.com, Outlook itself, Claws, Evolution, Kolab Now and the Kolab server, the Horde stack and a many others. The problem, however, is that using an output format to share calendars with other applications or other people quickly turns out to be impractical. ICal is relatively easy to implement and knows no major technical issue; what it does not do however, is what should make a calendar useful: it does not update over time. Everytime a calendar gets edited and therefore updated, one would need to export it again via ICal, then send it to another user or another system, so that the new ICal file may be imported (again) into the other calendar.
I guess it’s workable enough if one were to work with very fixed calendars that change once every semester; but beyond that use case, calendars tend to get updated many times a week if not a day in a business as well as a family context. In order to work with these calendars in a smooth and effective way, the preferred way is to use synchronisation protocols. Microsoft has the famous ActiveSync protocol, which is widely used but not an open standard; other services such as Google or Apple usually will not disclose their protocols but will provide both the cloud storage, the web interface and the application (capable of working offline) for various platforms and devices. The alternative, yet thoroughly open standards based, is to use the “sister” standard to ICal, which is CalDav. CalDav is the standard protocol to sync calendars between different devices and between a server and clients. It is a true open standard and its maintenance is handled by the CalConnect Consortium. CalDav is by no means something that is out of the way: a whole breadth of services such as Kolab Now and Fast Mail rely on it to let their users sync between their calendar servers and their devices. Even better: there are commercial API services acting as middlemen between cloud silos that use CalDav to extract calendar and contacts and move them from one service to another: SmoothSync, Fruux and Cronofy for instance are on this market. CalDav is recognized as the “lingua franca” of the online calendar world.
But the point is this one: It is 2016 and shared calendars that should be simple and straightforward are both complex and obscure. People should not think twice about what to use: they should be able to share their calendars seamlessly, post it online, move from one provider to another with very little hassle. Instead of this most are locked in and when they want to move to another provider the notion that they should learn about the various calendar sharing protocols is simply outlandish.
There is more, and unfortunately it gets worse. The Apple stack does shine in its default calendar client, the eponymous iCal. It handles both iCal and CalDav very well. When you are on Android however, it gets… complicated. There are surprizingly few calendar applications able to handle CalDav; in fact, one first needs to install DavDroid (free on the F-Droid app store, available for a fee on Google Play Store), fill in its calendar credentials and then… nothing. Everything works well with DavDroid of course, but it is just not enough as it is by no means a calendar application, “only” a software enabling the support of CalDav and CalDav-capable calendar services on Android. Unless you’re using Samsung or Lenovo/Motorola, chances are your Android terminal won’t ship with a calendar out of the box. There are several of them available on the Google Play Store and the F-Droid app store: not all of them are CalDav ready and several of them can either handle local calendars or are front-ends for Google Calendar. The other shoe drops when one realizes that even Emacs is actually not that effective beyond its own local calendars (native and org-mode) and its Google Calendar client(s).
In short, running and using a shared calendar on a variety of devices, Android, MacOs & iOS, Linux and Windows is simply a crazy and somewhat absurd odyssey. In the end it is the freedom of choice and interoperability that are at stake; not that running an online and shared calendar based on open standards is not possible (Kolab Systems does that very well): it just does demand commitment, uncanny motivation and talent. The reason for this is complex, but the result is that sharing calendars online in 2016 still seems a very advanced technology. At the age of big data and software containers, it shouldn’t be. I guess life has its ways of reminding us of how frail we are as creatures and human organizations….
It’s been a while I have not written about Emacs and more particularly my personal use case for Emacs. I started using Emacs because I was looking for a text editor capable of handling formats such as HTML and CSS; then I found out Emacs had quite convenient IRC clients and I could even use a bit of Org mode for project management. That was in 2013 and early 2014. As I was impressed by the seemingly infinite power of Emacs, I started using Org-mode more and more on a daily basis (something I still do today); and I started learning (e)lisp both in order to understand Emacs a bit more in-depth and because I wanted to start to learn a programming language.
Remember: I’m no software developer. When I’m not maintaining or creating websites for friends, I’m not doing much else in the way of “coding”. My Emacs usage remains however a daily experience that I would like to share here.
The first and basic idea that drives my usage of Emacs is both simple yet powerful. I’m certainly not the first one to come up with it: most of what we do as users of computers on a daily basis revolves around text edition and handling text. That’s an obvious concept when it is applied to software development or just plain text edition. But it is equally relevant when we consider email, IRC, file and folder management, Twitter and RSS feeds browsing; and it does still make sense with web browsing for instance.
Put simply and broadly, many things -if not most- that we accomplish on a computer can be seen as text editing. Once somebody shares this view deeply, that is on a personal basis and for its own personal case, it is possible to accomplish a lot of things with text editors such as Emacs. What this does practically mean in my case is that I use Emacs for a broad variety of usage on a daily basis:
Email: I am happy -and somewhat proud- to announce that I’m using mu4e (and emacs set of tools and clients for email) for most of my mail processing. I now rarely use Evolution, which is my only graphical email client besides K9 on Android. Mu4e caters to most of my needs when it comes to email. In fact it fits the bill almost perfectly, the only exception being that I sometimes need to tweak it a bit when receiving oddly formated emails sent from Outlook 2014 and upwards. My mails are stored both online and on my computer in the MailDir format. I fetch them and sync them between my computer and the servers using offlineimap; they are indexed and searchable using the powerful mu mail indexer; and there is no performance issue at all. If anything it is noticeably faster than graphical email clients, especially the search part. Emacs in general handles html emails surprisingly well, and besides the Outlook 14 hiccup I mentioned above, I have no trouble viewing decent html on my “buffer”.
Org-Mode: that one is a heavy hitter. I use Org-mode for what it does best: task management, planning, note taking and ideas organization. I use it sometimes to write blog posts, but where it would really be useful in that regard would be with a blogging engine supporting org files and / or markdown.
Blogging and text editing: I write my posts using either org-mode or markdown. But the real trick is to have an effective workflow between Emacs and the blog engine. Unfortunately WordPress is not so good at that which makes me think about a few options for the future.
IRC: I don’t use IRC on a daily basis, but I have grown frustrated for years with IRC clients. No names here, but I find most of them complex and annoying. At least with ERC, I have an unobstrusive experience which got me on IRC more frequently, and not just to communicate within the confines of the LibreOffice community.
File and document management: Using Dired, a well known Emacs set of tools, file management is increasingly a good reason for me to use Emacs.
Terminal using eshell: I’m not fiddling on the command line all day long, but using Arch Linux on my systems means that you will fire your terminal at least one every two or three days in order to keep the system updated.
Documentation: Emacs comes with a lot of tutorials and manuals for many of its main utilities, and of course to learn (e)Lisp. It is possible and even very convenient to browse this documentation stack within Emacs.
What I use less for various reasons:
Internet browsing: Emacs is getting better at that but let’s face it, unless I’m browsing documentation or text-rich web pages online, I get a rather limited use for a text only browser.
Twitter mode: I would LOVE to edit and browse Twitter through Emacs. But the twitter mode is simply counterintuitive and slow. I’m a taker of any suggestion for any other Twitter utility running on Emacs out there.
RSS feeds browsing: Here again, I think we’re missing a good package. Emacs ships with a native RSS feed reader, but it is frankly a bit horrible. Another tool, elfeed, has a much richer functionnality but either because of lack of time or because of a bad configuration I just don’t find it convenient, even though it loads evertime on my own Emacs and is updated with my own feed. It is something to consider for the future.
I hope I have given some hope for people interested in using Emacs. I’m not a programmer, and if anything my specialities are literature, philosophy and History. As one can see however, Emacs is really useful for me and it should be for a lot of people as long as they’re willing to invest some time and enjoy learning new things and new ways to work and communicate.
I have never written about this rather sensitive topic before, but I recently realized that when we set up the concept of “Native-Language Communities” back in the old days of OpenOffice.org, the general idea was to allow everyone to participate to a Free Software project. Now, the stated ability -the basic freedom if you will- for women to contribute to any Free Software project has never been offically questioned. The reality, however, is more complex.
Surveying a broad range of Free & Open Source Software projects will highlight one unmistakable trend: Only very few women may be counted as contributors (active, regular, or otherwise) . Even The Document Foundation that is rather on the top of the projects with several women on the board of Directors, part of the foundation’s staff and among the most active developers, the community likely has about a dozen female contributors. A dozen over several hundred contributors: that’s not much. It is possible to explain this relative absence of female developers by several social and cultural factors (some jobs and industries tend to attract more males than females, etc.) . To a large extent that is probably true. What these factors do not take into account, however, is the social games of discrimination towards female developers occuring in some communities.
To many women, a large social group of men they are supposed to join may be intimidating – the same could probably be said of any men joining a large social group primarily populated of women. But when what looks intimidating reveals itself as being actually oppressing , that is the moment we have a true problem. Male developers shunning, criticizing, belittling and offending female developers because they are females, even when not necessarily expressed in an explicit way, is purely not acceptable. It is neither on the most basic moral grounds nor in the letter and spirit of the Free Software movement. The Internet, unfortunately, reveals protracted bullies, the kind of people who would probably not have the guts to ask the targeted woman out, or even not dare look at a female developer in the eyes and tell her what he would be able to write from the comfort of his own keyboard, miles away from her.
In the Free & Open Source Software projects, a particular attention must then be paid to this double issue: ensuring female contributors feel at ease participating to the community while ensuring that no form of discrimination based on sex (or race for that matter) is explicitly or implicitly tolerated as an acceptable behaviour. In concrete terms, clear rules against discrimination should be laid out and enforced – the latter being the key part of the solution – while a number of ideas should be explored in order to ease the participation of female contributors to Free Software projects. The Debian Women project is in many ways a great testbed for future initiatives.
Meanwhile, let’s all remember that regardless of our personal views on society, religion, politics and other topics, no one should be discriminated for its involvement and contribution to Free Software projects. Free Software is too important to let it sink under those issues, and female contributors deserve the same respect and the same roles as male developers. Software freedom comes for everyone.
Recently the Document Foundation has published its annual report for the year 2015. You can download it as a pdf by following this link, and you can now even purchase a paper copy of the report. This publication gives me the opportunity to talk a bit about what I think makes a great FOSS project and what I understand may be a great community.
If it is possible to see this topic as something many people already went over and over again, think again: Free & Open Source Software is seen as having kept and even increased its momentum these past few years, with many innovative companies developing and distributing software licensed under a Free & Open Source license from the very beginning. This trend indicates two important points: FOSS is no longer something you can automagically use as a nice tag slapped on a commodity software; and FOSS projects cannot really be treated as afterthoughts or “nice-to-haves”. Gone are the days where many vendors could claim to be sympathetic and even supportive to FOSS but only insofar as their double-digits forecasted new software solution would not be affected by a cumbersome “community of developers”. Innovation relies on, starts with, runs thanks to FOSS technologies and practices. One question is to wonder what comes next. Another one is to wonder why Open Source is still seen as a complex maze of concepts and practices by so many in the IT industry. This post will try to address one major difficulty of FOSS: why do some projects fail while others succeed.
My analysis is that because FOSS is a combination of several utterly different things (licensing, collaborative practices, philosophy, ethics, business models…) it is quite hard to claim that FOSS has “won” anymore that it has “lost”. Business models may for a time and under the right circumstances bring convincing proof of their relevance. Licenses may or may not gain popularity among projects because of a variety of factors. Philosophy may evolve to encompass new technological challenges (Free Software and cloud computing), etc. But what does a successful, friendly and great Free Software project do? What does this mean? Below are a few points that I believe to be key parameters to have a striving and growing FOSS project:
A clear and clean intent: The original author(s) of the project should be clear about their intent and the reasons that make them start the project. If it sounds obvious or perhaps some sort of justification no one should have to make explicit, in my experience there are wrong reasons to start a project and often bold claims that are made in order to “cover up” the initial intent behind the project. I remember clearly that just a few years ago, an established vendor “dumped” -really there is no better word than this one- a code base for an application development framework on to Apache. Apache also accepted the code dump of the OpenOffice.org codebase to Oracle, but I will not quote this example as it could be taken as an easy trolling from yours truly. So let’s go back to the other, unnamed Apache project. The vendor at the time made bold claims that it wanted to push its development framework to the top and make one of the most used tools in that category. Because it would be Open Source, it would automagically attract new developers behind the project and new developers as consumers of that framework. Fast forward till today: the vendor still has some resources into the community, but the project, while relatively active, is nowhere where it could have been and the community quite endogenous (i.e: the affiliation of developers shows a clear lack of diversity). The problem with the initial intent was that the bold claims the vendor made at first were not reflecting the reality of what it actually wanted to do: lower its costs in a highly competitive field while finding a plausible exit strategy.
Clear rules, clean governance, simple goals: This seems like a no-brainer, and yet many projects fail at addressing these points to this day. By clear rules and clean governance, original developers should make it easy for contributors to, well, contribute. It may be more difficult than it seems. It is easy enough (sometimes) to publish the code repository; less easy to justify a distributed code revision tool (aka Git but there are others) over a centralized one like SVN; it is however much harder to attract non-developers to the project, because this usually entails having quality assurance practices everybody agrees on, a workflow for documentation, volunteers for users support, and perhaps some low-hanging fruits in the field of devops and infrastructure. The challenge, then, is to weld in all these bits and pieces together to have an effective process generating code, happiness, and revenue (not just for the original developers though). Clean governance is trickier. It does not only rely on clear rules although they do make up for a large part of the governance. It does not just imply transparency. Clean governance exists and works well when no contributor can have its hand forced by a party that essentially yields too many resources in the project. Clean governance, in a nutshell, exists when no one can seriously make the claim that the game is rigged. You will find many projects with “one”, most important (corporate) contributor, and many will claim the project works well. I’m sure it does, but my experience shows that the imbalance that may not affect the everyday’s life of the community can gradually transform into a dysfunctional project with an ineffective governance that is rigged and only able to serve one party’s interest. It should be added that Free Software by itself does not make claims against such situations as the largest contributor should pretty much have the largest influence – and that’s fine with me. It is fine in smaller scale project with one contributor; and yet again it still raises the question of what would happen if that person were to leave the project. On this point, there’s no easy answer; but ensuring there’s as little imbalance as possible is a good thing to do. I’ve set aside simple goals because far from being a mere slogan, there are actually an important factor among the rest. Whatever the goals and intent of the original developers may be, a large or small part of it may not be shared by every contributor to the project. And that’s all right of course: the project exists and finds its coherence on the “segment” of the goal(s) that is actually the common interest shared by all the contributors of the project. If your own, ultimate goal is to build and fly a transcontinental airliner, it may well be that I’m only interested in powerful jet engines; or that I may be interested in a military airfreighter. So while we may not work all the way up to the airliner, we will work together on at least one specific project: the jet engine. This is where our combined interests align. Simple goals then are understandable, articulate, and stand a much better chance to be shared by a lot of potential contributors.
Good licensing & open doors: What’s good licensing? Don’t expect I will impose my views on what’s the best Free and Open Source Software license. I do have an opinion on the subject but it does not matter. Good licensing is licensing that is both well accepted by the contributors, and implies no or a minimum amount of friction and potential games to be played. Also, copyright aggregation is a no-go for many developers, even for a good cause. If it is to ensure the codebase has an unified IP in order to protect the “intellectual property” of the code base or avoid legal issues, other tools exists, such as declarations of origin whereby the contrbutor states that its contributions are indeed its own. This now leads me to what I call open doors. An open doors policy is the opposite of what’s happening in the Hotel California song, where you can get in but never leave. “Open Doors” truly empowers the developers and other contributors who want to participate and bring meaningful and important contributions. Yet this principle should never bend the rules of the project so that ignores the barriers to entry. In other words: I’ve been a strong advocate of the meritocracy principle for years. I have witnessed an unmistakable trend: meritocracy works in FOSS projects. It does work very well indeed. What it does not do, however, is to ensure that the barriers to entry to a project are both documented and low enough as to enable the potential involvement of as many parties as possible. Because of this, you could easily describe projects with proper meritocratic governance and transparent processes, but with a “domination” of just a few parties, one software vendors dominating the rest. Whether that would be an unspoken yet desired outcome remains to be debated of course.
With these few ideas in mind, I hope I’ve given some sort of “analysis chart” of what makes a good Open Source project. If we live in an era where even Wired titles that Open Source has won, maybe it’s time to improve and perfect our art. We’re not done with Open Source, we have just started.