Tag Archives: free software

GPL and free software language for government contracts

This weekend at BuddyCamp Miami (which ruled btw) I chatted with a number of folks about putting GPL clauses into client contracts. It can be especially challenging when working with universities or other bureaucracies that have hardcore, work-for-hire-ish intellectual property clauses already built into their consultant contract boilerplate. On a number of occasions, my clients and I have worked with the legal departments at universities to develop new language that fits the spirit and law of GPL software. In my opinion, this kind of work is among the most important work I’ve done since I started in this business, even more important than most of the software I’ve written. By having the discussions with legal, and by getting free-software-friendly boilerplate on their books, we take steps toward legitimatizing free software in the university, and making it part of the culture.

Anyway, I was asked privately to share some of this contract language, and I figured it would be more useful to do it in a blog post than in an email. So here are a few examples that have been approved by the legal departments at large universities. (Side note: We should come up with a system for sharing these kinds of strategy docs in a more organized way.)

  1. This clause replaced one university’s extremely restrictive IP boilerplate:

    Foundation acknowledges and agrees that enhancements, bug fixes and other custom developments produced under the scope of this agreement will be subject to release under the GNU Public License v2, or another compatible and relevant open-source license.

  2. The following clause is added as a footnote to the existing language about IP:

    Section VIII (1-3) shall not apply when work is being performed in the public domain. Consultant agrees to comply with the GNU General Public License version 2, as set out in the Attachment #2, when work is being performed in the public domain.

    A few notes about the language in this second example (which their lawyers wrote, not me). First, “Attachment #2″ is a copy of the GPLv2. Second, I think there is a little bit of confusion here about “public domain”, because strictly speaking, “public domain” means that no one owns the copyright, while the GPL is dependent on copyright. I think the spirit of the phrase “performed in the public domain” is supposed to be something like “written for public consumption”. But a literal reading of this clause probably means that I must relinquish copyright over the work done under this contract into the public domain. In this specific case, the end goal is for me to extend one of my existing GPL-licensed WordPress plugins; so I will then be integrating this newly-created public-domain code into the plugin, and then distributing the whole thing under the GPL, with a note that the newly added library is in the public domain. This is not ideal, but it’s OK for this case where I’m building a standalone add-on for my own work – good enough not to continue negotiations :)

If I can dig up others, I’ll post them here. If you have real-life examples, please share in the comments.

Doom and gloom upon the offing of Google Reader

This week, Google announced that it’s shutting down Reader. This is the first of Google’s “sunsets” that hits me personally – Reader has been a crucial part of my internet use for the better part of a decade. I happen to think, like Marco Arment, that in the long run the loss of Google Reader will probably be good for innovation in RSS readers and for RSS in general. Google’s hamstrung app has been just good enough for people like me, but non-approachable for non-geeks. A year from now, I’m hoping that there’ll be many more quality players. So, in the long run, I’m reasonably optimistic.

