Tag Archives: open source

“I am not a programmer”

· 4 Replies

I am not a programmer.

Spend a few minutes in a place where software users interact with software developers – support forums, dev trackers, face-to-face team meetings – and you’re bound to hear this phrase used (or one of its relatives: I am not [a geek|a developer|a coder|tech-savvy], etc). It’s a statement of fact, and a useful statement at that, since the kind of help offered to a “programmer” is obviously quite different from what’s offered to someone who’s not.

But The Phrase is so much more than that. It’s a strategic move in a social game. Its uses fall into roughly two categories: a cry for empathy, and a deflection of responsibility.

A cry for empathy

I am not a programmer often means Go easy on me. Ask yourself: Why would someone go out of their way to ask for empathy in this way?

Sometimes it’s a way for a n00b to test the waters. Newcomers to a software community don’t always know the community conventions for asking for help. Labeling oneself as “not a programmer” is a gentle way of gauging how others react to new folks.

More frequently, in my experience, I am not a programmer is used by people who have been burned in the past. Maybe the user once asked a question and got an answer that was over her head. Maybe the discussion turned sour when the developers looked down their noses at someone who couldn’t understand a few lines of code. When this happens, I am not a programmer is a shield, a preemptive attempt to guard against the abuse that the asker rightly or wrongly expects to receive.

I wrote a post a while back on how this looks from the developer’s point of view. The gist, so far as this use of The Phrase is concerned, is that developers should be as empathetic as possible in these situations. For one thing, treating people with kindness is just the right thing to do. Beyond that, it’s important to the future of the community to extend a hand to potential contributors.

A deflection of responsibility

The other common use of I am not a programmer is something like: I’m not technical, so don’t even try to get me to crack the hood, which often amounts to I refuse to make an honest attempt. Do it for me.

This phenomenon is, in part, a side effect of the fact that I work with WordPress. WP is unusual among free software projects in that “ease of use” has always been central to its development strategy. The Dashboard, the inline updater, the plugin installer, the five-minute install – all are the result of a conscious effort by WP devs to make the barrier for entry as low as possible. And it’s worked. Without touching so much as a semi-colon of code, you can set up a beautiful and powerful website using WP and the some of the thousands of readily available plugins and themes.

On balance, this is a Very Good Thing. But it also sets up, in the mind of the average user, a certain (incorrect) understanding and set of (unreasonable) expectations about how free software works. In the world of commercial software, the development process is deliberately shrouded from end users. Apple (to take an example) has support forums. But the solutions offered here are always “click here” and “type this”, never “change this code” or “hack this” – if for no other reason than that the software is designed to be un-hack-friendly. In the case of open source software, the source code is available. Thus there is no enforced distinction between those who write the code and those who use it. For users of free software who are accustomed to the proprietary model, it’s hard to get your head around the idea that you can – and should! – be hacking it as part of the troubleshooting process.

Moreover, people who are accustomed to paying for software are used to getting a minimal level of functionality and support in exchange for their license fees. Free software has no license fees. But there persists a sense, in the minds of some users, of “How could you release something that is not 100% working?”. They approach support as a consumer transaction; the idea that troubleshooting could be a collaborative endeavor between users and devs, and that this troubleshooting is part of a larger arc of software development, is totally foreign to them. This seems especially true in the case of WordPress, which is so easy to use that it sets user expectations very high.

It’s perfectly understandable that the move from proprietary to free software would be jarring for users. But it’s not OK for these users to attempt to force their commercial expectations on a non-commercial community. The blurring of the line between user and developer, where users occasionally take a deep breath and crack open the hood, is a crucial part of the way free software is developed. It’s how bugs get fixed, and it’s how new devs emerge from the larger community. I am not a programmer, when it means I refuse to step outside my comfort zone, does active harm to the software project. It’s not that everyone has to become a “programmer” – it’s perfectly fine if you have no desire to get technical. But to deflect the issue altogether – especially with incredulity or anger, as if it’s totally unbelievable that you may be asked to do something technical – is a violation of the free software ethos.

So, next time you see a support request prefaced with “I am not a programmer…”, show a little empathy – but not too much 🙂

The “patronage model” for free software freelancers

· 9 Replies

The problem of the free software freelancer

Many contributors to free software projects fall roughly into one of two categories:

  1. Employees whose employers who have taken a stance to support free software development – like Facebook or Automattic
  2. Hobbyists who contribute in their spare time

In some ways, these two categories represent the extremes of a spectrum: the first group contributes because it’s their job while the latter contributes because they love it. These motivations are by no means mutually exclusive; I’d hope that most people who are paid to work on free software also love to do it. But this short list does describe what I would call the two “pure” drivers of contribution.

