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.

It’s been a great year. It’s been a tough year. I learned a lot. I grew quieter. I tried to become more humble. I didn’t lose weight. I got engaged to the Love of my life. I helped pushing something nobody usually gets excited about: an office suite. But folks, beyond the code, beyond a community, beyond ourselves, we did more than an office suite.

We changed the world.

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!

It’s been several weeks I hadn’t updated this blog. I was quite busy but I really avoided to comment on the latest developments at Apache and OpenOffice.org. Now that the OpenOffice.org project has formally been voted as an Apache project in incubation phase, I feel I can more easily comment on this latest move.

To start with the straight question; what do I think about this? I do have mixed feelings about Oracle moving the OpenOffice.org assets to the Apache Foundation. As explained in the Document Foundation’s official press release, this is a missed opportunity to reunite OpenOffice.org to the Document Foundation. By reuniting the two Oracle wouldn’t have accomplished a reconciliation, as there was no real need for this (whatever reconciliation would happen on a personal level) , but it would have brought order and coherence to the free and open source software office suites. Instead, Oracle chose -in a move where resentment and vengeance were not absent- to dump the OpenOffice.org code and trademark to the Apache Foundation without the Oracle engineers who had been working on it since fifteen years.

The player who was apparently enjoying the announcement in the most public fashion was IBM. Trailing the formal announcement of Oracle, one very official press release from Armonk, followed by IBM bloggers with an uncanny sense of certainty and confidence that OpenOffice.org had come of age at last. Ten days after the announcement, the press is anything but enthusiastic, and the promoters of the move to Apache resolved themselves to address the obvious elephant in the room: LibreOffice. If anything went really bad in these past ten days, it would be the willful ignorance by corporations of the community itself, and its move to create the LibreOffice project and the Document Foundation 8 months ago. I guess we will wonder for a long time why it was deemed necessary by some to ignore the basic reality around LibreOffice and OpenOffice.org: While there might be two projects, there really is only one community. Anyone trying to pretend it otherwise would miss the big picture.

But then, where does it leave us? Nowhere new, really, and this for two reasons.

The incubator project called OpenOffice.org might end up being very different from the project currently located at www.openoffice.org ; the governance structure, now led by the Apache Foundation, the few proposed developers are different people (I will refrain to sing the now famous tune “but they don’t have enough developers” I’ve heard so much about LibreOffice and that I still sometimes hear). Sure, a few people from the “former” project have signed up. They even have the same old community manager ad vitam ; but when you look closely, it’s hard to see anyone there who would be able to contribute anything meaningful except for two kinds of people: IBM & Red Office engineers. Their number barely amounts to a dozen. This number and the people who either fish for opportunity or hold personal grudges against the Document Foundation (there are always people like that) make up the list of the OpenOffice.org project committers.

Second, I cannot imagine the relevance of a new Openoffice.org project that would compete against LibreOffice. The “competition-is-good” argument does not stand here, as it would be a mere division of resources. That’s why I think that the project will have to find a different role and mission than to do exactly the things it was doing before. Side-stream (and not upstream) code for Symphony, LibreOffice, common development house for ODF APIs and libs are honorable and relevant goals for such a project.

But I see something else happening that is actually quite good in my view. The presence of IBM developers inside incubator project means that at the very least, IBM will be pushing code to the OpenOffice.org codebase, effectively changing the “orbit” of the OpenOffice.org project from Oracle / Sun to IBM. If I take my reasoning a bit farther, it might mean that IBM will directly influence the project inside Apache, essentially making it progressively different from the LibreOffice project. It would reinstate, then, the dichotomy behind a proprietary office suite and its weaker cousin, with Symphony instead of StarOffice (unless IBM would liberate the code of Symphony, which would be an excellent move).

