Category Archives: Open Source

AppSet: a refreshingly nice package manager for Arch Linux in the times of app stores

Posted on by
1

In this post I will not talk about LibreOffice or open standards  but I thought this could be of interest to GNU/Linux users out there so feel free to comment and discuss.

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!

A Word of Thanks

Posted on by
1

Yesterday Michael Brauer posted on the OASIS ODF TC mailing list his farewell post. Michael, like a very large number of the other employees of the “Oracle’s Hamburg Business Unit”, if not all of them, will be let go by the end of the month. If you wonder what the “Oracle’s Hamburg Business Unit” is, it’s the people who have been developing a large part of what was OpenOffice.org and before that, StarOffice. I remember the company when it was a privately owned entity called StarDivision. I have contributed and interacted with these people for over 10 years. I guess I will see some of them working for different employers; sometimes as competitors, sometimes as partners. But we will see us again one day or another, and I look forward that day. I have made a few friends there; these are bright people, and they have played an instrumental in the expansion of Free and Open Source Software, and dare I remind it? ODF and Open Standards as well.  I sincerely wish them the best for the future, whatever road they choose to take. This “business unit” has been known under many names during all these years, and I understand very well that the present days must be sad and sorrowful days.

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!

 

Letting dogs bark and answering real questions

Posted on by
3

I was expecting the point in time during the setup phase of the Document Foundation where we would start to hear the first critics and doubts about what we are doing and where we’re heading. This is never a good time, not because the questions make me uncomfortable, but because I either know the answer to these questions or I believe we will find the answer to them, yet, I cannot simply answer them with a short email. It requires more time and effort than that, and sometimes it requires an education that goes both ways: Listening people voicing their doubts, their questions and frustrations, and have people understand that we can’t do everything right at the same time, that we have limits, and that we’re only trying our best.  It is an exercise of patience and passion at the same time, and it’s an everyday drill. Ultimately, we collectively grow stronger, and we come out of this phase as a more effective team than before.

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.

Links for the end of April

Posted on by
Reply

I am having a very busy month of April, but I mean, a really busy one. I am alive and kicking, but I am swamped.

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.

What does Community really mean? (Part 2)

Posted on by
Reply

In the first part of this essay I attempted to describe how communities around Free & Open Source Software (FOSS) projects are born and what is their underlying model. After having described the conditions necessary to have communities emerge around Free and Open Source Software I used Simon Phipps’ s typology of communities in order to highlight the various roles that are found in these groups, and how several sub-groups may be distinguished inside a FOSS community. I ended up the first part by hinting at the limits of that typology. Here’s why.

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!