Between the two extremes lies a considerable gray area, where the two varieties of motivation – love and money – may coexist in the same person, yet point in different directions. Take me. I am a freelancer, specializing in development and consulting on WordPress and related technologies. On the one hand, I’m an ideological advocate for free software, and I love contributing. On the other hand, the dynamics of the freelancer’s situation often discourage contribution. There are only so many hours in my day, and when the work hours are spent doing client work for WordPress, I hardly want to devote my limited free time to working on WordPress for free. And clients have a bunch of perfectly understandable reasons for not wanting to share the work that they’re paying for: they don’t want to spend more money than necessary to get their site working, they want the competitive edge that may come from secrecy, and so on. The two “pure” motivations for contributing are in conflict with each other.

The patronage model

To combat the conflict, so that I can contribute more, I’ve moved increasingly toward what I think of as a “patronage” model. Broadly, the idea is that clients fund the process of turning the custom-developed features (that they were already going to pay for) into something that can be contributed back to the free software community; in exchange, they get certain benefits, like prestige and publicity. For me, the strategy has come down to a couple of key rules.

  • Learn to preach the free software gospel – People and organizations like to feel that they’re being good citizens. So I’m prepared to explain to potential clients how their particular contributions, and free software stewardship more generally, can provide broader benefit. The nature of the pitch differs depending on the specific client and feature, but there’s almost always a larger story to be told about how the software community would be improved by the contribution in question. It can be useful to explain how the dynamics of free software development differ from proprietary retail software: Propietary software is developed on speculation, where the hope is that the upfront cost will be recovered by huge volume at low prices. In contrast, the vast majority of free software users don’t pay anything, which leaves the Kind And Generous Samaritans to bear the brunt. Don’t be afraid to sound lofty – in cases where the software wouldn’t be built without the patronage, the patron really is doing something wonderful.
  • Stop accepting work from the wrong kinds of clients – In contrast to the foregoing rule, some potential clients don’t care about “being good citizens”, and no amount of clever proselytizing will change their minds. There’s nothing inherently wrong with this attitude: one of the freedoms of free software is the freedom to use it without any moral obligation to “give back”. But, as a developer who does care about the community, I’m not interested in working for this kind of client. So I don’t.
  • Only accept client work that can result in contributions – Most client jobs, at least in web development, are primarily about implementation – taking off-the-shelf software, maybe installing some plugins and customizing a theme. This kind of work generally does not require the kinds of novel development or deep bugfixing that results in meaningful community contributions. There is nothing wrong with this kind of work. But, personally, I don’t find it as inherently interesting as novel development, and it doesn’t make the best use of my limited development time. Thus, I usually only take on a job if it looks like I’ll be able to spin off something truly new.
  • Break down the cost structure – It costs more to build something for broad use than it does to build something for a single client. Every time you have to add a UI for options, or abstract a piece of code for more customizability, it takes time and money. Be honest with the client about how much extra money it will take to turn bespoke code into something distributable. This also means being strategic about itemizing the project scope. When writing a spec for the project, try to separate out those parts that could be turned into something distributable, so that it’ll be easier to provide an honest breakdown. There may also be cases where a client wants to contribute, but doesn’t have a clear idea how to do so – in these cases, don’t be afraid to suggest ways of dividing up the project so as to provide the biggest benefit to the community.
  • Provide the right kinds publicity for the patron – Make it clear to the client the ways in which they’ll receive credit. Some ideas: Include the patron’s name in the name of the plugin. Write a blog post or some tweets thanking them for their patronage. Include the patron as a co-author. Maintain a credits.txt file in your codebase.
  • Include strict licensing and IP clauses in the contract – I include language in all of my contracts to the effect of: All custom development for this project is subject to release under the GPLv2 or another relevant free software license. I do not do work-for-hire type clauses, or other arrangements that involve giving exclusive intellectual property rights to the client, because I want to maintain the right to release the software under a free license. I’ll admit that this stipulation has caused me a good deal of trouble in the last year, but it’s extremely important to me for two reasons. First, I’m an active contributor to the very same free software projects that my clients want to use in their projects. If I develop something proprietary for them, and then (knowingly or unknowingly) I include this proprietary code in something with a free license, I could be held liable for violating the license terms both of the project and of the client. Second, and more germane to the discussion here, every hour I spend doing proprietary development is an hour not spent on free development, and I think that free software is important for a number of critical reasons. So I don’t work with a client who won’t agree that all custom work be releasable (at least in theory) under a free license.

I’ve been freelancing full time for about two years. During that time, I’ve managed to take on a growing number of increasingly large projects. Through the same period, due to the patronage model, I’ve largely maintained – or even increased – the amount of time spent contributing to free software projects (even as my free time has been dominated by marriage and fatherhood!). More money in my pocket, and more free software for community use. Truly a win-win.