More immediately, though, a couple of causes for concern:

  1. Finding an alternative to Reader. My RSS reading habits are too ingrained for me to abandon them, even for a short time. More than that: following RSS feeds is beyond mere habit, but is check on my intellectual honesty. I follow many blogs whose authors I frequently disagree with, or even dislike. (Contrast this with Twitter, where I’m pretty fickle about whom I follow, and how many tweets/links I pay attention to.) So RSS is, for me, a partial antidote to the echo chamber tendency. That means that I’ve got to find a new app, and migrate over, and I’ve got to do it quickly.

    There have been a number of posts over the last couple days listing Reader alternatives. A number of them are cloud/service based, and for practical reasons (such as, um, Google Reader) as well as philosophical reasons (see below), I’m only considering alternative tools that I can run either locally or on my own server. A couple that spring to mind:

    • Fever. I’m interested in this one because (a) the screenshots make it look nice, and (b) it comes highly recommended by people I respect, like D’Arcy Norman. I like that it’s self-hosted. I don’t like the fact that its sustainability model is to charge for downloads. It’s not that I don’t think the author shouldn’t be paid – I would be happy to pay $30 or $300 for a great RSS reader app. It’s that the success of the single-developer model is contingent on the willingness of that developer to keep working on the project (paid or otherwise). I’m far more comfortable with software that is community developed under a free license, ideally using a set of technologies that would allow me to modify or even adopt the project if the main devs were to abandon it.
    • Tiny Tiny RSS. tt-rss also comes recommended by someone I respect (Mika Epstein, in this case). And it’s community-developed, which I like. It doesn’t look as pretty as Fever, but aesthetics are about fourth or fifth on my list of requirements.
    • PressForward. As Aram describes, the PF team (of which I’m pleased to be a member) is working on a WordPress-based tool that, among other things, does RSS aggregation and provides some feed-reading capabilities. PressForward is really designed for a different kind of use case – where groups of editors work together to pare down large amounts of feed data into smaller publications – but it could be finagled to be a simple feed reader. Mobile support is a particular pain point, as 50% or more of my RSS intake is done on my phone, and PF has nothing in place to make this possible at the present time. So, PressForward may not be quite ready for primetime, but I do think that it has promise.
  2. Get the hell off of Google. We all know that Google is a company with shareholders and profit goals to meet. Yet we often act like Google is some sort of ambient benevolent force on the web. Since I started Project Reclaim, I’ve been working on extricating myself and my data from the clutches of Google (among other corporate entities). Reader’s demise is a wake-up call that the time for dilly-dallying is over.

    For my own part, I still use a few Google services besides Reader:

    • Gmail. I don’t use Gmail primarily anymore, though many people do still email me at my gmail.com address, so obviously I have it open and I check it frequently.
    • Picasa. I use the Picasa desktop app on OSX to export photos from my cameras and organize/tag them. I also use Picasa Web Albums as one of my many photo backup services. (Seriously – I back up my photos to no fewer than six different local and cloud services. Nothing is more important or irreplaceable than my family photos.)
    • Drive/Docs. Aside from the occasional one-off collaborations, I use Drive to maintain a number of spreadsheets and other documents that I share with members of my family, etc.
    • Calendar. I’m not a heavy calendar user, but when I do use a calendar, I like Google because of its integration with my Android phone.
    • Chromium. Not Chrome, but still largely Google-reliant, Chromium is not my main browser, but I use it daily for doing various sorts of development testing.
    • Android. This is maybe the one that steams me the most, because at the moment there are no truly free alternatives. (Firefox OS, please hurry up.)

    In some of these cases, there are easy ways to get off of the Google services. In others, it’ll be a challenge to find alternatives that provide the same functionality. In any case, the Reader slaughter is a harsh reminder that Project Reclaim has stagnated too long with respect to Google services.

    More than myself, I’m worried about others – those who aren’t as technically inclined as I am, or those who simply don’t care as much as I do. Google’s made it pretty clear (as is their right, I guess) that they’re not an ambient benevolence. Those who rely on Google then, especially for critical services like email, should take this warning very seriously. Please consider carefully what you’re doing when you make yourself wholly dependent on the whim’s of Google’s product managers, and consider options that are either free-as-in-speech, or services that you pay for in a traditional way.

Commons In A Box, ready to unbox

It’s been a long time coming, but it’s here: Commons In A Box. Today we’re releasing version 1.0-beta1, the first public release. For some background on Commons In A Box, here’s today’s press release, my Commons Dev Blog post explaining some of the features of Commons In A Box, and the 2011 press release announcing the project.

The primary goal of Commons In A Box, in my view, is to reduce the barrier of entry to setting up BuddyPress community sites. BuddyPress is an extremely powerful and flexible platform for developing social WordPress sites, but getting a BP site right takes knowledge (which plugins are worth installing, which ones work best together, etc) and elbow-grease (customizing your theme, keeping a complex system up to date). These practical requirements have made BuddyPress seem imposing to many users – including, and perhaps especially, the users that need free community software the most, such as educational institutions. Commons In A Box lowers these barriers in a serious way, by helping with plugin selection and installation, and by providing a beautiful and flexible default theme. My hope is that Commons In A Box will serve as a gateway for a swath of potential users into the world of BuddyPress, WordPress, and free software more generally.

The process of pitching, planning, and producing Commons In A Box has been interesting, frustrating, and rewarding. In the upcoming weeks and months, I may write more about this process, and what I’ll personally take away from it. In the meantime, I’ll say that I’m very pleased to be ending this first stage of development, and pushing it into the wild, since software – even imperfect software – is infinitely more valuable when it’s out there, being used, than when it’s mouldering on a developer’s machine. Shipping FTW!

