Author Archives: Boone Gorges

WordPress in education, meet the free software community. And vice versa.

· 28 Replies

There’s a huge, amorphous community of people using WordPress in education. Let’s call it WPedu. There’s another huge community of people involved in the WordPress free software community. Let’s call it WPorg.

WPedu, meet WPorg. WPorg, meet WPedu.

WPorg should know that WPedu is killing it right now

I’d like WPorg to know that WPedu is kicking some serious ass. Take DS106 as an example. DS106 is a distributed course on the topic of Digital Storytelling (that’s the “DS”), where students all over the world – some of whom are enrolled in credit-bearing DS courses at their colleges, some of whom are just tagging along for the ride – use their blogs to complete assignments of various sorts. WordPress, FeedWordPress, BuddyPress, and a bunch of custom hacks are used to aggregate content from hundreds of participants into a single stream. The whole thing is built around the idea of openness: existing, open standards like RSS are being used to federate standalone instances of WordPress (alongside any other system that outputs RSS).

People working on free software – like you, WPorg! – should be flipping out over how awesome that is.

Similarly impressive innovations can be found all over the WPedu world. The innovation is motivated by the love of the work, and by principles: education should be open, individuals should control their data and their online identities, software should be free as in speech. These are the very same principles that are close to the hearts of free software enthusiasts.

People involved in the WPorg community should be spending more effort reaching out to WPedu people. The software developers, instructional technologists, faculty members, and other people working in WPedu are a huge, largely untapped resource for the free software project. People working in K-12 and universities, especially those working in public institutions, often have an incentive (even an imperative) to be sharing their work out to the larger community. (Contrast this with the fact that for-profit WP devs actually have a disincentive to contribute, an issue I wrote about recently.) People in WPedu are experts at piecing systems together, at writing documentation, at community moderation, and so on. They often enjoy flexible job descriptions and fairly loose oversight, and they’re less beholden to financial issues than people working in the private sector. Thus, for many WPedu people, it’d be quite concievable to shoehorn some free software work into their workweek. Most of all, WPedu people are totally awesome people – you have to be pretty awesome to put up with the lackluster pay and ridiculous bureaucracies that education folk have to deal with. Start talking to these awesome people. They have incredible ideas about where WP should go, and they have the resources to help get there.

WPedu should start tooting its own horn

On the flip side: WPedu, you are doing some cool shit, and deep in your heart, you know it. So don’t be afraid to talk about it. It’s true, ome of you are blogging, and that’s great. These blogs are usually addressed (understandably enough) to fellow WPedu people – “here’s a cool new way to use WordPress in a university”, etc. But you should stop qualifying yourselves: Lots of the stuff you’re doing is legitimately a cool new way to use WordPress, period, and you should be proud of that. Own your excellence and innovation.

I come from WPedu, so I say this from experience: there’s too much modesty, bordering on mousyness, among WPedu innovators. Many – most? – of you were never formally trained in software development (or design, or support, or documentation, or whatever). I know I never was. And being embedded in institutions founded on the very notion of Expertise – you can’t spell University without PhD – makes you too unsure of your own skills to reach out and get involved. Here’s a secret: Most of the people in the WPorg community came from non-technical backgrounds, too. (IMO, that’s one of the things that has made WordPress successful, but that’s a topic for another post.) You deserve to be involved, just as much as any of the current community contributors. Three-quarters of expertise is having the confidence to get involved.

If that’s not enough persuasion, here are some practical considerations.

  1. When you build systems using a piece of software – like, let’s say, a student blogging system using WordPress – you become dependent on the future development of that software. By getting involved in the community – submitting patches, doing beta testing, participating in support forums, writing plugins and themes, blogging, etc – you can earn a seat at the table where decisions about WP’s future are made. When your voice isn’t heard, someone else’s voice will be heard in your place. And, as someone who straddles WPedu and WPorg, I can say with confidence that edu and non-profit voices are way underrepresented in the WP project.
  2. Very Important People, such as your boss, your promotion committee, public and private grant committees, and so forth, will be Very Impressed by a list of contributions to free software projects. If you can tell funders that your software has been downloaded hundreds of thousands of times (as we are unashamed to do with the CUNY Academic Commons project), and if you can tie this into a broader narrative about engaging meaningfully with a broader public, it can help to guarantee your financial continuance, if you know what I mean.
  3. It’s the right thing to do. The work that you’re doing at your institutions is helping your students in a huge way. If, by putting in just a bit of extra work, you can increase the potential beneficiaries of your work by ten- or one-hundred- or one-thousand-fold, why wouldn’t you do so?