Not everyone will have my good fortune to be able to stick to such a strategy. I’m lucky to be offered far more work than I could possibly accept, which means I can turn down the stuff I don’t want, in accordance with the rules listed above. And I’m fortunate to be well known and well respected in my field. But it should be noted that my good fortune is not a coincidence. The more of your time you can devote to public work in free software – whether that work is as a hobbyist or as a patron-sponsored freelancer – the more well known you’ll become in the community, which will result in more job offers and more leverage with potential clients. It’s a virtuous circle that takes some courage to break into, but ends up being beneficial to everyone if you’re successful at it.

Small-scale patronage and the future of free software

Just as important as the benefits that the patronage model has brought to my own career is what it says about the future of free software development. Software like WordPress will never be commercially supported like Windows, where development is funded by the license fees of millions of users. For major development on free software projects, it’ll always be incumbent on a few generous patrons to provide resources. But there are dangers in overcentralized patronage: if, say, Automattic decided to abandon its committment to the WordPress project, a huge percentage of dev resources would suddenly dry up. The contractor-patronage model I’ve described here is a way of increasing the number of patrons, while lowering the financial bar for patronage – organizations can contribute in a meaningful way with just a few thousand dollars. Adopted widely, this promises to be a more secure foundation for ongoing free software development.

I develop free software because of CUNY and Blackboard

· 52 Replies

For two reasons, Blackboard is the key to why I develop free software.

The first reason is historical. I first got into free software development because of my work with the CUNY Academic Commons project. As spearheaded by Matt Gold, George Otte and others, the Commons is intended to create a space, using free software like WordPress and MediaWiki for members of the huge community of the City University of New York to discover each other and work together. The project is not pitched as a Blackboard alternative, for a number of reasons (primary among which is that the Commons’s Terms of Service prohibit undergraduate courses from being held on the site). Still, the Commons was conceived, at least in part, out of frustration about the near lack of collaborative tools and spaces in CUNY. And more than anything else, Blackboard (by which I mean Blackboard Learn, the proprietary learning management software that has been CUNY’s official courseware for quite a few years) is the embodiment of what can be so frustrating about academic technology at CUNY: central management, inflexibility, clunkiness, anti-openness. In this way, Blackboard begat the CUNY Academic Commons, and the CUNY Academic Commons begat Boone the developer.

There is another reason why Blackboard is integral to my free software development. It is ideological.

Short version: I love CUNY and I love public education. Blackboard is a parasite on both. Writing free software is the best way I know to disrupt the awful relationship between companies like Blackboard and vulnerable populations like CUNY undergraduates.

Here’s the longer version. I’ve been affiliated with CUNY in a number of capacities over the last decade: PhD student, adjunct lecturer, graduate fellow, full-time instructional technologist, external contractor. I’ve seen many parts of CUNY from many different points of view. Like so many others who have philandered their way through CUNY’s incestuous HR departments, my experience has rendered a decidedly love/hate attitude toward the institution. You can get a taste of the what CUNY hate looks like by glancing at something like @CUNYfail. The love runs deeper. Those fortunate enough to have “gotten around” at CUNY can attest to the richness of its varied campus cultures. In every office and every department on every campus, you’ll meet people who are innovating and striving to get their work done, in spite of a bureaucracy that sometimes feels designed to thwart.

And the students. CUNY is the City University of New York, the City University. It belongs to New York, and its history is tied up with the ideals of free education for New York’s residents. While the last few decades have seen the institution (as a whole, as well as a collection of campuses) evolve away from these ideals in various official and unofficial ways, it’s impossible to step into a CUNY classroom without getting a sense that CUNY still serves as a steward for New York’s future. CUNY is too huge and its population too varied to make general statements about the student body, but I’ll say anecdotally that, of all the universities I’ve been associated with, none even approach the level of racial, economic, and academic diversity that you find on a single campus, to say nothing of the system as a whole. CUNY is (to use a lame but apt cliché) a cross-section of New York: her first-generation Americans, her first-generation college students, her rich and her poor, her advantaged and her vulnerable. (See also Jim Groom’s I Bleed CUNY, which makes a similar point with a lot less abandon.)

Public education is a public trust, maybe the most important equalizer a state can provide for its citizens. CUNY, with the population of New York City as its public, could demonstrate the full potential of public education in a more complete and visible way than perhaps any other public university. It’s for this reason that it breaks my heart and boils my blood to see CUNY money – which is to say, student tuition and fees – poured into a piece of software like Blackboard.

