Addons, Extensions, and Mods – Oh My!

I’ve been doing a lot of work, recently, in three different projects: MediaWiki, Minetest, and Etherpad Lite.

In each of these projects, there exists at least one way to add on small, additional features, or change the way the software behaves. It has struck me as a very interesting construct, and I think that it could be a very useful thing for almost any project to have. So, I’d like to share what I’ve learned.


My experience with MediaWiki extensions is mostly through the two I’ve helped so far: EtherEditor and UploadWizard. They both do a lot of different things, and they both tie into the MediaWiki interface in one way or another, but the really interesting part of the development of an extension is that, while there may be a lot of interplay between the extension and MediaWiki proper, the extension very much feels like its own project. You can easily install and remove the extensions, and they sometimes have their own code hosting. Having this separation is immensely helpful for the developers, because it gives a sense of independence, and allows for much more modular code.

Of course, it’s also a gateway to modifying the core of the project. While I did fix most of the bugs I found in UploadWizard by simply changing the UploadWizard code base, there were a few instances where I was forced to enter the MediaWiki code, and fix something there. Maybe that seems undesirable, but having worked with the extension for a few weeks by then, I was relatively well-versed in the MediaWiki style, and could dive in with relative ease to find the problem. This leads to another benefit of this kind of contribution: It makes for very literate contributors, and since everyone has to play in the same sandbox, they very often contribute any patches to core back to the main project.


I’ve talked about Minetest before, but this time is a bit different: The modding API has existed for many months now, and in the words of Perttu Ahola, the main developer, game content has exploded.

The really interesting thing about the Minetest system is, while the core game is written in C++, the mods are all written in Lua. This was a choice made early on, and it somewhat separates the two communities—modders and “core” developers. While I’m not sure there’s any way to circumvent that separation, I feel it could be handled better, and perhaps I can muse on that in a later post.

In any case, the Minetest system also offers a very interesting benefit: People have dived in to create something, and hopefully learn something, who otherwise might not have learned to program at all. This is a parallel to the World of Warcraft modding community, and even uses the same language. People who happen to learn the game, and enjoy it, eventually learn something of the Lua API and start playing with it. After talking to the rest of the community and learning from them, they learn even more about programming.

Another confusing part of the Minetest modding community is that, while mods are simple to install, there is no real central place for them as yet. I’ve done my best to create a starting point, software-wise, but it has mostly been stagnant, and nobody appears to be interested in using it. The forums for Minetest house the majority of the release announcements and documentation, but the community could definitely use a move to a more comprehensive place for issue tracking, wikis, and code hosting.

Etherpad Lite

The final example is one near and dear to my heart. Etherpad Lite, a fork of Etherpad, has been recently building a more robust community, filled with new faces. A lot of documentation was provided, and suddenly the Plugin API was useful, and people started writing code for it.