I shouldn’t make it sound like there’s no overlap between WPedu and WPorg. There is. But it’s much smaller than it should be, given the direct parallels between the ideological goals of the free software project and the ideological goals of the educational enterprise

I’m working on a couple ideas that I think will help to bridge some of the gaps between WPedu and WPorg. I’ll share more about them when they become more well-formed. In the meantime, I’d love to hear your thoughts about how to move these mutually beneficial connections from the realm of the practical to the actual.

Blog, come forth!

· 4 Replies

This blog has gone unloved as of late. I’ve been working too much, and not taking the time to sit back and think about the work I’m doing, and I think that’s a bad thing. Reading Alan Levine’s call-out the other day reinforced the feeling that I should devote more attention to reflecting in this space, if only for my own sanity.

So, as a starting place, I made a new theme – my first revamp since I started this blog in late 2008. I ripped off Mark Jaquith’s idea and used Twenty Twelve – the new default theme that will ship with WordPress 3.5 – as my parent theme. It’s much easier on the eyes than my old theme, and its responsive nature allowed me to uninstall WP Touch. (WP Touch, you served valiantly lo these many years. RIP.) If you’re interested, I’ve made my (very modest) child theme available on Github.

BuddyCamp – it’s about time

· 6 Replies

Yesterday the first ever BuddyCamp was announced. BuddyCamp Vancouver 2012 is the brainchild Cyri Jones, a Vancouver-based educator and entrepreneur who works a lot with WP and BP. I think it’s going to be a very cool event.

The idea of a BuddyPress-specific event along the lines of WordCamp has been tossed around a lot in the past, at least between the most active members of the BP community. Some have argued that BP is a bit “niche” to serve as the foundation for an event like this (see some of the comments in this WP Realm post, for example). However, while it’s clear that BP has far fewer users than WP, those who do use BP on an everyday basis are often very passionate about it. I think that the community is plenty large at this point to support local events of this type.

In the past, John Jacoby has suggested that a more general “WordPress Plugins Camp” might be a logical precursor to a BuddyCamp – after all, there are lots more plugins than just BuddyPress, which translates to many more potential attendees. I think a general Plugins Camp is a pretty kickass idea, and devs/designers working with BP would have a lot to bring to such an event. But it’s worth noting that this first BuddyCamp will be about a lot more than just devs and designers. I’d wager that over half the attendees will be people who are using free software to build online community space, from a non-technical point of view. These people may not know the first thing about building a WordPress plugin, but they have lots to say about how software can facilitate community – and this is something very specific to a BuddyPress event. So I think there’s really a need for something like a BuddyCamp, where the people who are building the software can get in the same room with the people who are pushing it to its practical limits in real-world scenarios.

Also, while I wish that the whole thing had been arranged a few months sooner (sometimes the best ideas happen at the last minute!), I think the timing of BuddyCamp Vancouver is really great. It’s sandwiched between two events, also being held in Vancouver, which should have huge overlaps in terms of interested attendees: WordCamp Vancouver and Open Ed 2012. I’m hoping that, in particular, a lot of people coming into town for Open Ed will think about coming a day or two early to talk about BuddyPress and its uses in supporting online learning communities. Spoiler alert: I may be talking about this very topic in my own BuddyCamp Vancouver session 🙂

I’m hoping that this is just the first of a series of BuddyCamps. I can easily imagine that there’s enough interest in BP to support a handful of similar events around the world each year. If you’re a motivated fan of BuddyPress, you may want to think about planning such an event in the future!

Project Reclaim update

· 5 Replies