In virtue of their age, undergraduates are inherently a vulnerable population, and CUNY undergraduates – reflecting as they do the full demographic spectrum of New York City itself – are doubly vulnerable. Many CUNY undergraduates go to CUNY because if they didn’t, they wouldn’t go to college at all. This imposes certain moral strictures on those responsible for managing and spending the money paid by CUNY students in tuition and fees. Wasting CUNY money is a far worse crime than wasting, say, shareholder money in a private company. Shareholders have freedom; if they don’t like your management, they vote with their feet/wallets/brokers. CUNY students, by and large, do not have the same freedom; it’s safe to say that, for most CUNY students most students, big-ticket NYU and Ivy Columbia are not reasonable alternatives. CUNY students are, in this sense, captive, which means that their hard-earned tuition money is captive as well. Thus it is a very bad thing to spend that money on things that aren’t worth it.

And Blackboard is not worth it. Vats of digital ink have been spilled expounding Blackboard’s turdiness, and this is no place to rehash all the arguments in depth. A short list, off the top of my head:

  • The software is expensive [EDIT 9-21-2011: See this post for more details on cost]
  • It’s extremely unpleasant to use.
  • It forces, and reinforces, an entirely teacher-centric pedagogical model.
  • It attempts to do the work of dozens of applications, and as a result does all of them poorly.
  • Blackboard data is stored in proprietary formats, with no easy export features built in, which creates a sort of Hotel California of educational materials
  • The very concept of a “learning management system” may itself be wrongheaded.
  • As recently reported, the software may be insecure, a fact that the company may have willingly ignored.
  • Blackboard’s business practices are monopolistic, litigious, and borgish

In short, Blackboard sucks. Blackboard supporters might claim that some, or even most, of the criticisms leveled above are false, or that they apply equally to other web software. Maybe. And I certainly don’t mean to downplay the difficulty of creating or assembling a suite of software that does well what Blackboard does poorly. But the argument against spending student money on something like Blackboard goes beyond a simple tally of weaknesses and strengths. As Jim Groom and others have argued for years, shelling out for Blackboard means sending money to a big company with no vested interest in the purposes of the institution, which in the case of CUNY is nothing less than the stewardship of New York City’s future, while the alternative is to divert money away from software licenses and into people who will actually support an environment of learning on our campuses. Frankly, even if Blackboard were a perfect piece of software, and even if its licensing and hosting fees were half of what it costs to hire full-time instructional technologists, programmers, and the like to support local instances of free software; even if these things were true, Blackboard would still be the wrong choice, because it perverts the goals of the university by putting tools and corporations before people. The fact that Blackboard is so expensive and so shitty just makes the case against it that much stronger.

As long as our IT departments are dominated by Microsoft-trained technicians and corporate-owned CIOs, perhaps the best way to advance the cause – the cause of justice in the way that student money is spent – is to create viable alternatives to Blackboard and its ilk, alternatives that are free (as in speech) and cheap (as in beer). This, more than anything else, is why I develop free software, the idea that I might play a role in creating the viable alternatives. In the end, it’s not just about Blackboard, of course. The case of Blackboard and CUNY is a particularly problematic example of a broader phenomenon, where vulnerable populations are controlled through proprietary software. Examples abound: Facebook, Apple, Google. (See also my Project Reclaim.) The case of Blackboard and its contracts with public institutions like CUNY is just one instance of these exploitative relationships, but it’s the instance that hits home the most for me, because CUNY is such a part of me, and because the exploitation is, in this case, so severe and so terrible.

On average, I spend about half of my working week doing unpaid work for the free software community. Every once in a while, I get discouraged: by unreasonable feedback, by systematic inertia, by community dramas, by my own limitations as a developer, and so on. In those moments, I think about CUNY, and I think about Blackboard, and I feel the fire burn again. For that, I say to CUNY (which I love) and Blackboard (which I hate): Thanks for making me into a free software developer.

The GPL is for users

· 9 Replies

The General Public License (aka the GPL) is for users. This observation seems so obvious that it needn’t be stated. But for those who develop software licensed under the GPL (like WordPress and most related projects), it’s a fact that should be revisited every now and again, because it has all sorts of ramifications for the work we do.

Users versus developers

What do I mean when I say that the GPL is “about users”? Who are “users”? We might draw a parallel between software and books. Books have readers (hopefully!), and they have authors. Authors read too; proofing is a kind of reading, of course, and one might argue moreover that reading is an inextricable part of writing. Yet when we talk about a book’s “readers” we generally mean to discount its author. ‘Readers’ in this sense is a gloss for ‘just readers’, that is, those readers whose relationship to the book is limited to reading. The situation with software is more complex, but roughly the same distinction can be made between users and developers. ‘Developers’ refers broadly to those people involved in the conceptualization and implementation (and also often the use) of a piece of software, while ‘users’ refers to those who just use it.

My reading of the GPL is that it’s heavily focused on users. (References to the GPL throughout are to GPL 3.0. You can find older versions of the licence, such as version 2 that is shipped with WordPress, on GNU’s website.) Take the opening line from the second paragraph of the Preamble:

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program–to make sure it remains free software for all its users.