Learn more about Commons In A Box.

Three talks in Vancouver

For those Bo(o)neheads who follow me to every event in VW vans, I’ll be giving three talks in Vancouver next month:

  1. BuddyPress: Beyond Facebook Clones, Oct 13, WordCamp Vancouver. I’ll highlight some uses of BP that are not straightforward social networks. (BTW, if you know of any really cool ones, please let me know in the comments!)
  2. Free Software and the University: The Story of the CUNY Academic Commons, Oct 14, BuddyCamp Vancouver. I’ll be using the story of the Commons as an excuse to rant about an allegory about the importance of free software in public schools.
  3. Getting Started with BuddyPress Plugins, Oct 14, BuddyCamp Vancouver. I’ll be giving an overview of what WordPress plugin developers need to know about getting their feet wet with BP plugins.

“I am not a programmer”

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

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.

Sowing the seeds

Today I devoted an unusually large amount of time doing free user support for BuddyPress and WordPress (in IRC, over email, through some Trac tickets, and on WordPress StackExchange, the latter of which I’ve been experimenting with for the first time, and I find pretty cool). I say “unusually large” because while I used to do a lot of this sort of thing, it now falls to the bottom of my list of priorities – I do paid work, and when I’m not doing that I do free software development, and when I’m not doing that I try to get the hell away from my computer. As one of the leaders of the BuddyPress project, I usually justify this balance to myself by saying: There are lots of people who can provide user support for this software as well as I can, but there are few who can do productive development for it like I can, so my time is better spent developing. Generally, I think this is a pretty good argument. But I’m glad that days like today come along occasionally, because they remind me of some basic things about the nature of the community around a piece of free software that you can forget when your head is buried too deep in the codebase.

As an aside, I should note that I use the word ‘community’ in a measured way. The word is often overapplied, as if calling a bunch of people working on similar things “the WordPress community” or “the Digital Humanities community” or “the CUNY community” will, in a feat of performative metamorphosis (like how the Queen’s saying “I dub thee Sir Boone” would ipso facto make me a knight), bring into being the thing it purports to describe. Terminological misgivings to one side, there is an undeniable sense in which the work that we do – and by “we” here I mean specifically free software developers, though the point is quite a bit more general than that – is done in a community, or at least (more formally) a network, insofar as those who work on a common piece of free software never really work in isolation from one another. The development process that underlies these software projects depends on the existence of feedback loops, from the end user to the administrator of the installation to the community leaders to the developers themselves, in the form of bug reports, software patches, feature suggestions, support requests, blog posts, and so on.

These feedback loops are not unique to free software development; they’re not even unique to software. But in free software circles the loops are perhaps uniquely malleable, and the distinctions between user and developer uniquely permeable. Each user is a potential contributor, be it through code or advocacy. But the potential is not realized automatically. It’s obvious enough that users who hate using the software and developers whose patches are ignored will never become part of the community. More interesting is the case where a newbie approaches the community with enthusiasm and skill, but where their offerings are not nurtured and so never become real contributions.

I think this happens more than we would care to admit, and I am happy to take my share of the blame. As a developer, I become emotionally attached to the project, and as a result I sometimes interpret criticism as a personal attack. The parts of development that are least exciting – hunting down and fixing the obscure bugs that affect only a small number of users but, for those users, are ruinous – these make me defensive and sometimes angry, as they take my attention away from the more generative work I’d rather be doing. I value my time so highly that I occasionally get annoyed when someone requests some of that time to answer a “simple” question. In each instance, my attitude as a developer and leader of the project could have the effect of chilling what might otherwise have been a fruitful engagement.

Taking the time to do some “support” is the ideal way to fight these tendencies. People ask questions about the software, contribute patches, suggest improvements, etc, because they like the software and want to use it. These people are friends of the project, and should not be treated as enemies. Taking the time to work directly with users is a way of closing the feedback circuit, of sowing the seeds of future collaboration and contribution. If one out of five people recommends the software to someone else, and one out of a hundred contributes back to the software in the form of documentation or code or advocacy, that’s fruitful enough to make the engagement worthwhile.

2011

A bunch of stuff happened in 2011.