With all the points discussed above I have not mentioned the possible opportunities for collaboration between the two projects. I think there are very clear and exciting ones, especially around ODF, which unites us all, from IBM to the Document Foundation. That’s why I welcome the Apache Incubator project for OpenOffice.org despite all its shortcomings and the missed opportunity. I think we’re better with it than without it and prefer this to a slow death of the project in the hands of Oracle. True, I have refrained from casting any non-binding vote on the Apache lists in favor of or against the Apache incubation of the OpenOffice.org project. I feel it wouldn’t have made any sense to cast a non-binding ballot. I look forward working with the OpenOffice.org project, and believe very much that in the end, not in a very long time, we will be truly reunited. In the meantime, and to quote from the press, let’s build the most exciting Free Software project besides Firefox, LibreOffice!

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.

True, the Document Foundation and the LibreOffice project have the goal to further and secure the development of the OpenOffice.org project. But we also believe we should go beyond that and that’s why we welcome everyone interested in contributing, not just specific people we know. But you hardly never start with nothing. Our base is the OpenOffice.org community, with its history, its common knowledge and habits. Sometimes these habits need to be modified or even abandoned, sometimes, they reflect the result of years and years of community experience. But in any case, we are not looking backwards; we are looking forward knowing that what we are creating is fundamentally the right thing to do. Everybody, whether old-timer of the OpenOffice.org project or newcomer should feel at home within the LibreOffice project. Legacy should inspire us to reach beyond its past success and should never be a burden. And if I have not told you so before: Welcome to the LibreOffice Project. Let’s build something exciting!

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!

This essay is not really about the interesting but sometimes fuzzy back and forth between Canonical, the Gnome and KDE projects. This belongs to another level of discussion about cooperation and community processes. Let’s start with some basic definition. When we talk about Free and Open Source Software, we essentially describe two elements: 1) the availability of the source code of that software 2) the rights or freedoms that come with the software itself both in its binary and source code form. Both freedom and source code do not imply, let alone advocate the need for a community. You can perfectly use Free Software that is not developed by  a community and it will be Free Software; it will be software that comes with a Free Software licence, conveys the rights described in its software licence and of course provide the source code and binaries. For instance, the Sylpheed mail client is a venerable yet advanced mail client developed pretty much by one developer and it is Free and Open Source Software (the difference between Free Software and Open Source does not matter much at this point). There is a fork of Sylpheed that is perhaps more popular than its parent, and it is developed collaboratively. Of course it is also Free and Open Source. Its name is Claws Mail. I use it  as my default mail client on Linux as I think it brings some features I need compared to both Sylpheed and Thunderbird or Evolution.

So how does the notion of community get into the mix? That is not an easy one to answer. Let’s just say that because Free and Open Source Software conveys certain freedoms and mandates the availability of the code in its source form, anyone can hack it. Wether its author agrees with patches and changes some new developers might propose is exactly where the notion of community takes shape. (Of course explanations on the new sociology induced by the Internet are also valid but are perhaps somewhat too broad for our specific question). As it were Simon Phipps and others, such as Yochai Benkler have defined the availability of the code both in its source and its binary form as digital commons. The term commons itself goes back to medieval economic concepts, as the “commons” were in western Europe the acres of land that was used by the community of peasants by opposition of the rest of the land that was mostly used by the local lord either for his own consumption or as a certain quantity of agricultural goods meant to be sold on regional markets.

Digital commons are thus code that is out there and can be studied, hacked, used and distributed by anyone. Sometimes the “local” rules will make it so that the author will just produce the code in an opaque way, put it in the commons but won’t do anything else and will not engage with the “community” out there. Pretty often the author will be authors who will develop the software collaboratively, attracting more contributors in the mix. That’s how Free and Open Source Software  communities start. We thus have isolated the “big bang” moment of the community in a Free and Open Source Software project. It is made up of three coordinates:

• the good will of the first author of the code
• the actual interest of people in the code and the project
• their will to contribute – and their subsequent contribution

If you tie these three elements you will have the necessary conditions for the birth of a community around Free and Open Source Software projects. And just like the Big Bang is followed by the expansion of the Universe, we now have to see how a community works.

