Last week, I attended THATCamp CHNM, and I entered (and somehow managed to win) the Maker Challenge with a WP plugin that pulls related items from the DPLA API and displays them on your posts. I’ve just added the plugin to the wordpress.org repository: http://wordpress.org/plugins/wp-dpla.
Read more about the plugin at my THATCamp post: http://chnm2013.thatcamp.org/06/08/maker-challenge-wordpress-plugin-for-displaying-related-items-from-the-dpla/
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:
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:
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:
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.
#70. Yippee!
I use Github Issues as a bugtracker for a number of my projects. My workflow usually includes having the ticket open in one browser tab, and a local WordPress installation open in another browser tab (to test the bugfixes themselves). When I write commit messages, I want to reference the issue number, but by default, it’s buried deep in the <title> element, and thus not visible on a smallish browser tab.
So I wrote a short userscript that reproduces the issue number at the beginning of the <title>, so I can see it at a glance. It’s structured as a userscript for Greasemonkey/Firefox, though I imagine you could easily repackage it for Chrome or whatever.
[code language=javascript]
// ==UserScript==
// @name github issue number in tab
// @namespace https://boone.gorg.es
// @description github issue number in tab
// @include https://github.com/*/*/issues/*
// @version 1
// @grant none
// ==/UserScript==
var t, ttext, issueno;
t = document.getElementsByTagName( ‘title’ );
ttext = t[0].innerHTML;
ino = ttext.match(/Issue #([0-9]+)/);
console.log(“#” + ino[1] + ” ” + ttext);
t[0].innerHTML = “#” + ino[1] + ” ” + ttext;
[/code]
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!
Many contributors to free software projects fall roughly into one of two categories:
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.
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.
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.
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.
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.
Hey you! Do something about SOPA and PROTECT IP..
The Stop Online Privacy Act (and its cousin in the Senate, the PROTECT IP Act) are inching closer to passage. Time is running short for you to do what you can to stymie this legislation, which could very well destroy the open internet as we know it. (Don’t know about SOPA? Get a nice overview in this short video, or check out Jeff Sayre’s helpful bibliography of resources about the bill.)
If you are reading my blog, you likely fall into one of a few camps, each of which has a vested interest in preventing the passage of SOPA and PROTECTIP:
For one thing, the small-to-medium sized web organizations that are most likely to be targets of SOPA’s blacklisting protocols make up the bulk of the clientele for many web developers I know. These organizations generally do not have the visibility or high profile to put up a stink when and if they fall prey to overzealous “copyright” claims, nor do they have the deep pockets to fund the necessary legal defenses. The danger is especially great for websites that accept – or are built on – user-generated content, like many WordPress and BuddyPress sites; SOPA provides for the blacklisting of entire domains, based merely on the a few pieces of “offending” content, even if the content was not created or posted by the domain owners. Over time, these threats and constraints are bound to make the development of these kinds of sites far less feasible and attractive, resulting in less work for developers – and less development on the open source projects that are largely subsidized by this kind of work.
On a deeper level, those who are interested in the philosophical underpinnings of free software – the rights of the user – should be terrified by the prospect of media corporations gaining what amounts to veto power over our most fecund channels for the exercise of free expression. Free software lives and dies alongside a free internet. When one level of our internet infrastructure (DNS) is under the control of a self-interested few, it makes “freedom” at higher levels of abstraction – like the level of the user-facing software – into an illusion.
At an institutional level, thoughtful folks in higher ed and edtech have been fighting for years against a FERPA-fueled obsession with privacy and closedness. They’ve made strides. Platforms that foster learning in open spaces – stuff like institutional blog and wiki installations – have become increasingly commonplace, demonstrating to the powers that be that, for one thing, the legal dangers are not so great, and for another, whatever legal concerns there may be are far outweighed by the pedagogical benefits to be reaped from the open nature of the systems. The threats put into place by SOPA are likely to undo much of this work, by tipping the scales back in the direction of fear-driven policy written by CYA-focused university lawyers. Advocates of open education, and the platforms that support it, should be keen not to let their efforts go to waste.
At the level of the individual student, the case is more profound. The most promising thread in the story of higher ed and the internet – the thread running through Gardner Campbell’s Bags of Gold and Jim Groom’s a domain of one’s own – is, in my understanding, founded on notions about student power and agency. Users of the internet are not, and should not be, passive actors and consumers of content. Instead, they should take control of their (digital) selves, becoming active participants in the construction of the web, the web’s content, and their own avatars. SOPA and its ilk are an endorsement of the opposite idea: the “ownership” of creative content on the internet is heavily weighted toward media companies, which is to say that you are allowed to be in control of your digital self until it causes a problem for a suit at MPAA or RIAA. The entire remix/mashup culture of ds106 is impossible in such a scenario. If you think that this culture, and the ideology of student personhood that underscores the culture, is worth saving, you should be fighting SOPA tooth and nail.
What can you do? Write a blog post. Join or support the Electronic Frontier Foundation. Most importantly, if you are an American, contact your representatives in Congress. The Stop American Censorship site makes this easy, and gives you all the talking points you’ll need. (“This bill is a job killer!”)
Do it now!
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.
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.
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.
Developers have all sorts of reasons for releasing software under free software licenses like the GPL. A few, off the top of my head:
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.
A few months ago, I was contacted by Kathryn Weinstein, a local graphic designer and member of the graphic design faculty at Queens College, about co-teaching a WordPress course, for credit toward the Graphic Design degree, in the fall of 2011. Immediately, I felt drawn to the prospect of revisiting my old haunting grounds. But more than that, I was convinced that such a class had potential to benefit students in a few important ways. So I agreed to the project, and Kathryn and I have been planning, off and on, since then.
While the first goal of this fall’s course – titled “WordPress: Beyond the Basics” – is, of course, to serve its enrolled students, Kathryn and I have agreed that we also want our experience to serve as a sort of experiment for future courses, at QC and beyond. In that vein, I’ll be writing occasionally, both here on my personal blog and on our course site, about the process of planning and executing the course. This post will focus on how we’re conceiving and justifying the class, in very broad terms.
The course objectives, in the current draft of our syllabus, look like this:
This suggests a multi-layered approach to the course. On one level (roughly corresponding to the second objective in our list), it’ll be what I take to be typical of a graphic design curriculum. The first and third objectives, which will involve getting our hands dirty with some real coding, call for more justification. A few thoughts:
On balance, I see these considerations as a pretty solid justification for the academic value of a course like the one we’re considering.
If it’s not too much of a stretch to justify a graphic design course on designing for the web – and, as you might gather from my previous musings, I don’t think it’s a stretch at all – you may still wonder why it makes sense to focus on WordPress.
There are a few reasons. First is a conviction, shared by Kathryn and me, that diving into a complex platform like WordPress will ultimately make for a more engaging and valuable experience than a more staged, “Hello World”-style introduction to web technologies. It’s true that many of our students will never have seen so much as a line of HTML, and it may be true that our job would be easier if we waded in the shallows instead of diving headfirst into WordPress’s morass of HTML, CSS, PHP, MySQL, JavaScript…. But I – a Seasoned Web Professional – didn’t learn about the web that way. I learned by jumping into a complex system, and figuring my way out.
The architecture of WordPress makes this kind of learning easy. Take WP themes. I’ve often heard friends (who were much smarter than me, by the way) complain about the fact that WP’s theming system involves the on-the-fly interpretation of raw PHP – a recipe for security and aesthetic disasters if there ever was one. But this feature/bug also makes the themes readable, and thus hackable. The fact that WP is written largely in procedural PHP means that you can follow its thread of reasoning, change a line of code, and see the changes with a simple browser refresh. No compilation; no MVC framework; no class dependencies. One might argue that these features of WP make it less robust or sophisticated, but they almost certainly lower the bar for the n00b.
Moreover, WordPress is really, really widely used. Starting with WP will give students a sense of what it’s like to develop a website in the actual world. More than that – facility with WP development is something that a budding designer can put on her resumé, and it will actually mean something to those who read it.
From an ideological point of view, I’m a fan of the fact that we’ll be able to build an entire class on totally free technologies. From the LAMP stack, to WordPress, to Firefox and Firebug, we’ll be developing with tools that are free-as-in-beer and free-as-in-speech. That’s good for students in several ways. It means that they won’t have to plop down for expensive licenses. And it means that lessons about data ownership and free software philosophy can come along for the ride.
In an upcoming post, I’ll be talking in more detail about what we plan to cover in the course. It’s still very much a work in progress – and will be right up through the beginning of the semester, as we won’t know until then about our students’ backgrounds – but I plan to use this space to workshop some ideas. Feedback welcome!
This year I attended my third THATCamp (at CHNM, anyway – I’ve been to a few others around the country). The first time I went, in 2009, I’d just started working with Matt Gold on the CUNY Academic Commons. I didn’t know many people in the digital humanities community. I was a graduate student in philosophy, accustomed to conferences that were philosophy-ish and graduate-student-esque. THATCamp stood in stark contrast to this background, and as a result was very new and exciting. An event where academics would get together to talk about things that were actually interesting, independently motivated, and new – the very idea of it! I couldn’t help but feel intoxicated by it all.
Fast forward two years. I’m no longer a graduate student. I’m no longer a full-time employee of a university. I’m no longer a stranger to digital humanities and the DH community. And I’m no longer a n00b. Unsurprisingly, this perspective changes the way I experience THATCamp.
For one thing, the “more hack, less yak” theme which prevails at THATCamp does not have revelatory ring it once had. I build stuff for a living. All I ever do is hack. As a result, I actually look forward to the occasional yak. I recognize that the “less yak” mantra arises out of frustration about the futility of “mere” talk, and represents a railing against the tendency of academic activity to consist of little more than such talk. In this sense, I should probably be grateful that I’m no longer in a career where I feel trapped under a pile of words. And, in fact, I do feel pretty happy about it, especially after all these years. But my recent career changes do mean that I don’t get the same gee-whiz-I’m-so-excited-we’re-actually-doing-something rush out of THATCamp that many others (justifiably) do.
On a related note, I’m less excited about geekery these days than I was before I was a professional geek. (I’m being intentionally narrow in my use of the word ‘geek’ to mean ‘someone who codes’. The word isn’t particularly important; swap it out for ‘coder’ if you want.) THATCamp can be like a dude ranch. The city slickers come to the country for the weekend, ride a horse, throw a lasso, eat some beans-n-bacon, and say “Gee, isn’t the country life great?” What the dudes don’t realize is that being a rancher means doing stuff like shoveling a lot of cow shit. In the same way, coming to THATCamp and learning a bit about Greasemonkey scripts or the Google Maps API or WordPress themes can be a rush – after all, those things are all really cool. But it’s also a kind of cartoonish picture of what it’s like to write code all day long, which is really more about shoveling the cow shit of bug tickets than about whizbang jQuery effects and singing campfire tunes.
Of course, I’m under no illusion that THATCamp sessions are meant to be introductions to the Real Cowboy Life, and I’m certain that the attendees of such sessions aren’t under any such illusions either. And I should be clear that I don’t want to be a spoilsport. For the most part, I think it’s genuinely good for people to learn how to write code (where writing code should be understood as standing in for a whole bunch of related phenomena). For one thing, it’s undoubtably good for people to engage critically with the tools that mediate so much of our lives. Moreover, people like Patrick Murray-John have been making some interesting, if tentative, arguments for the ways in which the modes of thinking exemplified by coding might interesect with, and augment, the modes typified by traditional academic work. Plus, learning to code is just plain fun. So it’s great that people who wouldn’t otherwise have the chance to learn something about code have THATCamp as an outlet. I’m just no longer one of those people, I guess.
I also would probably enjoy THATCamp more if I broke outside of my own comfort zone. During this year’s event, I skipped a couple sessions to write Anthologize code with a few members of the One Week | One Tool gang. It was a blast, and a great way to spend time with some friends who are otherwise scattered throughout the country. Yet, I might have gotten more out of the event if I’d attended more sessions, especially sessions whose subjects were a bit outside of my normal area of specialization. But at an event like THATCamp Prime, which has the usual round-up of DH A-listers talking about tried-and-true topics, it becomes increasingly difficult to find those truly new conversations.
I don’t really mean these observations to be wholesale critiques of the THATCamp setup. Many of the reactions that I saw to this year’s event – blog posts, tweets, personal conversations, and the excited looks on people’s faces – suggested that the newcomers felt the same sense of giddiness that characterized my own first THATCamp experience. But I do think it’s interesting how my giddiness (or lack thereof) is so hugely shaped by changes in my own standing over the years. Maybe next year I’ll make more of a concentrated effort to carve out a spot at THATCamp for folks with my particular set of interests and strengths.