Picture by Eliane Domingos of the Document Foundation

If you wish to read our official wishes, we have them here, and they come from all of us. My thanks go to everyone who is making the LibreOffice project possible and what it is today. We have grown quite a lot in 15 months, probably more than we would have thought. 2012 is going to be the opportunity for the Document Foundation to solidify its successes and turn them into a powerful entity and structure. It will also be the year where several strategic project, such as LibreOffice OnLine, will see their development hopefully take off. Adoption-wise things are already well on their way. Deployments are ongoing on a worldwide basis, large and small, and what we  need at this stage is to push our brand name in a more consistent way. It will also be the year where our friends at the Apache Foundation release their first Apache OpenOffice; what will be interesting will be not their first release(s) but the one that will see most of the Lotus stack be injected into it. This will actually be a good opportunity to clearly differentiate Apache OpenOffice, and that in turns will improve the Apache OpenOffice project’s health and its relation with the outside world (LibreOffice being one example).

But 2012 will be the year where you will be able to experiment the benefits of the LibreOffice development’s effort as we will bring the 3.5 and the 3.6 lines to life. I think it will illustrate that a community-based development model does effectively work and brings real and regular improvements and changes to an aging codebase.

On a more personal note, 2012 will be an important year: I’m getting married in June (expect full delays in blog posting) and this is something I was not expecting even a few years ago. But there are a few people in this world (in this case, only one) who can change everything for the best, and for this I’m truly blessed and very, very happy.

Last but not least, I would like to express my gratitude to my family and my friends at the Document Foundation and at Ars Aperta for making all this a reality. You truly rock. What else is there to wish? Health, happiness, and love.

Merry Christmas and a happy new year 2012.

LibreOffice has an aging interface. It’s not just that it has many defaults, because, as much of the software packed with features tends to have this problem; it’s that LibreOffice looks a bit like it’s living in 2003. That reason alone is enough to want to change the whole UI. However the LibreOffice codebase is, despite constant clean-ups somewhat too complex to have its UI change overnight. Therefore we will be able to do so in an incremental fashion. What is needed is specifications developers can work with that target one specific user interface feature. With that, developers are able to “swallow” the specification and possibly implement it in a specific time frame. Will Citrus be the next LibreOffice UI? I don’t know. But if the design team is good at writing specifications (something some of its active members are in the process of learning) we might get to something that will have much in common with Citrus. The fineprint on this, however is that we need motivated volunteers able to work on UI improvements in an effective fashion, and developers’ resource to implement them.  If you are interested and would like to help, please join!

]]> http://standardsandfreedom.net/index.php/2011/12/11/citrus-reality/feed/ 2 http://standardsandfreedom.net/index.php/2011/11/20/a-few-thoughts-on-innovation/ http://standardsandfreedom.net/index.php/2011/11/20/a-few-thoughts-on-innovation/#comments Sun, 20 Nov 2011 18:22:01 +0000 Charles http://standardsandfreedom.net/?p=438 Continue reading →]]> I was invited the other day to a conference about innovation in the information technology sector. There was nothing remarkable about that event, except perhaps that it led me to voice an opinion I held for years: I do not understand what people are really talking about when they talk about innovation, at least in software, that is.

It might be odd to write this, but if there’s any concept that’s both fuzzy and dangerously misleading in the software industry, that would be innovation. I have read for many years and listened to people explaining how to “stirr and create innovation” in a company or in a community. Maybe these words have been used for lack of a better term; but I still don’t see how you can create innovation. I think you might be able to stirr it somehow, as it’s already a humbler verb. But frankly, can someone out there tell me what does innovation mean in the software world?

