Free Your Mind, Not Just Your Software

The Free Software Philosophy

The philosophy behind the free software movement is noble and well-intentioned. Projects that have chosen to operate under this philosophy have been wildly successful and have produced outstanding products. In many ways, I enjoy the fruits of free-software projects. My laptop runs Kubuntu Linux. OpenOffice.org is my office suite of choice. Firefox is my default browser. WordPress is my blogging platform of choice. Rockbox is my MP3 player firmware.

Having benefitted so greatly from using free software products, I have even done what I am able to contribute to free software projects, from introducing others to the software, to writing tutorials, to attempting to help other users in support forums, and even trying my hand at contributing code in the form of plugins and themes.

One of the fundamental principles of free software philosophy is the right of users to form a community, to use, share, change, improve, and help others to use software. This philosophy states that users should be free to use, to study, to modify, and to redistribute both the original and modified copies of software.

Thus, the free software philosophy inherently encourages those who might not otherwise choose to do so, to get involved with the project. This involvement  from the users' sense of altruism (for the good of others/the project), sense of belonging (to be part of the group/project), or sense gratitude (to give back to a project from which one has benefitted).

Unfortunately, I have seen those who espouse this free-software philosophy also exemplify stifling closed-mindedness and attitudes that actively drive would-be contributors away from, rather than bring them into, the project community. A few recent cases in the WordPress community belie close-mindedness, arrogance, condescension, and nepotistic hypocrisy - attitudes that are counter-productive to building free-software communities.

The Unforgivable Prodigal Son

In the first case, a WordPress plugin author was using some practices that are clearly unacceptable within the WordPress community. This plugin author was allowing users to download and install his plugins, but upon attempting to use the installed plugin, the plugin forced the user to register his email address with the plugin author, and was also forced to double-opt-in subscribe to the plugin author's internet-marketing-focused email list - an email list that many users complained of being "spam"-like, due to its frequency and lack of focus on the users' installed plugins from the author.

Clearly, these practices are outside the acceptable bounds for the WordPress community - and, especially, the wordpress.org plugin repository. Thus, the author's plugins were removed from the repository.

However, after weeks of back-and-forth discussion with this plugin author, he decided that being a part of the WordPress community and having his plugins listed in the wordpress.org plugin repository was more important than forcing users to subscribe to his email list. He decided to modify his plugins to make the email-list subscription optional.

What was the response of the wordpress.org repository? Rather than welcome him with open arms, and celebrate that a "prodigal son" would embrace even a bit of the free-software philosophy, the response was instead, "Thanks, but no thanks." This plugin author was told that, no matter what changes he made, his plugins would never again be accepted into the repository.

As one might expect, this response discouraged the plugin author to the point that he decided that pursuing making his plugins repository-acceptable not worth his time and effort. Further, he decided that he would no longer continue to develop free-cost plugins.

While I question the widespread usefulness of most of this author's plugins, he did develop several very useful plugins. So, not only did the response from the WordPress project actively push a developer away from the WordPress community and away from free-software philosophy, but it also reduced the availability of plugins to end users of WordPress.

And what was the reaction of many in the WordPress community? In essence: good riddance; once a spammer, always a spammer.

This response assumes that the plugin author's only intent was to be a "spammer" - that he was up to no good whatsoever. In reality, the plugin author's intent - misguided and completely unacceptable as it was - was to support his free plugin development and free plugin support by driving traffic to his profitable email list.

Such a response is both unacceptable and unwarranted.

First, the author's plugins were not "spammy" or otherwise harmful. They provided value and usefulness to those who use them. While the author's tactics for forcing subscription to his email list were wrong, the author fully and appropriately complied with un-subscribe requests. While the email newsletter is not useful to many users, it does not meet any of the accepted definitions of "spam".

Second, it is important to understand that, prior to his plugins being removed from the repository, the plugin author was given no official warning whatsoever that his plugins violated the repository guidelines. Several users complained about the plugins in the wordpress.org support forums (to which the plugin author responded), but he was never formally notified that he would need to modify his plugins or face their removal from the repository.

Third, regardless of his reasoning, the plugin author relented, and decided to accept the terms specified in the repository guidelines. Whether or not he agreed with them, he willingly chose to modify his plugins so that they would conform.

So, this plugin author was given no warning in the first place, and then was given no opportunity to resolve the problems with his plugins: no warning, no forgiveness, and no attempt to bring this plugin author into the WordPress community or the free-software philosophy.

As a result, a potential community member was actively driven away from the community, and the community has less code contributions to show for it.

No Learning Curve Allowed

In the second case, a new developer decided to develop and release a WordPress plugin. This developer, being new to the GPL and to developing for WordPress - and thus mostly ignorant of GPL requirements and the free-software philosophy of WordPress - made a mistake.

This plugin author noticed that users were removing or replacing a public-facing attribution link he had put into his plugin. So, in response, he base64-encoded this attribution link - not realizing that he was, in effect, thwarting the user's intent in using his plugin. This author also had not explicitly declared in his plugin that it was released under the GPL.

This plugin author - also without warning or notice - found that his plugin had been removed/disabled from the repository. He inquired at the WPTavern Forum, and was told that the reasons for his plugin being removed were primarily the base64-encoding of the attribution link, and secondarily the lack of license disclosure.

The plugin author confirmed this information with the wordpress.org plugin repository moderator, and based on this information, demonstrated his understanding for why the encoding was unacceptable and immediately made the necessary changes to his plugin.

(Side note: kudos to the repository moderator, for working with this plugin author and for restoring the plugin once the changes were made.)