Here as elsewhere in the text of the GPL, no real distinction is made between “you” as it refers to developers and “you” as it refers to users. Closer analysis makes it pretty clear, though. Take, for example, the freedoms that are purported to be taken away by proprietary licenses: the freedom to “share and change” software. Developers – or, to be more specific, license holders, who are generally either the developers themselves or, in the case of work for hire, the people who paid for the software to be developed – generally do not restrict their own rights to share and change the software that they create. Instead, restrictions are imposed on others, the (“just”) users.

Similar reasoning applies to the core freedoms that are outlined in the Free Software Definition, a sort of unofficial sister document of the GPL, also maintained by the Free Software Foundation. The four freedoms:

  • The freedom to run the program, for any purpose (freedom 0).
  • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help your neighbor (freedom 2).
  • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

On the face of it, freedoms 1 and possibly 3 are focused on developers, in the sense of “those who are able to write code”. But, with respect to a piece of software that they did not write and whose license they do not control, coders are just regular users (in the same way that Vonnegut may have been a “reader” of Twain). All four freedoms, indeed, are user-centric. The license holder, almost by definition, doesn’t need permission to use the code (0); the developer doesn’t need to study the code to know how it works (1); owners can redistribute at will (2); owners can modify and redistribute at will (3). It’s only in the context of users – those who did not write the software – that these freedoms need protection in the form of free software licenses like the GPL.

The GPL does make a few explicit provisions for the developer/license holder:

For the developers’ and authors’ protection, the GPL clearly explains that there is no warranty for this free software. For both users’ and authors’ sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.

The second provision is a sort of legal convenience; the first intends to ease what may otherwise be a prohibitive consequence of the core freedoms guaranteed by the rest of the GPL. Both are important and valuable. But it seems fair to say that they are secondary to the user-focused parts of the document, at the very least because they are motivated by other parts of the document, while user freedom needs independent justification.

There’s no question that the people who bear the brunt of implementing and upholding the GPL are software developers. In that sense, the GPL is very much “for” them. But, in a broader sense, that’s a bit like saying that school is “for” the teachers because the teachers play a key role in education. Schools are for children; they provide the motivation and justification for the whole enterprise. Similarly, the GPL is for users; if everyone wrote their own software, and there were no “just users”, the GPL (or any free software licenses, or any licenses at all) would be unnecessary.

Sacrifice

If I buy a pizza, I trade ownership of money for ownership of pizza. Once I have the pie, I can do pretty much whatever I want with it. I can eat the whole thing myself, I can share with a friend or two, I can throw it on the sidewalk. I can save the pizza in hopes that prices rise so that I can make a quick buck in a resale, I can retail off the individual slices, or I can give the whole thing away. I can’t use the pizza to solve world hunger (not because I’m not allowed, but because it’s not possible); I can’t use the pizza as a deadly weapon (not because it’s impossible, but because I’m not allowed). In short, ownership bestows certain rights. Not all rights – I don’t have the right to murder with the pizza, or to do impossible things with it – but many, even most of them.

The situation is more complex with intangible goods; especially those, like software, which can be reproduced without cost or loss. Copyright law in the United States (so far as I understand it; IANAL etc), in accordance with the Berne Convention, grants rights over intellectual and creative works to the authors automatically, at the time of creation. Thus, if I write a piece of software (from scratch – set aside issues of derivative work for a moment), I am granted extensive rights over the use and reuse of that piece of software, automatically, in virtue of being the author. That includes copyright – literally, the rights related to the copying and distribution of the software. In short, the default situation, for better or for worse, is for the developer – and only the developer – to possess the rights and freedoms enumerated by the Free Software Definition. By default, nothing is protected for the users.

Free software licenses exist in order to counteract this default scenario. But keep in mind what that means: When a developer releases a work under a license like the GPL, certain freedoms and rights are granted to users, which necessarily restricts the freedoms of the developer. The GPL admits as much:

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

“Responsibilities” is a nice way of putting what is essentially the stripping of certain rights (in the same way that, once you become a parent and thus responsible for your child’s well-being, you no longer have the right to go on a week-long bender). Once the software is released under a GPL, the original author has lost the right of exclusive distribution of the original software. Subsequent developers, those who modify and redistribute the software, are similarly restricted.

It’s a trade-off. Users get certain rights (viewing source code, copying, modifying, redistributing) because the developers have given up the default right of exclusivity. Examined in itself (without reference to subsidiary benefits for the moment), the trade-off is clearly made for the benefit of the users, and involves sacrifice on behalf of the developer, sacrifice which is usually quantified in monetary terms (Bill Gates didn’t get rich by writing open source software), but could also be associated with pride in being the sole author, etc. There are, in addition to this, secondary sacrifices involved in free software development (loss of identification with the software because of modifications or forking, less guaranteed income than in a proprietary development shop, increased support requests that come from wider use of a free-as-in-beer product [though the GPL explictly says that you can charge what you want, and that no warranty is implied]). To some extent, these secondary sacrifices can be mitigated by the realities of the market, and are anyway subject to the particulars of the scenario in which you find yourself. But the core sacrifice – giving up exclusivity over distribution – cannot be separated from free software licenses.

