One regular reader of this blog contacted me a few days ago to share a few suggestions and some concerns about the LibreOffice project. I did not agree with many of the points he was making, but a few of them made sense. I’d like to discuss the main one, because I think there is no clear cut answer about it even inside the LibreOffice project.
The matter at hand was that this reader felt that we could not really accomplish much in the way of a quality product if we were to continue to function as a community. Should we either “dump” our community, if it were even possible, or should we as project turn the tables and radically change the way we work?
If such questions seem outrageous, they tend to highlight what many people in the I.T. and even elsewhere think: Free & Open Source Software projects should deliver great products, but unfortunately, they seldom do. There are several problems with this assertion, the first one being that contrary to popular belief even inside FOSS communities FOSS projects do not produce nor develop products. Products are created by companies and they are complete and finite constructs. Online communities on the other hand, produce commons: software or media commons most of the time. A product does not come out by sheer will: it comes with warranties and a professional support structure that must exist and be operational, for consumers or professionals. LibreOffice, Firefox, Linux distributions, VLC, the Gimp, Emacs, etc. are software commons. They may do their job really well, they may be very innovative, but they cannot be products. What could be a product is a company providing support and services on a software. In this case, it wouldn’t be a product as much as a service, but you see my point: the offer itself would be the service and the software commons themselves would not be sold; only the added value can be monetized.
I frequently see this mistake being made even inside FOSS communities. Sometimes this stems from volunteers who want to help by promoting the software and as such they will think of what should be done in terms of “marketing”. But irrespective of the fact that “marketing” has changed a lot since the good old “4Ps” and the “explain what your product does to your client”, you cannot market software commons like you would with a product; you would create wrong expectations and disappointing users.
I do believe however that some of this misunderstanding arises out of frustration that a project is not headed to where we think it should, or that the software has not added the feature XYZ yet. Yet frustration is of little use to a project if you don’t try to change things from within. Obviously, not everyone has time to contribute nor is able to develop features. But does it mean that FOSS communities develop less innovative software than their proprietary counterparts?
Not at all. But it is important to remember that:
- Proprietary software products are different from Free and Open Source software, which is by definition software commons.
- Any glance at the IT industry would prove otherwise, but expectations vary from one sector to the other, especially when it comes to software everyone uses. That’s the case with LibreOffice, and people will mistake innovation with changing the interface all of a sudden for no seemingly understandable reason (case in point: the Ribbon user interface). Being a “user oriented software” has its blessings. And its curses.
- Communities are not companies. Individuals, commercial, academic and governmental entities coming together to produce software commons is very different from someone selling products or service for his own benefit or the one of shareholders. You may think one is more effective than the other, but in terms of how you can influence each of them, the verdict is clear: communities are the right venues to involve any interested party to contribute. That is not usually the logic with regular businesses.
So where does it leave us? I think it is important to remind ourselves what it is that we want. I do wish LibreOffice could get even more patches and features in, improve its quality. I do not believe that getting rid of our community of contributors is a right price to pay for such an expected outcome. True enough, the Document Foundation can invest resources to “get things done” and ensure certain tasks are performed in a timely fashion, to the extent our existing contributors would not be able to do it. But here lies the limit of the distinction: knowing when to rely on service providers and when to rely on our community. The answers are not always easy to come up with.