Again, it is important to understand the context. This plugin author did nothing that explicitly (or implicitly) violated the stated repository guidelines. His plugin was removed, he inquired as to why, received - and accepted - an explanation, and immediately made the necessary changes.

This situation - primarily the assertion that not disclosing license information in the plugin would result in the plugin being removed from the repository - caused me to take a look at how well the plugins from some of the more high-profile plugin authors conformed to that (unpublished) requirement.

What I found astounded me. Only 26% of the repository-hosted plugins written by Matt Mullenweg, Mark Jaquith, Peter Westwood, Ozh, and Viper007Bond explicitly disclosed license information - yet none of these plugin authors was under threat of having his plugins removed from the repository.

I published my results (in a blog post that was generally well-received by the authors whose plugins I audited), which led to Peter Westwood (Westi) adding to the upcoming dev chat a discussion point regarding proper means of license disclosure for plugins.

What I soon discovered was that some of the core developers - including Matt Mullenweg and Viper007Bond - dismissed the concerns out of hand, claiming that the plugin author in question clearly must be a "dirty" (or "lame") "spammer", and thus up to no good, due to his use of base64 encoding.

Once again, apparently the WordPress project would rather actively drive away a potential community member, rather than accept that he made an honest mistake and that he resolved the problem once he understood it. Likewise apparently, the project would prefer arrogantly and condescendingly to declare that, "with regard to the GPL and WordPress, ignorance isn't an excuse," and that "no good intention could ever come from code obfuscation," rather than show any patience with a developer new to the GPL and free software or to offer any forgiveness for mistakes that he made.

Membership Has Its Privileges

In the third case, a plugin author decided to fork an existing, very popular plugin. The plugin author intended to write a case study on "creating a clean plugin, with emphasis in source code’s good practices." This author also discovered that his plugin had been removed from the repository without warning.

Upon inquiring, this author learned that his plugin had been removed because an unnamed source alleged that his plugin contained certain security vulnerabilities. (Note: I discuss the handling of this issue elsewhere.)

As it turns out, the alleged security vulnerabilities in question originated not with this author's plugin, but rather with the original plugin he forked. Not only that, but the same alleged security vulnerabilities were propogated into other forks of the same original plugin.

On the positive side, the author was able to fix the alleged security vulnerabilities in his own plugin as well as alert the authors of both the original and the other forks regarding those vulnerabilities. Further, in the end, the author's plugin was restored to the repository.

However, the case demonstrates a double standard applied to this plugin author. His plugin was removed merely on the word of an unnamed informant. As far as I could tell, neither the other forks nor - more importantly - the original plugin were ever treated similarly by being removed from the repository until the same vulnerabilities were fixed.

In fact, to date, the original plugin is still available in the repository, without the now-known security vulnerabilities still not fixed. What is the difference? Usage and Popularity.

The author in question had only several hundred downloads of his plugin. The original plugin is currently the #2 Most Popular plugin in the repository, with over four million downloads. The author in question was relatively unknown, while the author of the original plugin is one of the most well-known.

If the security vulnerabilities were severe enough and the risk sufficiently high to remove from the repository a plugin downloaded a few hundred times, then the risk posed to users by the original plugin must be immesurable - and yet, the plugin remains in the repository, with severe security vulnerabilities intact. The unknown author's plugin was removed immediately and without warning, while the well-known author's plugin remains, after weeks of notice of the vulnerabilities. The well-known author was informed directly regarding the security vulnerabilities before any action was taken, while the unknown author was never contacted directly before or after action was taken.

This practice is a nepotistic double standard, applied based on the relative popularity of both plugins and authors. It is also hypocritical: the plugin that - by far - posed the greatest risk was left, unpatched, in the repository, likely due to the very reason that it posed the greatest risk (sheer number of downloads), while the plugin that posed little-to-no risk (both because of its miniscule number of downloads, and because it didn't actually call the functions that contained the vulnerable code) was removed from the repository without warning, hesitation, or question.

Leading By Example

While all of the scenarios I have mentioned deal with the wordpress.org plugin repository, my statements are in no way intended to reflect upon the repository moderator, whose responsibilities are as arduous as they are thankless. MarkR works incredibly hard moderating the repository, and has been one of the lone bright spots in each of these scenarios. He was the one who worked with the plugin authors in the latter two cases, to help them restore their plugins to the repository.

I would also like to point out that Mark Jaquith has also been nothing but helpful, both in helping the plugin authors correct the problems with their plugins and also in helping to explain to the community the actions that were taken and the reasoning behind them. He has shown patience, understanding, and respect in dealing with the WordPress community regarding these issues.

Perhaps more of the WordPress community needs to follow the example set by MarkR and Mark Jaquith.

Conclusion

This is no way to build a community.

All of these actions, behaviors, and attitudes are damaging to the WordPress community. Because of them, would-be community members are driven away, less code that might benefit the community is contributed, and WordPress users are left exposed to security vulnerabilities. Because of them, new and non-expert developers are discouraged from attempting to contribute. Because of them, opportunities to reach out and to bring others into both the WordPress community and the free-software philosophy are squandered.

Free software projects (and the communities built upon and around them) are best-served by attracting to the community all who would participate - whether that participation is contributing code, just using the software, or somewhere in-between - by encouraging contributions from all who would contribute, and by displaying patience, understanding, and a willingness to help such contributors when they make mistakes as they are learning how to contribute.

Rather than close-mindedness, display acceptance, understanding, and tolerance. Rather than arrogance and condescension, display respect, humility, and a willingness to forgive.  Rather than hypocrisy, display openness and truth. It is in an environment that displays such attitudes that a free-software community can best thrive, and in which the most noble and well-intentioned principles of free-software philosophy are exemplified and promoted.