Software licenses are political documents

Developers have all sorts of reasons for releasing software under free software licenses like the GPL. A few, off the top of my head:

  • You want to modify and redistribute existing software that is GPLed
  • You want to distribute somewhere that requires GPL-compatibility, like the wordpress.org plugin repository
  • You believe that forkability and other GPLy goodness makes for a better product
  • You want to develop for a platform, or contribute to a project, that requires GPL compatibility

I classify these reasons as prudential, in the sense that they are focused on the material benefits (money, fame, better software) that you believe will come from developing under the GPL. All of these reasons are great and important, and many of them have motivated my own work with GPL-licensed software. Taken together or even individually, it’s easy to imagine that these (and other) benefits would outweigh the sacrifice involved in giving up exclusive distribution rights over your work.

There’s another kind of justification for releasing under the GPL: you endorse, and want to advance, the political and moral ends that motived the creation of the GPL. The GPL assumes that it’s a good thing for users to have maximal freedom over their software:

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

The assumption here is that “greatest possible use to the public”, and by the extension the good of the public, is something to be actively pursued – a moral claim par excellence.

And, among free software licenses, the GPL is perhaps the most explicit about the ways in which user freedoms (and thus the greatest good of the public) should be guaranteed and propagated. The “viral” nature of the GPL constitutes a kind of normative statement about the value of user rights over developer rights, which goes beyond other free software licenses that do not share its viral nature. The difference might be summed up like this. Alice and Bob are coders, and Carol is a potential user of the software. If Alice writes a piece of software and licenses it under a free software license like those in the BSD tradition, Bob can fork the software, make a few changes, and sell it to Carol under any terms he’d like – he can compile a binary executable for distribution, without making the source code available, converting his fork into closed-source, proprietary software. If Alice licenses the software under the GPL, on the other hand, Bob can still modify and sell to Carol, but he may not change the terms of the original license – in particular, the source code must be made available for further modification and distribution.

The normative aspect of the difference is in the value that each license scheme ascribes to the rights and freedoms of various individuals involved. BSD is more permissive with respect to Bob; GPL limits his ability to license the derivitive work as he pleases. GPL is more focused on Carol, and protecting her – and other “just users” like her – at the cost of some of Bob’s freedoms. (The GPL is for users.) One might express the difference in political terms thus: the GPL is more liberal, and less libertarian, than the BSD. Users, who are on the weak end of the power spectrum when it comes to software, are protected under the GPL, in the same way that society’s underprivileged and weak are often the focus of political liberalism. On this picture, licenses, like laws more generally, are designed in part to create the restrictions necessary to protect the positive freedoms of a vulnerable population.

For developers who agree independently with the normative principles underlying the GPL, its moral benefits can outweigh the sacrifices it entails. Such a justification is the starting point for Stallman and the Free Software Foundation (see, for example, the FSF’s about page). You may, of course, foreground other aspects of free/open-source software when justifying your licensing. I’ve listed some justifications above, and entire movements have sprouted to focus on prudential, rather than moral, justifications for open source development.

But – and here’s the rub – licensing your work under the GPL constitutes an endorsement of its moral justifications, even if it’s not (from a cognitive point of view) what motivated you personally to apply the license. If you choose a free software license for prudential reasons, you are not justified in complaining when your project is forked. If you choose the GPL for prudential reasons, you can’t altogether disavow the inherently altruistic underpinnings reflected in the license’s preamble. Put another way: Among other things, software licenses are political documents, and it’s incumbent upon developers to understand them before adopting them.

It’s important for developers to think carefully about this before diving into a license. My own take is that the original motivation for free software – that user control over the software they use is fundamental to their autonomy – becomes truer every day, as more and more of our agency is mediated through software. For that reason, licenses like the GPL are ethically important, at least if your worldview depends (as mine does) on respecting the agency of other human beings.

This post was prompted by a recent post by Ipstenu. Much of my thinking on the matter is clarified and inspired by the first few chapters of Decoding Liberation: The Promise of Free and Open Source Software, a book about free software written by philosophers/computer scientists Samir Chopra and Scott Dexter. You can (and should) buy the book here.

Project Reclaim

· 40 Replies

Update: I have begun aggregating these posts at projectreclaim.net.