Back in March 2011, I kicked off the Project Reclaim project. Since then, others have picked up where I’ve left off – most notably, Doug Belshaw and D’Arcy Norman (who have surpassed me both in the reclaiming and in the blogging about the reclaiming). Behind my radio silence, though, has been a flurry of recent reclaiming activity:

  • I’m mostly de-Mac-ified. I recently bought a Samsung Series 9, which is serving as a stopgap full-time machine until I have the time to set up a desktop Linux rig. On day one, I wiped the Windows 7 installation and installed Arch Linux. It took some time to get set up, and I’m still using my Mac for a couple of things (Picasa, Skype, the old Adobe AIR Tweetdeck), but I’m almost totally moved over. I may write a post or two in the upcoming weeks about specific parts of the transition – there were some pain points, to be sure, especially in the initial setup. But, in general, it’s been smoother, easier, and more pleasurable than I would have guessed. Using Linux full time makes me feel like I’m back in the driver’s seat of my computing life, and it feels extra good to know that 95% of the software on my full-time machine is non-proprietary.
  • At the same time that I moved to Linux, I also switched to Vim. I’d been a user of BBEdit, which is a really great piece of software, but moving away from the Mac meant I had to choose something else. So I figured I’d go for the powerhouse of all text editors. Vim has a certain allure. When I was younger, I studied jazz piano. I remember watching my instructor play and being driven nearly to tears: I understood, in broad strokes, what he was doing and why it sounded the way it did, but it crushed me that I couldn’t translate that knowledge into the same kind of performance magic that he could. I feel much the same way about Vim masters. I’m far from a master, but I’m getting much much more fluent. Also, of course, Vim is non-proprietary, and it gives me major geek cred. So, big win all around. I should note that the Vim transition has actually been far more difficult than the Linux transition, and it was only after about four or five weeks of full-time use that I started to feel like I was back to my pre-switch level of productivity. (In this sense, it was a lot like switching from QWERTY to Dvorak.)

The big proprietary services and software products left in my life are Dropbox and Twitter. Moving away from Dropbox is fairly simple – see D’Arcy’s great posts on his experiments with Owncloud – I’ve just been lazy about it. Twitter is far more complicated, both technically and socially, as well as far more pressing, given Twitter’s recent NBCishness. So that’s the next mountain to climb.

How many others have been Reclaiming over the last year or two? Would love to see more projects along the lines of D’Arcy’s and Doug’s.

“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.

TimThumb problems and solutions for WordPress theme developers

· 4 Replies

TimThumb is popular PHP script for dymanic image resizing, and is often included in WordPress themes and plugins. It caches its processed images for performance reasons; its default cache directory is called cache, one directory level up from the script itself. TimThumb itself helpfully allows users to define a custom cache directory with a constant (FILE_CACHE_DIRECTORY) as well as a mechanism for loading this custom configuration (an optional timthumb-config.php file).

This setup provides plenty of flexibility when you’re using TimThumb on a one-off site for a client. But when TimThumb is packaged with a theme or plugin, this method of configuring TT not very helpful. Take the case of WooThemes, which uses TimThumb in all of its themes. We use a number of these themes on the CUNY Academic Commons, where I keep tight reins on file permissions. Our Apache user can’t write to the subdirectories of wp-content/themes/, which means that the versions of TimThumb in this directory can’t use the default cache location.

The problem is that there’s no easy way to fix this in a global way. Creating a /cache/ subdirectory in each of these theme directories and chmodding them to something more lax is out of the question in my scenario. After all, I already have a directory where Apache can write files: the WP uploads directories (wp-content/uploads and wp-content/blogs.dir).

But configuring TimThumb to put its cache in one of these places is difficult to accomplish globally. The obvious solution is to create appropriate timthumb-config.php file in each of the theme directories in question. This stinks, though, because it means that my modifications will have to be reapplied each time I upgrade the themes. In fact, what I’ve actually done for the moment is a variation on this: I created a centralized timthumb-config.php file, in a centralized location (wp-content, in my case), containing a single line:

[code language=’php’]

[/code]