In general terms, I would define innovation as the big and small changes constantly leading to a change of the art in any given field. I think that’s pretty much what one usually understands by that word. So why could this not be applied to software? Precisely because software is rarely -if at all- the result of big changes happening all of a sudden and by accident. Software development usually happens at an incremental pace, whether openly so (think about the agile development practices) or even when there’s a structured corporate environment favoring traditional code reviews and quality assurance processes through stable product development cycles. Software is not produced by accident. Software is the result of process, and in theory accidents do not happen there. In fact, I could also point out that incremental changes or a period of technological incubation might be observed right before the emergence of almost any given technology. Take the medieval rudder for instance: it’s been rumored to have been imported in Europe around the 12th century by Chinese ships, but there are tracks and evidence of previous try-outs by European sailors and shipyards to design wooden rudders and articulate them with a complete mechanism. Similarly, it is hard to say how “innovation” happened in the sixties when the U.S. decided to send manned flights to the moon, but the wave of small and not so small innovation that was the result of this huge project is still visible to everyone (think of the Tefal pans, among many other things).

Thus there are, I think, two points that need to be highlighted: First, innovation does not happen all of a sudden if the field of software field and more generally ICT. It is a set of processes that ultimately lead to new software, or software that’s supposedly not as bad as the former state of the art. Second, what’s unclear is how -to quote several people I listened to- innovation “happens”. It sounds sometimes that innovation is a mystery or the philosophers’ stone that require care and secrecy to happen. Yet in the software industry, it does not work that way, for all the marketing and bells and whistles that come out of software vendors do not brush aside the fact that even inside these corporations software development is a set of very well defined, but non-public, processes.

Innovation is not a mystery and I don’t think that you can track how it works. You can assume that a certain set of circumstances and an environment letting people code start-ups emerge and Free & Open Source Software projects grow will ultimately translate into something that someone, whether a journalist, consultant, politicians or venture capitalists will call innovation. Anything else besides that, innovation sounds more like vapor and magical boxes. This should probably express what I feel about software patents, by the way.

One last thing: Innovation is different than progress. Progress is usually applied to fields that do not necessarily belong to science or technology; it can be more a perception and may concern society as a whole. Yet the interesting thing is that while progress seems to be an even more elusive term than innovation, you can actually tell progress from regression or stagnation: people perceive it almost immediately, however relative it sometimes may be.

Enjoy the beginning of the Holiday season!

I had several colleagues, friends and people asking me whether they should run Arch Linux on their desktops or laptops. I even read someone’s blog today on his impression on Arch Linux and Ubuntu. It’s time for me to jump in and clarify what you should expect with Arch Linux as a desktop on a daily basis.

Arch Linux is a rolling release system. What this means is that you do not get releases at specific intervals in time, like you do with Ubuntu, OpenSuse or Fedora. Instead there is a constant stream of updates that are uploaded on the distribution servers and that you can pull almost everyday. These updates are uploaded after a testing period by the Arch Linux  testing community (you can switch to the testing mirrors if you wish) and it is up to you to choose if you want to install them or not.

Such a rolling release process eliminates the need to accomplish major upgrade and makes you gain time, as you typically end up installing your Arch Linux system once, or twice if you really screwed up something. Also, Arch Linux does not come with very specific tools (aside the pacman package manager) and therefore you do not end up with Unity vs. Gnome Shell or YAST and PUP, or whatever control center. You get the latest KDE version, the latest Gnome 3 version, the latest Unity and the latest Xfce (these are examples). Pretty much everything is configurable as the distribution gets to make choices on core components versions (glibc, python, etc.) and exercises its value and role on testing and QA (what happens after each kernel upgrade, etc.)

Yet all this does not mean the distribution is hard to use. Not at all. The installation process may take a while (several hours.. or less) and I would be tempted to claim that what takes time is to transfer your own content and granular application settings to the new system, such as themes, pictures, etc.