Lately I have been feeling increasingly uneasy about the state of my digital affairs. I am a leader on a number of open source software projects that pride themselves on, among other things, their ability to enable users to “own their own data”. Moreover, I am trained as a philosopher, and have spent a pretty fair amount of time reading and thinking carefully about the nature of data and our relationships with it. If anyone is in a position to develop and advocate for good models of digital independence, I am.

Yet, when I look around my digital world, I see instance after instance where I am, to a greater or lesser extent, completely reliant on the good will of commercial entities and their propietary systems. To wit:

  • My Twitter account is a big part of my online identity
  • The last five years of my private correspondence, personal and professional, is in Gmail
  • I use Dropbox for syncing documents between devices (like my blog_sandbox.txt file, where I’m writing this post!)
  • I use Picasa Web Albums to back up and share photos
  • I have a Mozy account to back up the rest of my important files
  • Until recently, I had an iPhone. I still use a Mac
  • I use Remember The Milk for task management
  • I store source code for all my projects in Github

Some of these are products; some are services. Some are free; some of them I pay for. And – for sure – some of the companies behind the products and services listed above are more evil than others. So I don’t want to pretend that my reliance on each of them is equally bad. But each item on this list plays a crucial role in my digital life, and each one of them operates in a way that is beyond my control, both literally (I can’t modify the source code) and more figuratively (questions about ownership, exportability, transportability are icky).

I’m planning to extricate myself.

Project Reclaim

In order to make it sound a bit fancier, I’m giving my project a name: Project Reclaim. ‘Reclaim’ because it’s a manifestation of my desire to fight the inertia that leads us to give up control over our computing experiences, my desire to reclaim control and ownership. ‘Project’ because this will be hard, and ongoing. And why give it a name at all? I’m hoping that, by being public about it – putting my experiences in a series of blog posts and tweets under a common tag – that I’ll be able to hold myself accountable, and hopefully guide others who are hoping to reclaim their lives a bit as well.

In short, Project Reclaim is the process of weaning oneself off of digital platforms that are closed source and/or under the control of others.

Methodology

How will Project Reclaim actually work?

  1. Assess the situation I’ll first need a way of figuring out which systems and platforms are worth moving away from, what their replacements should be, and in what order I should effect the transition. I’ve got a few rules of thumb.
    • Open source is better than closed source. I write open-source software for a living. I believe that, on balance, it makes better software. And I believe that using software where one has access to the source code is a necessary component of maximizing one’s digital autonomy. Thus: if the third-party system I’m currently using is also a benefactor of open-source communities (like, say, wordpress.com), it makes it less urgent to move away. And, when selecting replacements, select open source if at all possible.
    • Paying is better than getting something for free This might seem like a contrast to the previous rule, but I don’t think it is. When you use a free service, somebody’s paying the bills. Usually that means targeted advertising – think Facebook and Gmail. Paying service fees, on the other hand, and agreeing to the contract that comes with it, generally has the effect of making the relationship more transparent. Of course, this is far from absolute, but it seems reasonable in a broad sense. Plus, I like to support developers and services that are truly valuable.
    • Go for the low-hanging fruit In cases like email, there are well-established, straightforward (though not necessarily easy…ugh) ways of fending for yourself. No need to invent the wheel. On the other hand, some of the areas where alternatives are less obvious – social networking-type data springs to mind – also happen to be areas where I have some expertise and leverage. So, in those cases, it might be worth innovating.
    • Get the important stuff first My email history is more important to me than my Twitter history; the convenience of Github is more valuable to me than the convenience of Dropbox. Plan the Reclaim accordingly.
    • Get the vulnerable stuff first Recent statements by Twitter have made me think that the way I interact with the services is more subject to change in the upcoming months than, say, the way I interact with Gmail. That’s frightening. The more profit-hungry the company is – and, thus, the more disinclined to have the customer’s freedoms in mind – the more urgent it is to pull yourself out.

    Clearly, some of these considerations are at odds with each other. But they give a rough framework for deciding whether, when, and how to carry out the mission of Project Reclaim.

  2. Make the switch Here’s where the action happens: I do what I need to do to move myself to the replacement.
  3. Write about it This weekend I spent an afternoon on the problem of Twitter, and I ran into a ton of technical problems that remain unresolved. I imagine that there will be similar hurdles for each part of the project. I’m hoping that, by writing about the problems (and, where they exist, the solutions) I can help other people to take some of the same steps themselves, or even to spur someone really smart to come up with better solutions than the ones that currently exist.

What I expect from myself

My goal, ultimately, is to move away from third-party, closed-source services and platforms altogether. It might take some time. So I’ll make some interim goals: by the end of 2011, I’m hoping to have my email moved, my microblogging federated, my own backup system on my own server space, and my computer running an open-source OS.