I wrote a short script that crawled over every one of my WP themes, and if it found an offender (in my case, any theme with ‘WooThemes’ in the Author tag), create a symlink to the global config. I’ll be including this script as part of my more general deployment scripts.

Of course, this is all extremely inelegant. There are a few things that the theme developers could have done to account for my sort of situation:

  • Stop putting a copy of your shared utilities (the “framework”) in every theme directory. I understand why the theme shop might make this architectural decision – I’m sure that the vast majority of their theme sales are to people running the theme on a non-networked, single site. But it causes a lot of problems for Multisite networks that offer many themes to their users: a single change in the framework means updating all themes, which becomes a real pain if the theme dev’s autoupdater also isn’t working properly. Allow your framework to be installed as a network-activated plugin, or at least dropped into the wp-content directory. Better still: You can continue to ship the framework files with the themes, but only load them if the pluginified version is not found. That gives you the best of both worlds.

    Now in the case of TimThumb, this schema wouldn’t have solved the problem. But it would have meant hacking a single file, rather than 50 different files spread out through my installation.

  • Put a wrapper around TimThumb, to allow more flexible placement of the config file. For instance, create a file called mytheme-thumb.php, which looks like this:

    [code language=’php’]

    [/code]

    Then point all of your TimThumb-generated src attributes to mytheme-thumb.php, instead of directly at TimThumb. This way, if a global config is found, it’s loaded first, otherwise it falls back on a local timthumb-config.php file, as specified by TT itself.

  • Pluginify TimThumb before using it In a perfect world, you would have the flexibility of WordPress behind TimThumb: the ability to store your cache location to the database, for example, or to filter the location using apply_filters(). I did a bit of testing to see just how much overhead this would add. In my tests, TimThumb used about 700KB to load a simple picture. To load WordPress using the SHORTINIT constant (which loads just enough of WP to get things like get_option() and apply_filters()) takes about 2800KB. So loading WP SHORTINIT + TimThumb would take about 3500KB, or about 5x what it takes to load the same image using TimThumb alone. This wouldn’t be so bad with aggressive caching, but it’s probably too much sacrifice for a script that may get called several times on every single page load.

    So here’s another idea: Just drop in wp-includes/plugins.php. I once heard someone say that a great way to improve any PHP package is to include this file, and I think they’re right. plugins.php is self-contained (it doesn’t require the rest of WP), and it only adds another 50-100KB of overhead. Let’s take our mytheme-thumb.php file again, but add some plugins.php goodness:

    [code language=’php’]

    [/code]

    Now in this example, thumb.php wouldn’t have to be an out-of-the-box TimThumb instance. It could be filled with wonderful do_action() and apply_filters() goodness. And your global-timthumb-config.php or timthumb-config.php file wouldn’t just define constants – you could have full-fledged PHP functions, using WP’s hook infrastructure.

    This means maintaining a fork of TimThumb, but it could be a great resource for WP theme developers.

One year as an ex-academic

· 8 Replies

I realized the other day that it’s been just over a year since I quit graduate school, and by extension gave up on a life in academics. It was around the middle of April 2011 when I submitted my resignation letter. (I was spending the month teaching a course at my alma mater, and I felt more than a twinge of poignancy at the fact that I wrote the letter just a few hundred feet away from where I’d written my acceptance letter about nine years earlier, during my last semester of college.) Anyway, I thought I’d take a moment to reflect on how the year – my first spent as a non-student since I was four years old! – has gone.

The most personal of my fears about leaving graduate school had to do with the way I define myself. I was proud to think of myself as the academic type, and doubly proud to think of myself as a philosopher. (Observation: when someone who wears many hats does some work in philosophy, it’s common to see “philosopher” move to the front of their list of self-descriptors. Quelle prestige!) I’d spent about a third of my life under a certain avatar (in name if not always in practice), and I was nervous about casting it aside. How would I think of myself? How would I describe myself to others?