But let’s focus a bit on the installation process: that’s where things tend to get rougher. Arch Linux uses a command line installer. It does not make things very difficult to understand – besides, you can always refer to some very good documentation – but it definitely makes the process more intimidating and any issue or inconvenience tends to be perceived as a bigger annoyance than what it really is. Of course, such a comment has to be put in context of other Linux flavors where you insert a DVD and don’t do much aside choosing your keyboard and entering your name. Not so long away you still had to be careful when partitioning your hard disk even with an user-friendly interface. In any case, the installation process is what will make you reach a working, fully graphical and modern system or a glowing command-line mess. There’s nothing specific to avoid here, only know that your patience and work will be rewarded and that in a sense, such an installation is not that hard to perform.

Once your system is up and running, everything tends to run smoothly and you end up with a nice, fully customizable desktop. You can use  “community contributed packages” from the Arch Linux User Repository to complement your software tools, themes, fonts, games and utilities.

As a conclusion, I would say that while Arch is not as easy to install as, say, Ubuntu, once you’ve gone past it, you will be surprized how easy it is to use it, almost as easy than Ubuntu or any other distribution. Arch Linux is a very fun and stable distribution that successfully blends the bleeding edge, stability and hackability of Linux. Don’t be fooled by the rumours saying it’s for the elite. It is made for you, if you can give it 3 hours maximum of your time to install it, and it is likely you will never switch back.

Fast forward to the LibreOffice Conference in Paris. On the evening of the 14th we thought we would set up some beer and music party in a hacklab and we contacted the LOOP in Paris. While they had to migrate from one location to another we ended up in an alternative cultural space shared by hackers but also completely different people as well. What was really interesting to watch was the general blending of these populations. In the end, it should remind us that even the coming of the Document Foundation was and is at the same time the answer to the decay of a free software project struggling under the iron fist of an irresponsible and greedy corporation (Oracle)  and the perfect example of a community deciding what’s good for itself, having reached a point where “enough is enough”.

The LibreOffice Project is thus more than a free software project developing an office suite. It has started a bit before the events in Tunisia, but roughly at the same time the Iranian revolts were taking place (and they’re still going on by the way). It is about freedom and the individual power to refuse the will and the agenda of a large corporation. It is about realizing that something had been failing in our community and that it was time to fix it.

The Document Foundation was started because of that; and just like the people on the streets of the world, it was prepared  somewhat in a stealth mode at first, otherwise it  would have failed. Now things have become quite different, and we just celebrated our first year as a project and as a free community where everyone can fit in and contribute meaningfully to the greater good. The numbers speak for themselves, and the OpenOffice.org community has chosen to go for LibreOffice, not just as a product but as model, as a set of values and as a refusal to compromise one’s freedom to corporate agendas. Our manifesto highlights the goals and the values of the LibreOffice community and why the Document Foundation has been created and set up.

Yet we are not one fork among others. We are the next chapter of the next decade. We are LibreOffice, we are the Document Foundation. We are the people of OpenOffice.org . We are no puppets and no useful idiots. We bow to no one. We are here to fulfill the destiny of this great project: to create instruments of freedom and tools for knowledge.  We are “OOO”, we “Occupy OpenOffice” we stand for freedom, community, excellence and collaboration.

We are the 99%. Expect us.

I’m a rather outspoken user of Arch Linux after having used and tried many other distributions (MandrakeSoft/Mandriva, Suse, Debian, Fedora, Ubuntu, Mint, SLAX, Chakra and even a few others) and I think I got to like the rolling release concept quite a lot. The rolling release concept essentially takes away the notion of milestone release for a Linux distribution and replaces it by incremental and almost continuous updates. Which means that everyday I can update my system and it’s thus almost always running the most recent stable software versions. Note that the upgrade is my choice only, I could stop doing this for 3 weeks instance and that would be fine. Using Arch Linux does not only mean embracing the rolling release distribution model. It also  means being ready to install your system from the command line (granted, you only do that once in theory) which can be tedious but not reall difficult. Another “side effect” of using Arch Linux is that the distribution’s package management is done entirely through the command line and with the help of the excellent package manager pacman. Pacman is however not a graphical package manager, or rather, it does not come with a default, out of the box graphical front-end. Several of them do exist but it does not seem to be in the culture of Arch Linux to use one on a regular basis. Enter AppSet. AppSet is a very nice graphical package manager written in Qt; it even got me use KDE again on par with Gnome. AppSet does not only run on Arch Linux, it also supports Chakra (a very close fork of Arch Linux) and works in theory with any other packaging system.