Even if I manage to meet this goal, there’s a very real sense in which Project Reclaim will necessarily be an exercise in futility. I’ll always have to buy server space, and who’s to say that Amazon or Slicehost won’t go berserk tomorrow? I’ll always have to connect to the internet, which leaves me perpetually at the mercy of the ISPs, who are IMO more evil than all of the other service providers put together. It’s a depressing state of affairs: the kind of autonomy I want might be impossible given the way that the economy works. I take some solace in the fact that philosophers have spilled much ink over the problem of free will without coming up with a clear formulation of exactly what kind of autonomy would be worth arguing for. At least I’m not alone in my delusion.

That said, it’s a fight that I feel I have a responsibility to fight. If I’m going to continue to argue for the use and development of open source software, I have to start putting my money where my mouth is. And so, to me, Project Reclaim is less about my being a paragon of virtue, and more about my wanting to sleep a bit better at night.

Do I think that everyone should do this? People should prefer open solutions to closed ones, all things being equal. But generally, all things are not equal. Most people don’t have the time to write their own software, to run their own servers. For those people, decisions about their digital life are (rightly, I think) made more on the basis of aesthetics and convenience than lofty concepts like Autonomy and Ownership. But there are a few considerations that are perhaps relevant for the kinds of people who read my blog:

  • Open source developers who tout the importance of data ownership and other such freedoms have a special responsibility to model best behavior in these areas.
  • Academics, more than anyone, should be sensitive to the dangers of leaving the crucial pieces of one’s online self in the hands of corporate entities. That’s true for personal artifacts like email, but perhaps doubly so for scholarly work that ought to be part of a public trust.
  • Educators, like open source developers, should model best practices, encouraging students to take control over their digital identities.

So, while I wouldn’t belabor the point for the average Joe, I do think that people who consider themselves members of one of these groups – as most people reading my blog probably do – that they should think carefully about their relationship with the tools and services that enable their digital existence.

To freedom!

Empowering through openness – my application for the OpenEd 2009 travel scholarship

· 3 Replies

This blog post is my application for one of the travel scholarships to OpenEd 2009. Here’s how the prompt goes:

  1. What you would “bring” to the conference? What can you contribute, be it a willingness to volunteer to moderate a session, some special expertise or project, an already accepted proposal…
  2. What you see as the most critical issue facing you in your efforts around Open Education, and how you think the conference can help you address it?

I approach the subject of Open Education from two different angles. The first angle is a humanist one. I’m trained as an academic: I’m doing my doctoral studies in philosophy at the CUNY Graduate Center. This academic training fuels an interest in education, and especially the way that education might (or must) move toward openness as time passes. The second angle is a technical one. I’m (in the process of becoming) a coder and developer of web applications. Working primarily with open source applications like Wordpress, Mediawiki and Drupal, I’m developing an increasing sense of the user-empowering potential of open source software. These two angles on openness converge in my career in various ways, both in my day job as an instructional technologist at Queens College and as a developer for the CUNY Academic Commons.

As such, I think I could bring to OpenEd 2009 an interesting perspective on the nature of openness. As a user of – and contributor to – open source products, I can speak confidently to the community benefits that emerge when powerful tools are developed in an open way. And, more specifically, as someone who has used these tools toward both educational purposes (for example, in support of blogging initiatives both in my classes and in the classes of others) as well as in more broadly scholarly contexts (like the community of collaborative research that the CUNY Academic Commons is designed to foster), I have a concrete sense of the way in which openness in one realm – the realm of software – can foster and feed another kind of openness in the educational realm.

In service of these (somewhat abstract!) goals, I’m willing to participate in as many concrete ways as possible at the conference. I’m an active and energetic Twitter backchannel user (see, for example, the Twitter conversations I took part in at this year’s THATCamp, as well as my previous musings on the role of Twitter at conferences). In discussions both on and off Twitter, I can offer up experience both theoretical (I am a philosopher, after all) and practical (I’m also a geek). I’d also be happy to moderate a panel, if I were asked to do so.

As for what the conference will do for me, I envision that my attendance at OpenEd 2009 would help me to further bridge the gap between the practical and the technical that characterizes so many of the things I do in my career. As an instructional technologist, I think it can be easy to think of yourself as a purveyor and teacher of tools, tools that merely replicate the kinds of learning that have always happened in classrooms. This, after all, is often the path of least resistance. The challenge, I believe, is empower faculty members (and, ultimately, the students themselves) not only to use technology but to understand the extent to which it shapes the world and, by extension, ourselves; only by appreciating this can an individual engage with the technology in such a way that it expands (rather than controls) his or her humanity. Openness is the linchpin: students cannot make the connection between what happens in a class and what happens in the rest of their lives unless the window between the two is open. So I guess my goal is to see what kinds of practical approaches are being taken by people in positions similar to mine, in order to help faculty and students understand how they can empower themselves by embracing openness.