The most interesting change here is that, while a lot of people have enjoyed using the Plugin API, there are still a lot of missing features. Almost every plugin that gets discussed in the IRC channel (#etherpad-lite-dev on Freenode, come join!) will require some form of modification to the core. But the really cool thing is, the contributors are able to just do it! Now, with MediaWiki, it’s definitely possible to contribute a patch to core. But the response time is usually pretty high, which is fine, but it makes for some very slow integration time. If a company wanted to deploy an extension, but needed a new hook to do it, they might need to wait weeks, unless they made a lot of noise, to see that new hook integrated into the core. There’s a danger, there, of losing potentially helpful contributors. To the credit of the Etherpad Lite devs, they have responded with a latency of, at most, a day or two. And they’re getting more numerous, and faster.

Conclusions, take-aways, do this with your project

I wanted to compile the really useful, bare-bones, what-you-must-absolutely-know points of this post, so that anyone interested in adding this sort of system to their project, or anyone interested in improving their existing system, can use them. Here they are:

  1. Allow as much freedom as possible to your contributors. I’ve seen projects that require a specific API be used, that require registration and/or payment for the SDK….none of that, please. If you’re going to let people build on top of your project, give them an open field to build on, not some gated community.
  2. Choose a simple language. Now, if you’re paying attention, #1 should mean that you allow any language, but assuming that’s not possible, please don’t choose a compiled language. Use something interpreted, and make it at least somewhat relevant to your project. For MediaWiki, PHP was an obvious choice, but Minetest’s choice to use Lua also made some sense.
  3. Make it sort-of-centralized. However much I disagree with GitHub, I have to begrudgingly say that they have a nice system for this sort of thing. I use Gitorious to host my mods and plugins, but they don’t offer issue tracking, so if you do go that way, be prepared to set up Bugzilla or something. Don’t, for example, host your mods on a forum. It’s not easy enough to access, and the information is too sluggish to access.
  4. Document it really well. Minetest does a pretty great job of this, since there is a big file with *all* of the API methods and tables, as well as the “default” mod which has pretty good examples for just about anything you might want to do. MediaWiki tries, I think, but they could use something a little more concrete.
  5. Make good examples. This is a sub-part of #4, but it also deserves its own separate item. With Etherpad Lite, we made a separate repository with the skeleton all built out. Neither of my other examples, to my knowledge, have such a thing–or at least, it’s not easy to find!

Please take these five simple points to heart, and do consider using this idea of allowing small additions to a project via simple, separate modules. It’s a really great way to build a huge community of awesome developers.

Parkour and Programming

In my free time, I sometimes practice something called Parkour. In fact, my username (MarkTraceur) comes from that art, because “traceur” is a term for a person who practices Parkour. This art is a very intense physical discipline, combining simple, natural movements with martial arts techniques to form a set of “best practices” when it comes to moving through obstacles. In reality, it’s just a set of tools that help you evaluate problems of efficient movement.

Well, since the rest of my life is dominated by software, the natural thing to do is to compare Parkour to programming, and see if I can’t learn, and teach, something interesting. First, I should probably explain how I see Parkour.


Parkour, as explained above, is an art of movement. It helps you train a set of movements to the point where you’re very comfortable with all of them, and can easily reach for and execute the best movements for any particular situation. These movements include such things as vaults (for getting over things), wall-climbing techniques (for getting up things), underbar techniques (for getting through things), jumping and landing techniques (for getting off of things), and other more general movements.

Parkour isn’t just about exercise and practice, though. The community and organized practice of it was mostly started with the mantra “be useful”, and there is a lot of philosophy that goes with it. There’s also a huge slew of mental preparation a person needs to do in order to do some of the movements, and even judging the best movements for a situation takes a lot of thinking.

The really interesting thing about Parkour, to me, is that there never seems to be a single “best” way to do things. While most people would look at a situation and agree that one movement or another seems good, another person might come in and have a different idea that works better for them. For example, while going over a rail with a speed vault might be good for me, a shorter traceur might be better served by going under it with an underbar. Many of these questions share a similar non-deterministic quality that really appeals to me.


While my blog is mostly frequented by technical people, I expect this article in particular might draw some traceurs who don’t fully understand programming! So, I’ll try to explain what’s necessary for this article.

Programming is the act of telling a computer, through a list of commands, how to behave and what to do. For example, as you’re reading this on your web browser, your computer is likely listening on a network interface (wifi, 3G, 4G, or ethernet) for connections. It doesn’t do that because it innately understands, but because a programmer somewhere wrote the necessary words that told the computer “wait here, and listen for this data, then perform this action”.


The really cool parts about programming and the really cool parts about Parkour, I think, seem to cross pretty regularly. In programming, I often come across a situation where the solution I create might not be the one someone else would use. Most of the time, these solutions differ in their speed, or in the amount of memory they use, but depending on what you’re trying to accomplish, either one might be “best”. Admittedly, there are certain things (like “crash the computer, delete all the files”) that would almost always be excluded from being the “best”, but there are so many different qualities of each solution that most of them will be good in one way or another.

But the fun doesn’t stop there! Most traceurs will continually train their skills over and over again. Well, programmers do that, too: The more we write in any language, the more fluent we get with it. The first time you use a language, you jump straight into it and try really hard to use it anywhere you can. Once you learn the language well, you keep building on that knowledge with additional libraries, additional and more difficult file structures, and so on. Traceurs will be familiar with this concept, called “progression”.

Even some of the simple philosophical ideas bridge the gap. Where traceurs say to “be useful”, most programmers will also recognize a similar concept. Where software is free, it’s common courtesy (or sometimes legal obligation) to release derivative works as free. Where you download a file, it’s common courtesy to mirror it if you can. Where you fix a bug in a free library, it’s best to contribute that fix back to the original author. This is also similar to the general traceur practice of leaving a training spot better than how you found it.


The biggest difference between these two art forms is the physical involvement inherent in Parkour. This makes it an extremely difficult thing for a beginner to do with any sustained effort–the physical demands of hauling oneself up and over walls repeatedly is not to be taken lightly! For those of us who love sitting in front of flashing pixels for hours (or days) at a time, it’s very difficult to start.

Another huge difference is that, in software, there are a lot more concrete solutions for specific situations. In some places, there are well-known mathematical proofs that show the superiority of one solution or another. This is a result of two other differences: One, programming has been around, and popular, for a lot longer than Parkour. Two, programming is much more concretely defined, due to its mostly-deterministic nature. Above, I described the non-determinism as being a similarity, but programming was a lot closer to being deterministic than Parkour.


For programmers

  • Parkour is fun! If you haven’t tried it, and you’re in the Bay Area, feel free to contact me and drag me out on a run.
  • Being useful, and generally being helpful to your community, is a great philosophy to have. It makes for a really cool community, and it makes you feel good!
  • Thinking about a problem as having more than one “good” solution is more productive than thinking about it as having only one “best” solution. Maybe you’ll eventually decide that, in this situation, there is a best solution, but not necessarily acknowledging it will help you to generalize the other solutions for the next time!

For traceurs

  • Programming is fun! Maybe it doesn’t seem like it, but there are a lot of similarities between these two disciplines. If you love the mental high you get from computing paths through a course, you’d also love the mental gymnastics involved in getting a computer to do what you want!
  • Other communities have similar philiosophies to “be useful” and “leave the spot better than how you found it”, so keep doing those things! In particular, contributing to the community is a really great thing to do, and traceurs (and groups of traceurs) should make that effort a priority. Even just welcoming the community into your training sessions is a great benefit.
  • If you don’t already consciously consider that multiple solutions might be desirable in a particular situation, try! Next time you go out, do your normal training exercises, but then turn around and look at the obstacles a second time. Consider what you might do if you were shorter. How would you get through if you had a broken arm? What about if you couldn’t touch one of the obstacles for some reason?
  • Thanks, as always, for reading, and go freely!

Hostility to Free Software (follow-up)

Last week, I wrote a blog post about people who seem to be generally hostile towards free software advocates. A lot of people weighed in, and I’m happy to say that it’s resulted in a significant shift in my thinking.

The first thing I needed to do was to split up the question into several parts; so I split it into different groups of interaction. Those groups, and my conclusions about them, are as follows:

Free software user towards other free software users

This category, I think, was the one I was most worried about when I wrote the original post. It’s clear to me now that, in order for someone to make most of the criticisms that I highlighted in the previous post, someone would have to be aware of at least parts of the GNU philosophy.

These people are usually irritated with a free software advocate who disagrees with their preferred licensing scheme. Copyleft advocates don’t get along with permissive advocates, and vice versa. I’ve mostly observed permissive license advocates being discourteous, but I’m sure copyleft advocates have been just as discourteous at some point.

This category of hostile interaction is absolutely ridiculous. Sure, there are disagreements, but it’s foolish to argue about such things. Even the most hardcore copyleft advocates agree that, in an ideal world, permissive licenses would be better. Copyleft advocates use the tools available to them to ensure the freedoms they desire, for themselves and their users. And permissive advocates, while they’re usually very friendly and practical people, get very offended by copyleft advocates who are too insistent, claiming that copyleft is too restrictive. Both groups have goals, but both are working towards digital freedom. That ultimate goal needs to be the focus, rather than the particular tools used.

Free software users towards non-free software users who make free software

This is something of which I’m guilty, I’m ashamed to say. People who make free software for non-free platforms, like the iPhone or Windows, are sometimes victims of criticism because they straddle a fence between two worlds. But that fence is a huge barrier to some people, and the people who sit on it can help bring people across.

The problem, I think, is that when I try to help these people find free tools (like Gitorious, for example), I tend to come across as being too focused on one side of the fence. The people in this difficult position see me as attacking them, or their decision to help people in this way. I could try to explain at length that I mean only to find better tools for them, but that seems like wasted effort. They appear to be doing good work, so why bother criticizing? Someone making free software with non-free tools should be encouraged to continue making free software above all else. It might be helpful to encourage free developers to use Gitorious from the start, but criticizing their use of GitHub now seems unnecessary.

Free software users towards non-free software users

This is probably the most ridiculous form of hostility surrounding the free software movement, and probably the source of a lot of negative feelings. Free software users and advocates might occasionally look intimidating based on the fact that their information is something most people don’t ever consider, and don’t already understand. This fact combined with the very serious nature of most free software advocates makes for a very difficult person to converse with.

The best way to deal with this situation, then, is never to criticize, and never to obstruct people. I maintain, as I have in the past, that it would be better to not help people to support non-free software. However, rather than simply refusing without explanation, or with only a few words. Explain a way to accomplish the same thing with free software, and why you prefer free software. The goal here is to be verbose, so brush up on your ability to explain things to non-technical users!

Free software users towards non-free software developers

This is a relatively justifiable form of hostility, since the objects of it are directly opposed to the mission of free software advocates. However, there’s a problem: Developers are the best way to spread free software (more on this later), and we’re starting to alienate them!

Maybe we can’t win these people over with words, but it would be helpful to stop alienating them, certainly. For now at least, my best advice is to simply not advocate to them. Telling somebody that they’re doing things wrong is probably not the best way to win them over, and that’s really our only tack with non-free developers. Simply allowing these people to be, and encouraging them if and when they create free software, is our single best play.

General advice

In general, there are some things we should keep in mind when talking to the public. First of all, try to avoid “smear campaigns”. This is one of the most common criticisms of the Free Software Foundation in particular, and it makes a lot of sense. While Free Software is a reasonable idea, some of the ways it gets spread can be a little unnecessary and hostile. Simply calling technologies by their proper names will not cheapen the message at all, especially when the person speaking is already criticizing the technology for valid reasons.

Second, focus on positive reinforcement, rather than negative feedback only when things go wrong. I touched on this somewhat in the previous sections, but here it is again: We should be seen as an encouraging community, rather than some resistance that fights against people. This is why sites like OpenHatch have such great importance to the free software movement–we should encourage people to do good work, rather than criticize them for doing bad work.

Third, consider now that other freedoms, freedoms that aren’t related to software, are also important. While most of the time, people who make this argument simply mean freedom of choice. I maintain that freedom of choice isn’t freedom at all, merely an illusion–similar to allowing prisoners yard time. If you allow some amount of space, that’s good, but it’s still prison. It’s the same with non-free software: You can choose a lot of different software just like you could walk around the yard, but you can’t modify or share it, among other things.

Supply and Demand

One of the interesting points I’ve heard recently is that there are two major theories about the most effective approach. Some people prefer supply-side advocacy. This method is when developers are targeted, and they change their ways. This method costs relatively little, because there are fewer people who are more aware of the subject, but it can also be severely tedious. As we’ve seen, non-free developers are very set in their ways.

The other theory is demand-side advocacy, which is focused on users rather than developers. This takes a lot of time as well, since users can also be set in their ways, but are also troublesome because of their lesser domain knowledge.

My view of this is that supply-side advocacy should be the focus. Developers, while stubborn, feel good simply by making software. Add in altruism as a motivator, and possibly the ethical benefits of allowing their users freedom, and they’ll certainly be interested in making free software….or at least, that’s the goal!

Demand-side advocacy can be helpful, but since a lot of people don’t understand software, it can be difficult for them to understand the importance. If the landscape of free software gets wider, users should start to spill over more readily.

Thanks again for reading this blog, and thanks especially to everyone who contacted me in response to the last post. As always, go freely!

Hostility to Free Software

The free software community has been around for quite some time now–longer than I remember, since I’ve only joined in the past few years. And for some reason, though that time seems to have been spent on good works that benefit humanity, and advocacy that teaches people how to be free, the movement is sometimes the object of some hostility.

With every blog post, I encourage people to comment by emailing me, but for this post in particular, I’d like to make a special request for feedback, because this particular problem is a very important one to solve. If you have any ideas about how to further explain the below points, please email me.


One complaint I’ve seen very often is that free software advocates are mostly zealots. However, whenever I come up against that complaint, I turn to the dictionary definition of “zealot” and find the following:

  1. One who is zealous, especially excessively so.
  2. A fanatically committed person.


Both of these possible definitions involve some version of “excessive”, but that has never made sense to me. The second definition also includes some sense of irrationality, which also makes very little sense. Free software advocates love freedom, it’s true, and would rather have freedom than convenience. But that exact choice, and the preference free software advocates tend to have, are exactly the subjects of many romantic depictions of heroic figures, both in history and in fiction. New Jersey still immortalizes it on their license plates, and countless authors continue to speak highly of those who choose freedom. So why should any commitment to that ideal be considered excessive?


The next example of hostility is the name-calling that happens from time to time. Free software advocates are sometimes called zealots, as explained above. But several other names are also in use.

The first, and probably most offensive, is “freetard”. This term is particularly bad because it also perpetuates the use of the term “retard”, which is itself extremely offensive. But tying that term to the honorable choice to be free seems especially wrong. Implying that digital freedom is caused by some lack of mental capacity simply doesn’t make sense.

The next term is “bully”, used sometimes by people who seem to think free software advocates are too insistent. This is a bit strange, too, since most of the tactics used by the majority of free software advocates are very passive. This term was probably brought on by some of the more controversial tactics used by the Free Software Foundation, which itself tends to use name-calling on occasion. But that organization, while very important, does not dictate the actions of the rest of the community. Their philosophy articles are helpful, and they have good ideas, but their actions don’t need to reflect on all free software advocates.

The last term people use, falsely in my opinion, is something similar to “communist”. Now, this particular example may not be terribly offensive, since the days of the Cold War are gone. But using terms that are untrue doesn’t help anyone. I hope to soon write further on this subject, but to briefly summarize, free software allows for too much freedom among people, and the free market would soon bring people to release their own versions of things, possibly for money. Socialism and communism, and similar systems, wouldn’t be fertile ground for software freedom; or perhaps more appropriately, free software wouldn’t be contained by those systems for very long. This is pretty clearly caused by the “open source” branch of the movement, where people emphasize giving back to the community, and communal ownership of the creative works in the society, but even that community appears to be more motivated by capitalistic intentions than anything else.


There are a few possible reasons listed above, but I’m hoping to come to a more unified theory, since none of the individual incidents seem to be self-explanatory.

One idea I had was that people might be seeing free software as a threat to the software industry. Many people confuse “free” as being mostly related to the price of the software, so their hostility might be caused by a concern that profits would be lost if free software took hold. Of course, Making Money Ethically is a potentially helpful solution to that concern, but very few people understand the concepts set forth there, and even fewer would consider actually implementing those concepts.


In closing, I’d like to reiterate my call for feedback. I don’t know why people react the way they do to free software advocates, but I’d like to revisit this question with some more interesting data. If you think you have an answer, I’d love to get an email from you. If you think negatively about the free software movement in some way, can you trace your perception back to something concrete? Please contact me with any information you might have, and if possible, indicate whether you’re comfortable having your email reprinted on this blog.

Thanks for reading, and as always go freely!

Free Software in San Francisco

I’ve lived in San Francisco for over a month, now. My experience has been mostly very interesting, between working at the Wikimedia Foundation and socializing with transplants from Boston. However, my foremost lens for examining any situation has always been digital freedom. With that in mind, I have been paying attention to the general climate of software use in the Bay Area, and I’d like to share it with you now.

I should note that my purpose here is not to criticize any person or group, but to give feedback and maybe better explain the landscape of digital freedom in the Bay Area.

At Work

The Wikimedia Foundation itself, strangely, is not overwhelmingly supportive of free software. The employees tend to run either Mac OS X or Ubuntu on their workstations, and the server infrastructure seems largely based on Ubuntu as well.

The tools being used are largely free, however, with git dominating the source control landscape and Gerrit providing code review and hosting. There is a wide variety of other tools in use, but the people all seem generally in favor of free developer tools. Even a few designers seem to be interested in using free tools, which is a refreshing change from the usual reliance on Adobe.

Of course, the ultimate product of the WMF’s toil is free software, and that’s one of the most important things to consider, but having a general culture of digital freedom would be a huge benefit to the community and the individuals involved!

In the City

Walking around town, I notice a lot of technology. It is my profound displeasure, however, that most of it is branded with Apple logos! Every ride on public transportation is dominated by iPods, iPhones, and the infrequent iPads. I also see Kindles and Nooks, and of course the occasional Nintendo handheld device. I walk around with my brand new Neo Freerunner, but it’s hardly enough to offset the overwhelming feeling of digital restriction….

In Online Communities

I also spend some time chatting with local people online, through sites like Reddit and BAParkour. Those communities, too, appear to be dominated by non-free software. A lot of the technical discussions are dominated by non-free options, and most of the discussions in general seem to be powered by non-free technology.

In Surrounding Businesses

San Francisco is a big place for software businesses, as I’m sure readers will be aware. But a lot of the chatter I hear about local businesses involves work on non-free software. Many of the people involved will be proud of using free software in one capacity or another, but their interest in digital freedom apparently doesn’t extend to their customers.

In Social Circles

The socializing I have done in person has largely revolved around common ties to free software, too. However, that common tie seemed to be rather muted after prolonged conversations, since the people I meet almost always use notorious non-free software (e.g., iOS, Photoshop, Facebook/Twitter), and seem uninterested in changing that fact. While I hesitate to confront these people on the subject (see Freedom: A Struggle, not a Nose Dive), it’s always sort of jolting to realize that the people I met because of free software are not devoted to software freedom.


I think these facts point towards a rather grim situation for digital freedom in the Bay Area. This realization motivates me to seriously consider more devotion to the movement, possibly through more direct means, to help spread freedom in the area.

Why Free Software Is Important

I’ve been an advocate for free software for several years now, and as time goes on, I become more and more insistent on digital freedom. Many have noticed that my insistence is often in the face of practical problems, but I’ve always tried to explain why the practical problems are less important than the deeper philosophical ones. I hope to directly address that issue here today by showing why digital freedom is one of the most important things to consider.

Past Writings

I’ll note briefly that I’ve done something similar in the past. I wrote about practical problems being worth consideration, but I’ve also written about how free software isn’t a religion and how free knowledge can extend to physical things. My article on making money ethically also touches briefly on the importance of free software.

For Users

Users are most frequently the ones to say they have a practical problem with free software. They’ll claim that without non-free software, they can’t watch movies, play games, or create art. Most of the time, those complaints are based on incompatibilities, like when a Flash game is not compatible with Gnash, or based on lack of features, like when the GIMP is missing some advanced graphical feature that is included in Adobe Photoshop. There are practical reasons that those complaints can be mitigated in the free software world, but that’s not the main reason that users should be interested in digital freedom.

Users also often say that the four freedoms aren’t important to them–they claim that the freedom to modify is useless, as are the two distribution freedoms, and that in practice, all software is free to be run in any way. This, too, is not accurate: While a user may not be trained in programming, they may at some time wish to learn about it, which would require the freedom to study. And even if the user has no interest, ever, in programming, they also have the freedom to bring the software to another programmer who can help them fix a problem or add a feature.

However, there’s even more to worry about. Not specific cases, not practical advice, but philosophical reasons. As a software user, when you sign a license agreement, you sign away some rights. When those rights are speech, digital or otherwise, any person should be worried. In the past, governments have made laws to restrict speech. This manifested in restrictions on printing presses, restrictions on the sale of texts, and restrictions on what could be said, even in the most intimate of settings. Today, free speech is under less attack from the government, but more attack from corporations. TV and radio stations are more frequently resistant to controversial speech, and several corporations that create forms of communication will censor that communication based on their own standards of decency. Perhaps most notably, software companies restrict digital speech in the form of their software–that software, or any part thereof, or any modified form of either, cannot be transmitted to anyone else. How can we allow that?

For Developers

I sure hope you didn’t skip the above section, because it was important. Even if you’re only a developer, and not a user, the above section is largely the basis for this one.

To start, however, let’s look at the direct benefits: The developer who licenses their software freely will probably have a more involved user base. This is not a fact, but a likely result of the free software model. This result has been codified in the open source development model, but that model has also somewhat confused the meaning of freedom. Rather than mandating that the source code be open to the world, the free software developer allows their users to share it with anyone they like. That could include “everyone,” but it could also be restricted to a few people, if the right license is used on redistribution. The direct benefit is, any user of the software is also potentially a developer, a mirror, or at the very least, a tester.

Now, since you read the section for users, I can talk about indirect benefits. I have to assume that most programmers aren’t horrible people, so if you are a horrible person, then I can’t really help you. But if you happen to think others deserve to have rights, then the section on users applies to developers as well. As a user is allowed freedom, the developer is benefited by not causing a detrimental effect to others, and so their ethical code is preserved.

Go freely!

Making Money Ethically

Earlier today, the GNU/Linux Action Show had Richard Stallman on to celebrate their 200th episode. For the most part, it seemed like RMS was talking about some complicated issues, and they had a lot of trouble understanding what he meant by a lot of his statements.

However, one thing RMS mentioned that sort of struck my nerve was something that had struck it before. One of the parts of his philosophy is that it is unethical to sell non-free software, and that much I can support. But one of the ways he supports it is to say that programmers don’t need to be paid for their work.


(note: this section was added after the initial publication of the post, at 18:11 on the same day)

I feel I should define, briefly, what “ethical” means in this context. I mean specifically, when I say that something is “ethical”, that it does not violate the freedom of others. Most of the people this post can help will already be very concerned with their own freedom, but they may in one way or another be affecting the freedom of others in a detrimental way.

It may be called into question whether that is a reasonable definition of the word “ethical” in all contexts, but I am not reaching so broadly today, I am only discussing a very small subject.

My Beef

The funny thing is, I’ve gone through college and several jobs in order to train myself to make software. I happen to be similarly committed to free software, and I agree with RMS in that the jobs that produce non-free software should generally be shunned. However, that does not mean that programmers cannot have programming jobs!

I’ve long supported the Free Software movement, and a large part of my support has been explaining the ways that you can make money in an ethical way. So, here I am to explain it again, in a blog post.

Another motive for this blog post is that the hosts of the show specifically asked for a suggestion or two, so I’m here to give them some!

What I Am Not Saying

I want to note that I do not suggest these solutions for programmers working under others. If someone doesn’t have some way to support themselves, as a matter of staying alive, I would suggest that they maintain their current situation until they find a more ethical solution. Continue to lobby the people above you to release free software, but avoid jeopardizing your job.

This advice is leveled at people who make decisions about licensing, which might include some individual programmers who self-publish. Most programmers working under other people will be unable to follow this advice.

Ways to Do It

So, on to advice.

The first business method, touched on somewhat in the show, uses the new concept of crowd-funding to achieve funding. This would basically be an exercise of balancing the community’s interest in the software and the real costs associated with its production. So, if the developers need a few months of rent and food money, then they come up with a reasonable number to represent that amount of effort on their part, and ask for the money. It should be noted that there is no limit on how many projects you can have on a crowdfunding site, nor is there any requirement (unless self-imposed) with respect to delivery date, so you could theoretically set up several proposed projects at once and work on them in any order, depending on whether or not they got funded. So long as the end result was a freely-licensed software package, this would be completely in line with the four freedoms.

Another method that was mentioned in the show was to produce individual custom software packages, licensed under a free license (though probably not copyleft), which would also be extremely ethical. Most companies won’t care about the license, since the software won’t be distributed anyway. This method requires much more active involvement in the local business community, and any company that plays this game must be tied into many connections.

There are also several companies that primarily provide paid support for software that they produce, then release under a free license. The business model here would be somewhat less definite, since you could not give a specific price for the package, and would be counting on the fact that companies would need support. Similarly to the previous model, you would need to fight hard with companies to get them to buy your support, as opposed to passive involvement. In other words, you might not get much business just linking to your support hotline on your main page, you may need to market the software to companies and subsequently sell them a support package on the side.

A final business model, which might not be technically what most programmers want, is the non-profit one. The GNU project has survived in this capacity for over two decades (actually, nearly three), so it’s certainly not an unrealistic model for a software producer. Set up a cool suite of software, ask for donations, and sell t-shirts and mugs with your logo(s) on them! RMS went so far as to sell books and documentation, though a smaller shop might not be able to do that right away.

In Conclusion

Now that I’ve written this, it is a great weight from my shoulders. I can finally just link to it, as opposed to writing long-winded explanations every time.

If you feel I’ve missed a viable option, or have misrepresented something, please use the link below to email me your feedback. I’d love for this to be a comprehenzive resource for someone looking for advice with respect to starting a free software business.

And finally, as always, go freely.

Why We Need the GPL

The GNU General Public License (GPL) has been through three major versions. The first, released in 1989, was mostly concerned with preventing the addition of non-free code to a project in order to circumvent the requirement that modified versions of free software (under a license like the GPL) also be distributed under permissive terms. The second version addressed the problem of dual distributions, requiring that if a person was legally incapable of distributing the source code for GPL’d software under a permissive license, they could not distribute it at all. Finally, the third version addressed the problem of “Tivoization”, by preventing hardware manufacturers from forbidding their users to modify the software on their machines. The third version also added the Affero clause, which (if included) would require anyone offering access to the software over a network to also allow modifications and redistribution freely.

The Problem

These versions have all faced one serious recurring controversy: This license, masquerading as a protector of liberty, appears to restrict the users and developers of the software, too! There are similar licenses, like the LGPL, which allow derivative works without permissive licensing, but the GPL and AGPL both require that derivative works be licensed under the GPL, and often under the same version.

The major gripe is that, while the FSF and the GNU project both preach freedom loudly and clearly, they seem hell-bent, from the text of these licenses, to restrict people from doing what they wish with respect to derivative works. This perception appears to be tearing the free software community apart.

The Explanation

I hope, today, to dispel some of the myths. I don’t dispute the facts, here. There appears to be a severe disconnect between the words and deeds of the FSF. But I think that disconnect is justifiable.

Small side note: in addition to majoring in computer science, I am minoring in government, and I’m using all of my time in the government department studying United States constitutional law. The reasons for that decision are many and varied, but it’s a source of much clarity for me, and on this subject in particular, I have found a very interesting parallel between the actions of the FSF and the words of the Supreme Court.

In a case called Regents of the University of California v. Bakke, a case before the Supreme Court in 1978, there was a lot of discussion about affirmative action in state-run universities. Bakke, the respondent, said that the affirmative action program at UC Davis was detrimental to his ability to receive an education. Justice Powell, in a plurality opinion (later affirmed by an opinion in Grutter), upheld the program on the grounds that racial preferences, while generally abhorrent, were necessary in some cases to remedy past wrongs, and to establish justice once more.

Perhaps I’m overplaying my analogy here, but I think the principles are roughly equivalent. The FSF, whether knowingly or not, has instantiated a legal tool that takes away some of the choice from the developers of derivative works in order to prevent further such deprivals in the future. I’m sure that, in a perfect world, many of the people at the FSF would release their code under a public domain license, or maybe the BSD or MIT licenses, that give almost complete freedom to the users. But they’ve seen a severe societal meltdown with respect to digital freedom. The problem they see cannot be solved by mere goodwill towards man, or the charity of many volunteers. The problem needs a legal solution, as well. To create that solution, they devised the GPL.

Other Implications

I think that the GPL isn’t the only part of the free software movement affected by these principles. I think there are a lot of people who view the free software camp as unmoving, unwilling to accept compromise. I hope that this analogy I’ve set forward will help others to understand that many people have been fighting this war for too long, and suffered too many defeats, to allow themselves to give any quarter. That’s not to say that these people aren’t very understanding and helpful, but they will definitely be antagonistic if asked to give advice contrary to their ideals, and I hope that someone out there can understand that at least a little.

With that said, maybe it’s time for the free software community to start thinking in smaller steps. As I put forward in another blog post, maybe we need to start considering the immense administrative difficulties that face people in their struggle for digital freedom. Maybe encouraging someone to use Firefox, or even Chrome, on a Windows computer, is the best thing we can do for them until they truly understand what may be at stake.

As always, thank you for reading, and go freely.

Free Gaming

Free gaming has long been in a state of inertia. There are many developers who create free games, and those developers are to be commended. But why is it so difficult for free games to win over players? I intend to explore both the importance of free games, and the difficulties they have faced in winning users.


Quite simply, free games are important for exactly the same reasons other free software is important. We see exactly the same manipulation of data, be it personal or some other sort, in games as we do in other software. The biggest difference to my mind is that, while normal software tends to deal with data in a way we can easily see and relate to, games tend to do so in a more subtle and detached way. While we may hesitate to enter our credit card information into a web form, we may not hesitate when presented with an official-looking form inside of a game we have played many times.

I would also posit that free games are even more important for different reasons, namely the importance of creative freedom. With non-free games, the ownership of the world and the characters is firmly established as being with the company that produced the game engine. With free games, while the game engine is very clearly free software, the characters and story would also, likely, be licensed under a permissive license.


However important, it has been immensely clear to free game creators that users are either not interested or not able to play the games. Why is this happening? Why are free gamers nowhere to be found? Are they simply too immersed in whatever games they play to find time for freedom?

First, I think, the largest amount of hype a game gets is around its beginning. In the non-free world, games take that energy and save it, using promo videos and press releases to sustain the user’s interest in the game. This provides them with a loyal, excited fanbase that will, at the end of the cycle, buy the game. In the free software situation, however, the game is often *already released* when the first hype wave hits, however small that wave may be. This means that the excitement over the game is no longer contained, it is set free into the game world, and released. When the game is finally released, it won’t be an event to the players anymore, it will only be an upgrade.

Also, non-free gamers have a perception of games that is unrealistic. Their idea is that the story plays a large part in the entertainment, and that the story should thus be kept a secret, so as to increase the suspense. There are a few different problems with this perception. For one, the story is at least some part of the entertainment, but for every hour spent developing the story, I guarantee that five further hours were spent on making the story possible in the game world. The game engine is just as much a part of the entertainment, if not more. Also, there is an issue with the idea of secrecy. While it may be necessary for the player to remain in the dark in order to entertain themselves, that doesn’t mean a total-media-blackout. Most of the Internet is familiar with “spoiler alerts”, so that source of spoiler is often not relevant. As for the source code itself, I look at that particular situation like a book. If you really feel like skipping to the end, nobody is stopping you. But for those of us who want to read the whole thing, we can restrain ourselves.


Hype is the only standing problem from above, at least the only problem I found to be worth examining.

In the free software world, hype is difficult to maintain. We try to use press releases and blog posts to help, but the largest part of the hype will come from word of mouth. If your community is small, then, you need to keep them energized.

There may be some difficulties in particular cases, where the project owner is not interested in hearing the suggestions of the community, or where some of the community might be less than welcoming to new members. In these situations, it is up to the community to change the situation. Start a fan site, start an IRC where the community rules, and start developing a fork of the project, if necessary.


As with most of my articles, I want to leave you today with some concrete ideas of where to go from here. Since I am speaking mostly to gamers, I will encourage them to check out Minetest, a mining simulator similar to Minecraft; ToME, an RPG with roguelike aspects and a nice interface; and many other small games in your distribution’s repositories.

Thanks for reading, and go freely.

After SOPA: What Now?


Though I’m sure most of my readers will be familiar with the recent events in the United States legislature, I’m going to spend a brief period discussing it. Skip this part?

In the past month or so, the United States Congress introduced and debated a pair of bills called the “Stop Online Piracy Act” (SOPA) and the “Protect Intellectual Property Act” (PIPA).

Though differently named, they had much the same purpose: To leverage legislative power to increase the stretch of copyright law into the barest workings of the Internet. Essentially, the laws provided for methods by which a company or individual who owned the copyright on material that had been infringed upon by an Internet site could contact the proper authorities, and those authorities would immediately shut down that website. They did this by redirecting traffic to that domain name to a different IP address. These provisions alone promised to break the Internet irreparably. But the further outrages were that no due process was carried out, that the supporters of the bill had received a large amount of money from various film and recording industry lobbyists, and finally that even if you had only linked to a site that had infringing material, you could also be shot down.

These two bills, while having many supporters in Congress, engulfed the Internet in protests by users and site administrators alike. Entire websites took down their content for the day. Other sites “redacted” user content for the day. Many sites showed solidarity for weeks by redacting part of their logos. This was a great day in the history of the Internet, and definitely shows that we have become an entity that is capable of defending itself.

Now, on to the aftermath.


So, now we are past these two awful bills, SOPA and PIPA.

Though they were great threats to our digital freedom, and seems to have been defeated, I have to draw everyone’s attention to one very simple fact about SOPA/PIPA: These bills were not isolated incidents, and they aren’t going to be the last. There are threats to our freedom cropping up in ACTA, in various other copyright legislation, and many other non-governmental places.

But these attacks on our freedom need not go unnoticed, nor do we need to let them happen. We have the power to make a huge difference in our own digital lives, and I’m coming back into the online community to try and impress upon all of you how to do it.

Fixing It

First, since we just spent a lot of time trying to undo a pair of bills that threatened our freedom, let’s try and eradicate the cause. The two really big causes, in this case, are the MPAA (the movie industry) and the RIAA (the recording industry). If we want to do anything to fight against these organizations, we need to seriously look for alternatives. Y Combinator and others have been calling people to arms to try and “replace Hollywood”, but I’m pretty sure that those people are already out there. There are hundreds of people making short films in their basements for absolutely no pay. Try browsing for a while, and tell me that there isn’t something there for you. Then check out the Blender Foundation’s collection of animated shorts! I haven’t heard much talk about the RIAA’s part in this fiasco, but their replacement is already around, too: go to Jamendo and find out that there are some really awesome artists that use Creative Commons to protect their listeners. My favorites right now are Brad Sucks, Tenpenny Joke, and Josh Woodward.

Now, I’ve talked about the major proponents of SOPA/PIPA. But there is an irony in the whole situation that no-one seems to be seeing. While this was going on, and big companies were helping with the protest and censoring their own pages, nobody seemed to realize that those same big companies were guilty of much the same wrongs. Google, Tumblr, Minecraft, and TwitPic? None of these companies affords any freedom to their users! Sure, they let you use their products in limited capacity, but are you able to run a local instance of Tumblr? Can you modify Gmail? Can you even post anything you want on TwitPic? And Minecraft, of course, charges you to use the secret code and never truly lets you in to see it.

Basically what I’m saying is, most of the same people who talk big about digital freedom when it comes to SOPA/PIPA are abysmal at preserving those freedoms when it comes to simple freedoms: The freedom to use (in any way you want), the freedom to copy and distribute copies, the freedom to read and modify the source, and the freedom to redistribute modified copies. Those freedoms, in my life, are just as important as the integrity of DNS.

Now, I’ve talked a lot about digital freedom in a lot of different formats, and if I’ve learned anything it’s this: No one wants to make a drastic change, especially not in this particular area. So my advice is this: Check out the links above. Head over to the Free Software Directory and find something cool that replaces a piece of software you’re using. If you read “Minecraft” earlier and were offended, check out Minetest instead. Don’t replace your entire system with Gentoo just yet–that takes a lot of expertise. But maybe it’s time to use Firefox instead of Chrome? Maybe download LibreOffice to finally replace Microsoft Office? Maybe even brave the switch to Clementine to get away from iTunes! Little, tiny steps like this can really make a big difference in the landscape, and certainly in your perception of free software as being inaccessible or difficult to use.

Another great thing you can do to help in the fight for digital freedom is to join the Free Software Foundation. They’re having a membership drive right now, and they could really use the money. They’ll put it towards making cool software, educating people about it, and pushing for adoption of free formats.

And finally, Internet, I implore you to make one more small step towards freedom: Tell your friends. I don’t care if that translates into pageviews for me (no ads here), but I do care that you spread the word. Start a conversation one day about why everyone uses Office. Ask your graphic designer friends if they’ve tried the GIMP or Inkscape recently. Try not to get too into it–I’ve gone down that road, it’s not pretty–but definitely start to ask people you know about their choices, and if they could make better ones going forward.

Thank you, and go freely.