In the times of ubiquitous App Stores, even the ones that actually values and promotes Free Software such as the Ubuntu App Store, it’s good to hear you still have innovation happening in this field, with tools being developed that let users be in total control of their system. I’m sure that the AppSet team would welcome more contributors and more distributions!

I would like to tell the “Hamburg team” as we often used to call them that they should have no regrets whatsoever. Perhaps my words will surprise some, after all, I didn’t leave the OpenOffice.org project under Hamburg’s cheers.  It does not matter in the grand scheme of things; what I’m doing for the Document Foundation is what matters now and the shutdown of the operations at Hamburg shows once again that the people behind the Document Foundation were right from the start: Oracle’s stewardship of the OpenOffice.org project would neither be sustainable nor workable. I, for one, wish that in an ideal world, most of the Hamburg team would have transitioned over to the LibreOffice project. Unfortunately, that’s not the case, but life is made so that things are never really perfect.  StarDvision team, you gave birth to many good things, your work now lives in several software, most important of all them, in LibreOffice and the Document Foundation; Apache Openoffice.org/Symphony carries your name, and will use a great deal of your code as well. Even more importantly, the Hamburg team, through the OpenOffice.org project, has also attracted and helped many people from all walks of life who over the years have worked together and grown as a team. That is the case for me, and it’s the case for many other people. You have brought us so much, and I would like to express my sincere gratitude for all what you’ve done. You have started something incredibly important; your work will not have been made in vain, and it will continue to bear fruit for a long time.

Take care!

These days I started to see some questions arise here and there, about why we’re not proceeding as fast as we could with the setup of the legal entity, why we sometimes fail to communicate a vision for the project, etc. These are all good questions. Ultimately, we have to react to them by acting on the issues that are raised. Yet it is important to keep in mind that the light at the end of the tunnel is growing fast.  I hope (I know) we will soon see several announcements pertaining to the community and the project. We’re working hard at making the foundation a reality, but we’re also working hard at securing the Document Foundation’s financial future and at improving our community processes. Questions that arise about these matters are legitimate, and if you feel we’re not answering them, then it means we’re either swamped or are currently not able to answer them (because of various constraints). But we do read them, we do hear them. And they will be answered, either in writing, or in solid fact, usually expressed by an announcement. You can help make many things a reality by contributing to the LibreOffice project. It’s fun, it’s even exhilarating and it’s a formidable human adventure alongside being technically exciting and challenging.

Among the questions I was mentioning above, there are some that aren’t really questions, but are critics that are not uttered in a constructive way. These are critics that come from those who have chosen a different course and for whom the Document Foundation is by no means a symbol of digital freedom and software freedom. You will hear them singing many tunes, until their voices gradually faint in the background chatter. We can take some critics in a constructive way, as feedback to build a better project. But extravagant theories claiming that we are the pawns of Microsoft and that we are in fact detrimental to Free Software are delusions of people who do not understand anything to the way free and open source software communities work. Which is a shame, as some of them actually used to “manage” communities (and still claim they do, but one wonders who mandated them to even pretend to the title).  These critics are in fact detrimental to Free Software and to the ODF ecosystem, as they come across as awkward in the light of the events that have taken place since a few months. When everything is said and done, the LibreOffice project’s goals have been the right ones since the very first day and firing people off their roles inside the OpenOffice.org project hasn’t made them any less right today. An old but famous Persian saying tells that caravans keep going on their path while dogs bark at them.  The Document Foundation is a bit like a caravan, in that we’re a diverse community travelling towards one goal and not hesitating to include people on our way. We share our bread, we share our wine, we share our fire, and we even accept donations. Some people will call it awkward, will demand some “adult supervision”, will doubt each of our step, question our skills and postulate ulterior motives, but in the end, we shall prevail and we will be THE Free and Open Source Office Suite, innovative, open standards-based and developed in a transparent and inclusive way. Let the dogs bark. They really only wish they could be leading the party.