It turned out that the transition of self-definition was much less difficult than I’d feared. There are a few reasons why. First, from a practical point of view, I wasn’t really that engaged in my academic work anyway. The second half of my graduate career was characterized by attempt after semi-subconscious attempt to distract myself from the philosophical tasks at hand. These attempts were overwhelmingly successful, with the result that even when I did devote large amounts of time to doing philosophical work – which happened in fairly infrequent but significant bursts – my heart wasn’t really in it. A second, related reason for the easy transition is that, as a result of years of productive distraction, I had a number of alternative, and more meaningful, identities on which to fall back: software/web developer, educational technologist, teacher, etc. I imagine that such a transition would be far more difficult for someone who didn’t have viable alternatives.

So, from the internal point of view, the transition from academic to ex-academic went more smoothly than I’d hoped. The external transition – how the change has affected my relationships with others, or at least how I perceive the relationships – has been a little bit harder.

The thing is that, while I’m not one of the academics anymore, I spend much of my time with them. Most of my professional work is for universities, and many of my friends and co-workers are tied to schools in one way or another. Thus, I haven’t been able to quit the academic world cold turkey: I still have to go to meetings, deal with institutional BS, navigate political obstacle courses, etc. These are the crappy parts about working in universities, and becoming an ex-academic hasn’t made them any better in my case. (Admittedly, this is because of choices I’ve made to continue working where I work. I have friends who have left to go into, eg, banking.)

In addition to the more obvious annoying bureaucratic details of working within the university, there are the negative social aftereffects of dropping out: I don’t have a PhD, and never will, which means that I’m viewed (or at least, I feel like I’m viewed) in a different way. My opinion on academic matters just doesn’t matter in the same way anymore. I suppose that’s as it should be: the more time I spend away from the day-to-day of the university, the less relevant my opinions about that day-to-day become. Thus, when doing development work with universities, I’m a developer with some helpful experience in academia, rather than a technically-inclined academic. I should note that there have never been any specific instances where I’ve been called out on this distinction, or where it’s had an obviously negative effect on a relationship, but it’s always there in the background. (On a related note, I’ll probably never have a job where I, say, lead an academic computing program – but that’s not something I really want anyway.)

Thus, while I hate to sound sourgrapesesque about it, I haven’t lost much of anything by dropping out. I’m still heavily engaged in enabling the functions of the university that I find most important: teaching and scholarship. It’s just that I do it one or two levels of abstraction higher than when I was in the classroom or the library, and maybe it’s just as well.

On a personal level, the gains of dropping out have been enormous. Not only do I no longer devote any time to working on a project that I’m not really invested in (the dissertation), but I also no longer feel the crushing weight of the unfinished dissertation in my spare time. In the past year, I’ve read more broadly than ever in my life, discovering and developing areas of interest that I would never have dared to devote time to. I’m a new dad and I work from home, which means that I’ve been able to be the kind of dad I’d always hoped I’d be, without feeling guilty about the work I “should” be doing. I’m making an amount of money that is directly connected to the quality of my work, a startling and frankly disarming contrast to the way things seem to operate in universities, especially in the work I did as an adjunct. It’s been about a year since I intentionally read anything explicitly philosophical, but recently I’ve started to feel that itch again – and when I pick up a book or article, it’ll be because of an independent interest, rather than because it’s in an Important Person’s Bibliography.

So for me, quitting graduate school has been a nearly unmitigated success. It took years to work up the courage, and to develop the alternative paths that would make quitting feasible, but once those factors were in place, it was really the best decision I could have made.

Add an “Other” checkbox (with textbox) to a BuddyPress profile field

· 5 Replies

This is a pretty common form format:

Foo
Bar
Other

(Imagine that the textbox was next to the word ‘Other’ – wpautop() or something is being a stupid craphead and inserting a line break.)

It’s not really possible with BuddyPress’s xprofile fields. Today I dove into the codebase to see how hard it would be to add such a feature natively. The answer: Too.

So I wrote a hackish plugin instead, which you can get from this gist. (Note that it’s not in a plugin wrapper. Put it in your bp-custom.php.) To use: (1) On the Admin screen for a profile field, select ‘Yes’ under “Other Field”. (Note: it only works for checkbox fields!!) (2) ??? (3) Profit.