Some time ago, I stumbled over a rather aggressive comment in Quim’s blog, which made me wonder if we are approaching the topic of open sourcing Maemo components in the right manner.
The comment in question took big offense to the way the page Why_the_closed_packages presents reasons for keeping things closed source and it appeared to me that the meaning of the different reasons in his world view was completely different to how I perceive them. I usually classify myself as a open source lover with a realistic sense of why there sometimes has to exist closed source software but I’ll try to remain objective and respectful to both sides of the spectrum in this article.
To further understand this problem, I asked Paul Fertser of #maemo – one of the people I’ve had most intense debates with about licensing issues in Maemo and why things are the way they are, to read Why_the_closed_packages sections 1 and 3 (Reasons, Requesting the opening of closed components) with his bias towards free software and document his thoughts of it. The quotes are presented with his permission. His background is in the OpenMoko community which is on the more liberal end of the open source software spectrum in the mobile Linux space.
Why did I ask someone with a huge bias to do this? Because he has been showing willingness to try to understand why things are they are in order to make more sense of the open source situation in Maemo – and that is something I respect. In his reaction to WTCP, he writes pretty clearly why it is useful to approach it with this angle:
“I assume that the purpose of the page is to make the process of open-sourcing in particular and development in general efficient and constructive.
That means that neither your time, nor time of your colleagues should be spent on void talks about something you can’t change anyway and that people proposing opensourcing a particular component should concentrate on providing the most relevant arguments instead of taking part in religious debates.
To fulfill this purpose the page should be understandable and acceptable by the target audience.“ –Paul Fertser
The people who are going to make the most noise about open source policies are who our target audience of this page should be in order to be able to move away from time consuming religious debates and into constructive debates and discussions. That said, the page should also target developers for whom open sourcing a component would help their development.
The important thing is to spend more time on the actual open sourcing process than in time consuming discussions.
PF suggests some guidelines for the page, which I quote verbatim as see mostly no argument in what he states, emphasis mine:
First of all, you mainly target developers. And you take into account that among those interested in open-sourcing there will be a considerable amount of “free software zealots” who are sceptical and irritated about the proprietary software by default. So to avoid aversion that will be later reflected upon you and your fellows in form of negative emotions and useless quarrels i think it would be beneficial to follow several guidelines:
* Write from a hacker point of view, that way they’ll feel you’re “with” them and not “against”, that makes people feel much more comfortable, take emotional response of your readers into account.
* Avoid buzzwords and formal style, a convincing page should look nothing like a press-release as we all know everything that comes from a PR department smells like(added by editor) lies.
* Add technical details, that makes you look understanding the issues in deep, increasing credibility of other information.
* Do not use really questionable arguments, that’s like a red flag to a bull.
* Take into account many developers do not understand business and business reasons, so those should be explained in a more detailed way.
To me it seems it would be nice to have some introductory words on the page, at least that would make me less irritated and more constructive right from the beginning. I would gladly accept something like:
“We all know proprietary software sucks. Indeed it does, many of the headaches could have been avoided if there was less of it. Unfortunately, the reality is working in such a way we have to make compromises, that’s unavoidable. On the other hand, there are actual possibilities to free more of Maemo and Maemo-related software, read on to find out what can be done and how to perform that.”
That would make me feel comfortable because it looks informal, friendly and understanding. Also it gives hope. A nice way to get a pleased and listening reader.
While I don’t fully agree with the wording of the text or opinions of PR departments, there’s some parts I do find worth to mention. The best way to deal with an emotional response due to a default irritation of proprietary software is to provide technical details how the process actually work.
Like what happens when someone requests the open sourcing of a component. Does it go to a manager who agrees or disagrees or is there a wider process of checking with lawyers etc?.
These processes are not documented and transparency of these processes will help understanding how things are proceeding and provide examples of how open sourcing is done in practice from within a company. It is important to note that open sourcing does not happen overnight and present the practices.
The next part of this series will be about the exceptions to open sourcing and discussing the different reasons for having some components closed source.
Thanks to Paul Fertser for his input to this article.