Here’s a couple of links before an even more active month of May:

• Ars Aperta has contributed to a pretty interesting project, dubbed ODFgr and hosted by the OpenDoc Society. The goal of this website is to provide any developer with even a limited knowledge of ODF with resources and tools to manipulated ODF documents. We tried to design a pedagogical platform that the largest number will understand. Most of the examples are listed by languages (we mostly have Python and Perl) and you can study both the explanation and learn how to reproduce and implement it. We hope it will be the right spot for anyone willing to get started on OpenDocument hacking and development.
• Events-wise the month of May will be busy. I will attend the OASIS Board of Directors’ meetingin Berlin and meet with the Bitkom. The week after that Ars Aperta will join a session on the political and legal issues pertaining to Free Software development during the Linux Solutions 2011 event in Paris. I will also give another talk during the same event as part of the Document Foundation and our experience with forks. Spoons shall come next year.

The very first comment that somewhat counters’ Phipps’ s model is that it ignores the fundamentally dynamical nature of FOSS communities and the inherent sociological rejection of any real “stable” state of the social structure inside these communities. It means two things: That anyone from the end-user community may turn into a core developer provided he/she has the skills and provides relevant contributions in the relevant way (in my example, the end-user would have to contribute code patches in a regular fashion to become a core developer); second, that the members of these communities have no status that is carved in stone. You are not born a core developer, you become one, but you won’t remain one until you keep contributing. This in turn highlights two notions that are essential inside FOSS communities and that may be seen, as I wrote earlier, as an additional, yet necessary description of the way FOSS communities work through and beyond the typology enunciated by Simon.

But first let’s go back to my example of the core developer who has to keep on contributing unless his role and standing diminishes. What this example shows is that FOSS communities are at their very core “do-ocracies” ruled by the social contract created by the sheer existence of digital commons. Measuring how efficient the social contract may be means to evaluate how open and welcoming the authors/developers/core team are to new contributions. If that’s not the case then of course, FOSS allows code forking, and then the new social contract might be reinstated in a better way. What becomes apparent in these examples, however, is that the notion of contribution is perennial in assessing how a community works and what the standard for this assessment should be. Contribution is pretty much the only thing that gives both meaning and purpose to a FOSS community and is in fact the only activity that matters. The reasons for contributing code, materials, designs, documentation, QA, efforts of various kinds such as users’ support may be very different from one individual to another; the same stays true for a business contributing to such a project, yet it is out of the scope of this essay. Nonetheless, contribution is more than adding one little piece more to the overal project. It is the very fabric of the project and its community.  Contributions may differ in quantity, quality and nature; the only people who are not contributing -in theory the end users- are the only ones who cannot properly have their say inside the project by themselves. This sentence needs to be clarified: Unless someone engages with the project by contributing something it will benefit from the protection and the rights of the FOSS licence itself and the availability of the said software as a common digital good. Beyond this, his/her standing inside the project is theoretical. This is why the end-user community lies the farthest from the core of the project. Of course, and this is especially true in projects developing software meant to be used by everyone (i.e Mozilla Firefox, LibreOffice…) end users may be regularly heard because dedicated activities and teams will collect their feedback and engage volunteers in user experience testing, designs, etc. But the very same people engaging in these activities cease being passive at the very moment they start contributing time, effort and sometimes expertise to these activities and enter the “extenders’ community” if we stick to Simon Phipps’ s model. It is therefore crucial not so much to implement users feedback strategies – that truly depends on the project and its scope- but to make sure the barriers to contribution, not just of code but of anything else is low enough to encourage end-users’ interest and involvement.