Like 2010, 2011 was a year of transitions for me: in my relationship with academia, in the way I earn a living, in the way I present myself as a citizen-builder of the internet. Being a parent is the biggest transition of all, forcing me to put into perspective the ways I spend my energy and the ways in which I define myself and what has value to me. (This transition has been overwhelmingly a Good Thing.) Continuing to strive for the right balance in these areas will, I’m sure, be a hallmark of my 2012. (Thankfully, I have no plans to have a child or get married in 2012. A man needs a year off from major life events!)

Happy new year!

Done with Apple

In my 2010 year-in-review post I made a passing mention to my decision not to buy any more Apple products. Most people who know me can probably guess the reasons behind the decision, but recently I’ve had some discussions that made me think that it’s worth a blog post to spell them out.

First is my ongoing project to move away from proprietary software in general. All things being equal, it’s better to use software whose source code I can view and modify; even if, in fact, I never do these things, the fact that I could is a kind of safeguard against a number of frequent aspects of closed-source software: data lock-in, data rot, restrictions on hardware compatibility, secret surveillance, etc. As the operating system is in many ways the foundation of all other tasks I do on a computer, so it is of fundamental importance to use an open OS.

Second. I believe in the Web as an open platform for communication and expression, and Apple is increasingly anti-web.

You often hear hoopla about how digital technologies can radically democratize and transform x (fill in your favorite x: scholarship, education, publication, politics, etc). The success or failure of these transformations is tied up with the Web’s openness as a platform: open standards like TCP/IP, enablers of decentralization like distributed DNS, free software like Linux and Apache to run servers. Putting any of these technical details under the control of a single agent, especially a corporate agent that answers only to shareholders, threatens to limit free expression and disenfranchise vulnerable groups of potential users. If a robust, widely-used, open Web is important to the future of equality and democracy, and if such a Web can only be defended by keeping out proprietary interests, then it’s important to fight against interference from those interests.

I take it as fairly obvious that Apple (and not only Apple, though they seem to be the trendsetters) is anti-Web. Consider their distribution models. iTunes makes it so that you have to buy apps, music, and movies through an application, rather than through web pages. Know that annoying “feature” where, when you click on an iPhone app link on the web, you get a page informing you that you’ve clicked on an iTunes link, whereupon iTunes proceeds to open? That’s anti-web. The increasing focus on “apps” is a more troubling anti-web move. As was nicely illustrated by an article I read a while back (can’t find the link), you can spend a whole day doing stuff on an iPad – using Twitter, Facebook, WordPress, Yelp, email, Google Maps, etc – without ever viewing a web page (though they all use web services that use HTTP as a transport). In this way, Apple is doing an end run around the web.

The nature of the end run is particularly troubling. Apple is the arbiter of the software that runs on its devices (completely, in the case of iThings; increasingly, in the case of the AppStorified Mac). This creates unnecessary bottlenecks when it comes to bugfix or security releases. It creates a single point of failure for apps and therefore for devices; if Apple goes under tomorrow (or, more likely, changes their mind completely about whatever they please), how will you continue to update your apps? Worst, it puts Apple in the position of policing for content, which, whether driven by a well-intentioned desire to avoid offensive content or by a malevolent puritanism, is a Bad Thing.

Anyway, all of these points have been made over and over again, by many different people. My own bottom line: I believe in the value of the open web to such an extent that I’ve devoted my career to it. Thus, it feels wrong to keep using, and indirectly encouraging the use of, technologies like Apple’s. That goes especially for iOS and its devices, the area where I think the threat to the web is worst. But it extends to the Mac as well. Even if you maintain that the Mac will never merge into iOS (a position I find disingenuous), there’s no question that spending money on Mac hardware is a way of indirectly feeding the beast. Next time I buy a laptop, I’ll be sad not to be getting a pretty MacBook, but, on balance, I feel more comfortable giving my money to a hardware manufacturer that’s less pernicious.

For what it’s worth, I don’t think that mine is a decision that everyone must, or even should, make. Using Apple products brings pleasure to a lot of people, even people who largely share my ideologies about the free web. It’s perfectly legitimate to decide that the benefits you get from using those products outweigh the downsides. But, for me, it’s past the tipping point, which is why I’m done buying Apple products.

I develop free software because of CUNY and Blackboard

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.