If we study the three conditions quoted above, we will see that as soon as the code is open to participation and contribution, what’s really missing is the people able to contribute, and their contribution. This stage is crucial, as it is the real first challenge for a FOSS community. If the author of a FOSS project only codes in a language he and another person are familiar with, not a lot of volunteers will show up. In short, the author needs to make the project friendly enough so that the barrier to the contribution is acceptable  so that several people may contribute to it. Yet, you will find many people in Free and Open Source Software projects who are not hackers nor even core developers. Some will still work with code, such as QA testers or localizers, while some others will not even work remotely with code: User Interface teams, marketers, documentation writers, etc. If we push our journey to the other end of the community, we will find users. Yes, users are part of Free and Open Source Software communities too, even if they don’t contribute anything. They’re connected to projects by the mere fact that they’re using digital commons. What’s more, Free Software licences are often described as giving more assertive of users rights than of developers, which can indeed be argued in the way copyleft is implemented.

We thus find ourselves in diverse communities. They seem to encompass anyone from the core developers to the blissfully unaware end user. But how are these communities supposed to work? Can one end user show up on a forum and make demands based on his/her own needs and expect to have that demand fulfilled? Obviously no, or rather, not in this way. This is why understanding how a community works, once it is understood how communities are born and what they’re made of matters a lot.

Simon Phipps usually explains there is no such thing as a community. There are, however, different kinds of communities. According to Simon, there may be three types of communities around digital commons:

• the core developers community
• the extenders community (QA, localization, documentation, etc.)
• the users community.

Each of these communities can be seen as having its standing arranged as a concentric circle around the software commons (the code) and its influence on it decreases as it lies farther away from the code. The reason for this is the barriers of access to the code: core developers can obviously change the code directly, not marketers nor end users.

Yet, it is not as simple as that. For all the accuracy and elegance of the model described by Simon, I believe it is amendable in several ways. Also, the model ignores several elements of a sociological and symbolic nature which will be discussed in the part two of this essay. But perhaps more importantly, it takes into account the value of contribution and community process in an incomplete way. Read on!

I am thinking about the victims of this catastrophy, and I would like to express my deep sorrow. I hope that the rescue teams will be able to take out all the victims who are still alive under the ruins. We had some good news from Japan: It seems that the Japanese team of LibreOffice is safe -I am not sure if everyone is though, but I really hope so. Also, my good friend and longtime contributor to the OpenOffice  project Hirano Kazunari is reported to be alive and safe with his family. I had real concerns about him as I know he lives in the norther part of the Honshu island (the main island of Japan).

The issue is that our world is not just being torn apart by natural catastrophies; man also kills man. I would just like to express my solidarity and support to our users and volunteers of the Arabic world; people from Egypt, Tunisia, perhaps even Lybia, Yemen and elsewhere. Some of them have to fight for their rights, or sometimes for their own survival.

In these situation, the Document Foundation cannot do much, of course. But we are all humans, and we are a community, the Document Foundation’s community. We hope you and your relatives are well, wherever you are, and we hope to work with you in the future and for a very long time.Take good care of yourself and your relatives.

(If you live in Japan and you’re susbscribed to any of the TDF lists, please, say hi. We’d love to hear from you. Also if you live in Lybia, Tunisia, Egypt, Bahrein, Yemen… please ping us as well.)

That wasn’t my idea, but there’s evidence I was one of the culprits (I’m the guy holding the candle). Sigh … Anyway, since I’m no more in charge of the OOoCON and that I don’t even know whether they will be an OOoCON at all in Paris or elsewhere it was time to think about a conference for LibreOffice. As it turned out the feasibility of such a conference had already been somewhat studied and that’s how we came back with the proposal of Paris as the location of the first LibreOffice conference. I guess it’s useless to say that I -we- are proud to host it in the City of Lights and that we’re far from realizing the workload that will be necessary to invest in such a project. But what should be stated, as it has been in our press release, is that the conference of 2011 will be an exception in that it will be the only one that will not be decided by our community. The choice for a location for the LibreOffice conference of 2012 will be the result of a transparent community process. Please accept our apologies for this “delay”. We hope to see many of you in Paris in October 2011!