Contribution also breed what I often call the sense of appropriation, which is, for any given contributor, the feeling of co-ownership of the project and the digital commons developed by the project. This sense of co-ownership implies the adherence to the project’s goal while steering the will to do more and be more inside that community, depending of the person. This sense of appropriation may wane to the point where the contributor will stop contributing, and if several contributors lose appetite and fun contributing it is often a clear sign that something wrong is going on inside the community.Therefore the concept of meritocracy ,when properly applied in a community, is usually one of the best tools to grow that community as it remains as one of the main, if not the sole sane principles of community building. Meritocracy is the direct consequence of the value of contribution in a FOSS project.  Anything else in FOSS, such as democracy, ultimately lowers contributions to the benefit of uninvolved people and to the law of numbers, masses and manipulation. That’s why FOSS has never been about democracy but about meritocracy, even if it practices limited democracy among its contributors. But that notion belongs to community processes. Read on.

I have written above that contributions may differ in quantity, quality and nature. It is pretty often difficult to judge contributions objectively when they are made in code patches or bug reports. There are however many other ways to contribute aside code in a FOSS project. The question is not whether there is a standard to assess contribution; there is none, really and each community will evaluate them in a different way depending on its purpose, its history and its sociology. The question revolves around the decision-making process either in between various teams of the community. A good example is a situation where core developers want to go ahead with a release of a version they deem to be stable while the QA team is in disagreement with the core developers because of one specific outstanding bug that’s considered to be annoying enough to block the release. Staying within that case, let’s picture the UX team (user experience team) with one latest push on icons or one specific graphical detail, requesting the inclusion of its latest effort to the core developers. Can anyone tell who will have its own way?

If we refer to the threefold typology of the community described by Simon Phipps, the model is very static but one would say that the core developers would be able to dictate their own decision to the others as they are the ones who directly write the code and therefore have the broadest influence over it. While this is true, the ultimate consequence of this would lead to the complete disintegration of the community, as the powers would be vested once and for all to the core developers with everyone else bowing at them. While developers do make the code, the digital commons, by themselves (although it could be pointed out it’s not always the case) we could demonstrate that the domination of one category of contributors by the others is tyrannical and goes against meritocracy. If marketeers were to have their say in a constant way over developers, this would not be a Free and Open Source Software project anymore, it would mean working at Apple Inc. This highlights the need for community processes. Community processes are not just the processes leading to code creation and release. It is pretty much anything from governance to team setup, conflict resolution and release process.

Community processes thus have a rather broad scope. But they are -or should be- designed to strengthen and uphold meritocracy and transparency, by making sure specific rules of community work are clear and known. They are also supposed to provide the necessary environment for balancing power, which means that they define governance and governance processes. Community processes and governance do fulfill a need that the sheer meritocratic structure does not or rather cannot meet: it manages issues and decides of the political structure (political here is understood in its first sense, that is, the concern of the polis, the city, the tribe) of several people working together on specific but different tasks as a community.

We can now manage to enunciate the following propositions:

• contributions are the fuel for a project (not even money, and even less talk)
• community processes enable issues and conflict resolutions through governance and lower-level processes
• these processes cover contributors inclusion and allow them to contribute.

The term “community” thus needs to be defined with a certain accuracy as it covers several realities and as it is not necessarily a well-understood term. I can roughly and simply answer the initial question with the following (long) sentence:

A Free and Open Source Software community is a loosely knit group of teams and individuals contributing in various ways to a specific project with the help of specific tools, processes and governance yet without any overarching authority imposed from an external source, but from a structure that stems directly from themselves and ensures that the merit of each is rightly valued and taken into consideration from the ground up and in a transparent way.

Comments welcome!