Jon Smajda

Updates

Sun May 13 13:15:23 -0500 2012

I’ve had dry spells in the past on this blog, but this has been the longest. A lot has happened.

In December, I completed, and successfully defended, my PhD in sociology! Finally! It’s been a huge relief to be done and have that part of my life behind me. While I applied for some academic jobs this past Fall, nothing has panned out and I’m mostly out of the academic world these days. Not entirely though: I’m still working with The Society Pages and Contexts, keeping the servers running in the engine room for both sites and doing some podcasting and editorial work for TSP.

As a grad student I got interested in studying the culture of open source software, and I’ve now officially gone native: working as a web developer full-time for BOLD. Most of my time there is now spent working with Python and Django, which I greatly enjoy: both are elegant, powerful, and fun. We’ve been working on a particularly large Django project for the past year now that has been a great learning experience. If I ever get around to posting here again, there’ll likely be some Python and Django-related posts sharing what I’ve learned.

After spending nearly a decade pursuing a PhD in sociology, it’s been a bit of a mental adjustment to get used to the idea that this is now my career, not sociology. On most days, however, I’m happy with how this has turned out. There’s an ideal vision of what life in academia is like that I know I would love, but the reality is often pretty far off from that. Plus, I’m pretty pessimistic about the direction higher education is heading in this country.

More concretely though, I think there are several aspects of my personality that are just better suited to what I’m doing these days. For instance: I don’t have the right kind of long-term patience for academia. For example, my advisor and I have an article scheduled to be published this Fall. It was accepted by the journal last Fall. We finished writing the article last Spring. It’s based on research I did in 2004. So in academia, in other words, you’ve got to be in it for the long haul. Compare this to what I just said about about web development: in the time it’s taken this paper to go just from acceptance to publication—nevermind the actual time spent doing the research and writing!—I’ve learned an entire new programming language and web development framework. And I’m sure there will be others in the next few years. Software development is a fast-moving field. Sociology is not.

Let’s see…what else is new?

Last year, while I was scrambling to finish my dissertation and also get a new career started, I re-discovered running as the ultimate stress-reliever. A few months back, I started tracking my runs on Runkeeper. I keep going back and forth on whether I actually want to start entering races. The competitor in me thinks I should, but a big part of the appeal of running for me is getting away from other stressors in my life so I’m hesitant to introduce any extra stress into running. For now, it’s just for fun.
Chloe is now five years old. She starts Kindergarten in the Fall. She’s amazing.

That’s about it for now. Hopefully it won’t be another 10 months before I post again!

WordPress and Git

Sun Jul 17 15:35:54 -0500 2011

A few years back, I wrote a post on managing WordPress. For the most part, it’s still valid but I’ve been using git to manage code for quite awhile now, so I thought I’d give a little update.

Thanks to Mark Jaquith, there’s now a reliable, complete git mirror of WordPress. I’ve been using git to manage my WordPress sites for awhile now, but the actual updating of WordPress has always been weird to force into the git loop. My practice has been to keep a stock WordPress git repository that is also a subversion repository (just add *.svn to your .gitignore). I svn switch to a new tagged release, commit the result in git, and then this repository is set up as a remote on all my active WordPress sites, so I ssh into these sites and merge each with this stock WordPress branch.

Now that there’s a good Wordpress mirror on github, the way to take advantage of this may seem obvious: just clone this mirror and then merge from it. However, that has a couple downsides. First, you get messy history: all of the commits you’ve made locally for your site get drowned in WordPress core commits. Second, unless you’re actively developing WordPress core, you only care about official releases (and possibly beta releases). In other words, you want to merge with tags only and you don’t want messy history. So here’s how to get that: instead of cloning Jaquith’s mirror, just add it as a remote and squash the commits.

Step-by-step:

If you’re starting from scratch, create an empty git repo with git init and create an initial commit with something — maybe a local-readme.txt file explaining what you’re doing. (“Squash commit into empty head not supported yet”.) Anway, add the remote:

git remote add wp git://github.com/markjaquith/WordPress.git
git fetch -t wp

The first adds the github mirror as a remote named “wp”. The fetch -t will make sure you get all the tags. (Run git tags afterwards to see the list of available tags.)

Next, merge with the latest tag (here, 3.2.1):

git merge --squash --no-commit -s recursive -X theirs tags/3.2.1

The --squash means it takes the hundreds (thousands?) of ancestor commits for that tag and compresses it into a single commit. The -s recursive -X theirs tells git that if there are conflicts, use the new version. (Remember, all you’re doing here is creating a simple local WordPress mirror to merge your actual WordPress sites with.)

The --no-commit tells git to merge but stop just short of actually making the commit. So make sure everything looks good. For example, you can’t squash binary files so you may get conflicts about that. If this happens, just git checkout the latest version explicitly. For example, going from 3.2 to 3.2.1 I had to do the following: git checkout tags/3.2.1 -- wp-admin/images/wp-logo.png

Finally, git commit -m "3.2.1"

Now, as I said above, what I like to do is this: do not use this as your starting point for an actual WordPress instance. Instead you add this repo as a remote (just like we did above) to your site and then you can just do a git pull wp (or whatever you call it) there. That way you only have to do the little dance above once for each release if you’re responsible for multiple WordPress instances.

Quick aside: Why don’t I just put mine on github? I could. But here’s the problem: the reason Jaquith’s mirror is such a big deal is because he’s a WordPress core developer. Others have done this, but they’ve all had shortcomings: the ones I knew about didn’t include tags, or they were really slow to update, or they simply got abandoned. I’m not blaming any of them. Sure, I could put a “simplified WordPress repo” on github, but I don’t want to commit to updating it instantly every WordPress update forever. And what works for me may not work for you. The process I described above is not difficult and shows how you can take the comprehensive mirror and merge with it to make your life easier in your own way that suites your needs.

Plugins

What about plugins? There’s no git mirror of the WordPress Plugins Directory that I know of, so I usually revert to my subversion hack described above: svn co http://svn.wp-plugins.org/plugin-name/trunk/ . into a directory for the plugin and then commit the results into git. Alternatively, you can use WordPress' backend plugin updater, which can work just fine, but I inevitably end up having to modify certain plugins and that process simply overwrites the files and you lose your modifications, whereas at least svn up will alert you to conflicts and let you merge your changes into the new version. (Makes me wonder how many out-of-date plugins would be updated if the WordPress Plugin Directory worked more like github — where anyone could fork your plugin and fix it if you won’t…)

Beta Testing

If you want to test beta releases locally before installing them, you can just create a “testing” branch of your WordPress repository (git checkout -b testing) and then instead of merging with a release tag, just merge with whatever branch the development for the next version is happening on. Make sure if you’re going to switch back and forth to backup your database though!

Merging into an existing site

This may sound great for setting up new sites, but what about merging into an existing wordpress site? You’ll get conflicts because git won’t have a common ancestor commit to merge from. So fake one: create a graft file file linking your most recent commit where you updated WordPress (if you’re using git for the first time, just use your first commit) and the SHA1 of the commit for the version you’re currently running in your base WordPress repo. After creating this file, you should see both branches reflected in your git log and when you try to merge to the current commit in your remote branch, it should merge cleanly, as if you’d been merging with it all along.

Dvorak Follow-up

Sun May 15 11:39:52 -0500 2011

About a year-and-a-half ago, I wrote about how I was learning Dvorak. I was still very much in the learning phase at the time and I’ve been meaning to revisit the post for awhile now. Here’s a quick update:

I’m still typing Dvorak.
My hands rarely hurt anymore. This was the main motivation for trying Dvorak, so I’d call it a success. The decreased motion required with Dvorak seems to have made a difference. One qualification: I’ve also learned to be more conscious about how hard I type, so that may be making a difference as well.
I have no idea if I’m faster than with QWERTY. This wasn’t a factor in learning Dvorak for me and I haven’t done any speed tests.
I wanted to be able to switch between QWERTY and Dvorak. This has not been so easy. I can type QWERTY, but I’m slow and have to think extra hard about it and/or look at the keyboard the whole time. This is doubly bad because about the only time I have to type QWERTY is when I’m at someone else’s computer, usually with them watching while I’m trying to talk at the same time. So, already not an ideal environment for good typing. I could probably make the effort to get better at QWERTY and practice switching layouts more often, but it’s just not been that big of a problem yet.
If you type a lot of English and your hands hurt, I’d recommend trying Dvorak. Beyond that specific situation, I’m not sure how heavily I’d recommend it if you’re already a good QWERTY typist.

That last point is worth expanding on. The people who seem interested when I tell them I use Dvorak are programmers. Programming alone, however, is a pretty poor reason to switch. First, you don’t actually type that much when you’re programming. Second, all the special keys (brackets, braces, colon, semicolon, etc.) that you type a lot when you’re programming have moved, and not necessarily to more ergonomic locations. In fact, they’ve been moved to less ergonomic locations to make room for regular letters non-programmers use more frequently. You also have to relearn keyboard shortcuts, and keyboard shortcuts often have been chosen for ergonomic convenience. If you’re a vim user like myself, you have to relearn your vim muscle memory.

However, Dvorak is more easy to recommend to people who just type a lot of English: writing papers, dissertations, emails, blogging, etc. This group of people, however, tend to just think I’m crazy when I tell them I use Dvorak. They’ve often never heard of it and assume it’s something hard-core programmers might do, when, in fact, it makes more sense for them than the programmers who are intrigued by the idea. Of course, there’s an overlap between “people who program” and “people who spend a lot of non-programming time typing on a computer”, but it’s interesting to me that there’s a disconnect between those interested in Dvorak and those who could most benefit from it.

Link: The Screenshot That May Finally Force Me To Buy An iPad

Wed Apr 20 21:25:13 -0500 2011

That’s Vim! On an iPad! Using Prompt!

I’d love to buy an iPad, but my 5-year-old MacBook is really starting to show its age and there’s no way I can justify both. The main reason I need a laptop though is for writing in Vim. If I could do that on an iPad…

One question and one comment:

What are the ergonomics of using an iPad with the external keyboard? I’ve never actually seen someone do it, and it seems like it could be very awkward.
The “Oh yeah…” moment that brings me down a little bit after seeing this screenshot is that, of course, it’s an SSH app. You’re still connecting to another computer over the internet, and therefore dependent on, say, coffee shop wifi to keep you connected while writing. Of course, with a mythical Android tablet, with it’s old school file system, one could have a fully native Android version of Vim working off local files. I hear there are several great writing apps for iOS that hook into Dropbox, but I suspect the Dropbox-enabled port of Vim is still a ways off.

Link: Amazon Announces Library Lending

Wed Apr 20 20:04:42 -0500 2011

Amazon is working with OverDrive, the leading provider of digital content solutions for over 11,000 public and educational libraries in the United States, to bring a seamless library borrowing experience to Kindle customers.

I’ve had my Kindle about a year-and-a-half now and I get asked more about it now than when I first got it. “Can I check out ebooks from my library?” is one of the top questions people have. Our local library has OverDrive ebooks already, but has thus far had no Kindle support. There are a lot of avid readers out there that still go to libraries. This will sell some Kindles.

To read OverDrive books on my Kindle I break the DRM and convert them to .mobi files. This involves using some python scripts that are easily found online. This is not, however, something I can recommend to, say, my parents or their friends that are frequent library patrons. It’s also not something I should probably be admitting on this here eponymous blog, as it is illegal.

Which is the real problem with ebooks. Ebooks today are still where mp3s were a few years ago. Conventional wisdom among people who pontificate about these things on the internet is that eventually publishers will cave just like music labels did. Music labels were so scared of Apple’s dominance that they decided to allow Amazon to distribute DRM-free mp3s just to create a competitor to the iTunes store. Is Amazon enough of a threat to publishers that they’ll make the same decision? Or will Amazon have enough of the market at that point that it won’t matter? Apple sells music in order to sell iPods (and now iPhones and iPads), but Amazon is doing the reverse: selling Kindles in order to sell ebooks. The fact that there’s a Kindle app on every mobile platform now is evidence of this. Which begs the question: why strike a deal with library lenders like this? Just to get market share, I assume.

Link: Disable Automatic Gain Control in Skype

Tue Apr 19 21:35:28 -0500 2011

Open up ~/Library/Application Support/Skype/shared.xml in a text editor, find the <VoiceEng> section, and add <AGC>0</AGC> and <EC>0</EC>. Like so:

<VoiceENG>
  <AGC>0</AGC>
  <EC>0</EC>
  [One or more <MicVolume>'s. Leave them alone.]
</VoiceEng>

The thread is from 2007, but it still works in Skype 5.

This feature is single-handedly responsible for the many noisy podcast interviewers you hear. See, when your channel is quiet, Skype yanks up the gain on your mic, meaning that every little sniffle, sip of coffee, or fan running two rooms away gets picked up while your guest is talking. And then, when you re-enter the conversation, your first few words are way too loud and distorted until Skype re-adjusts the gain.

But not anymore on my podcasts.

To manually adjust your mic gain, open up the “Audio MIDI Setup” application (in /Applications/Utilities) and select the Input tab for your mic.

Moving Home

Wed Apr 13 06:55:00 -0500 2011

I’ve decided to bring this blog back to life. It has my name on it after all.

When I switched this site to Jekyll awhile back, I never really took the time to set up a good workflow for posting, which is part of the reason I quit using it. After listening to a recent Build & Analyze discussing static site generators and Dropbox, I got inspired to try to rig something up here. Here’s what I’ve got:

My Jekyll files are stored in my Dropbox and synced with all the computers I use.
I have an iMac that doubles as a home web server, so I created a VirtualHost on it to serve content from my Jekyll destination directory. It’s behind a weird port and an htaccess password, so it’s basically a private mirror of my blog.
On this iMac, I set up a launchd file that sets up a WatchPaths on my _posts directory. Whenever I change anything in that directory, it runs Jekyll and rebuilds my site on that machine.
I have a simple shell script that rsync’s the iMac version of the site to the real web server.

So I a) write a post in Vim on any computer, b) as soon as I :w the file gets synced to my “development server” which I can then preview in a browser until I’m happy, and then c) I run !jekyll_deploy.sh from within Vim when I’m happy with the results.

The second step is the huge improvement. I don’t have to keep another Terminal window open running Jekyll on localhost. I don’t have to worry about having the full Ruby/Jekyll system set up on every computer I use. Because Dropbox is so fast, and because the preview site is being served using Apache rather than WEBrick, moving from writing to previewing is just as fast as if I’m running Jekyll on my local machine.

A few more Vim-specific things: if you like to save drafts of posts as I do, then you’ll end up using the YAML date: to set the post date. I modified jekyll.vim’s created: to use date: instead and then added this to my .vimrc:

    map <Leader>jd :%s/^date: \(.*\)$/\=strftime("date: %m\/%d\/%y %H\:%M\:%S")/<CR>

With this, I can just type \jd (I have “\” set as my Leader) and it refreshes the post date and time to the current date and time. (I thought about having it do this automatically on save, but I don’t necessarily want to update the post date (or URL) just for typos.) I also have jekyll.vim’s JekyllPost and JekyllList mapped to \jn and \jl respectively.

I’m also using this trick to fix Vim’s highlighting of the YAML front matter.

Black Country Communion

Tue Apr 12 09:41:11 -0500 2011

My brother turned me on to Black Country Communion a few days ago and I’ve been listening to it nonstop since. They have an interesting sound: unique, but at the same time clearly evoking many other bands, both modern—Audioslave and Kings X to my ears—and also classic: Zeppelin and Deep Purple, for instance (no surprises there: Glenn Hughes sings and Jason Bonham plays drums).

Joe Bonamassa is one of those guitarists I’ve read rave reviews about but have never really taken the time to check out. The little bits I have heard (on Pandora, I think) were more classic blues kind of stuff, which I like just fine but don’t really go out of my way to listen to. This is more heavy rock though, and I like it. He’s a versatile player, but the trait that stands out most to me is his Eric Johnson-style violin sound. In interviews Eric Johnson has always said he views this sound as a rip-off of Clapton’s live sound with Cream. I never got that because Eric Johnson doesn’t really play like Clapton (even when he’s playing more bluesy stuff, in my opinion). Bonamassa, however, can play like both EJ (“One Last Soul”, “Song of Yesterday”) and EC (“Sista Jane”), and now I get it. It’s a hard sound to pull off because it’s dark and bassy, but with a strong mid-range bite. Your guitar can end up sounding like an angry duck or a muddy mess. But, I digress. Let’s put it this way: it’s great fun to imagine Eric Johnson sitting in with a real rock band instead of rehashing the same New Agey solo crap year after year.

What I've Been Up To

Sun May 23 16:02:39 -0500 2010

Let’s see, it’s almost June and this is just my second blog post of 2010. Can that possibly be right? No. It’s not right. It’s just I’ve mostly been blogging on Tumblr instead of here.

About a year ago I was bored with WordPress and wanted to try something different. I ended up experimenting with two blogging platforms at the same time: Jekyll (this blog) and Tumblr. The two are almost complete opposites of one another:

Jekyll is a static site generator where your entire blog lives on your local machine and the interface is designed with programmers in mind.
Tumblr is a hosted web service designed to be the easiest way for anyone to blog.

After the novelty of Jekyll wore off, I found it was just more fun to post on Tumblr, despite (and perhaps because of) its limitations. And with the Tumlbr gem and my Tumblr backup script, I can pretty have the exact same writing environment as Jekyll (i.e. a text editor and local markdown files) when I want it for longer posts.

So I’m not quite sure what to do with this particular blog. I’ve considered transferring the posts here and the “jon.smajda.com” domain to Tumblr entirely, but I think I’ve decided against that for now. This site will probably continue as just my all-purpose homepage (and pre-2010 blog archive) and I’ll just continue to blog on Tumblr.

Let’s see, while I’m at it, what else has been going on?

After initially being shy about actually appearing on the Contexts Podcast, I’m now a cohost and appear in one role or another on about half of the episodes or so. Turns out I like hearing myself talk after all, and the podcast is more fun than I expected it would be.
So much fun is the Contexts Podcast, in fact, that we’ve actually started a second podcast, Sociology Improv, that is more of an informal, discussion, dare I say “talk radio” kind of thing. The direction is kind of open-ended and we’re just letting it develop as we go, but it’s also a lot of fun. Plus: all of the music on this podcast is original music created by yours truly.
I presented at the Politics of Open Source conference in Amherst, MA a few weeks ago. That was fun because it was the first time I’ve actually presented stuff from my dissertation. It was also cool because of the conference format: one room, one presenter at a time. I’ll also be presenting (on Monday, August 16 at 8:30am) at the ASAs in Atlanta. I’ll be in just one of hundreds of rooms there though.
We finally sold our damn house in Minneapolis. This is a gigantic weight off our shoulders. …Let’s just leave it at that, ok?

Post-Journal Academic Publishing

Thu Jan 07 14:57:39 -0600 2010

Everyone knows the publishing industry is made up of dinosaurs, but academic publishing is the Brontosaurus. Academic journals are slow, expensive, inaccessible and non-transparent. And there’s absolutely no reason they need to exist anymore.

Ditching the Dead Trees

Most clearly, there’s no technical reason for printed academic journals. And while traditional journals are increasingly realizing this and going online, they are still published by traditional academic presses who need to somehow pay for themselves, so they charge exorbitant prices to individuals and libraries, and keep their journals in closed formats such as DRM-protected PDF files.

This might be justified if publishers were necessary to produce a journal, but they’re not. Editors of academic journals basically work for free and a journal is lucky if they can afford to hire a part-time managing editor. Neither authors or reviewers are paid either. In other words, the content is produced, reviewed, edited and handed over, at very little cost, to publishers (and often the academic associations who sponsor the journal) who turn around and sell the journals back, at very high prices, to the very people producing the content in the first place.

So what’s the alternative? An obvious first step would be to ditch the publishers and go online only. The web is a vastly superior distribution platform for most academic work. You can search a web page, for example. Copy and paste quotations. Easily convert HTML to any other format you prefer for reading—whether that’s reading on your Kindle or printing out a hard copy on dead trees. (And while I’m at it, let’s ditch the PDF in favor of the much more lightweight and flexible HTML. Online-only journals are often still obsessed with looking like print journals, for some reason.)

And, of course, by going online you save the cost involved in printing and distributing paper copies. And with that the need for academic publishers.

There are many journals that are free and online already. This isn’t a new idea: see open access journals. The problem is that the most prestigious journals are not among them. Association sponsored journals are still in print because the associations need them to be in order to fund themselves. And the really big name journals are actually profitable and pay for most of the other journals, which lose money. As long as the most prestigious journals are print journals, free online journals won’t truly take off.

But it’s not so much the “print” part that’s the problem. If any of the big name journals went online-only tomorrow—and they’re looking into it—they would still be distributed through publishers who will want to lock down the distribution channels so they can continue to make money. Publishing online for traditional publishers is actually expensive because they need to recover the revenue they’re accustomed to getting from print editions, so they have to invest in all sorts of ugly, draconian DRM schemes and restrictive licensing practices.

So even if every new journal out there was online only, and a good proportion of the less profitable journals converted to online open access journals, you’d still have an elite core of journals keeping the journal ecosystem expensive and inaccessible. There are too many players—publishers and associations—whose well-being depend on these journals to exist.

Getting rid of journals

In the absence of a print product, why do we need journals at all? There are a bunch of reasons you need entities like journals, with editors and reviewers. But is there any reason—aside from the occasional themed “special issues”—where the output of the peer review and editorial process needs to be monthly or bimonthly collections of articles organized like a book, with volume, issue and page numbers and a table of contents, all squeezed into discrete “issues”?

Here’s an alternative system that I think would work much better:

Imagine an online publishing system—not unlike a blog—where when you’re ready to share your work, you simply publish it to a website. (Ideally this would even be built into the word processor/text editor you write in: imagine a single “publish” button.) Your document shows up on a website, configured specifically for easy reading: a simple layout perfect for reading on a variety of devices or for printing.

Every academic would publish their work to a website just like this: individuals or institutions could host their own instances of the software.

There would be some sort of common identity management (OpenID maybe) built in to the system. If you only want a few people (individuals or institutions) to have access to early drafts, there’s an easy way to specify that.

This system would have a versioning system built-in: each published version would be labeled and scrolling back through previous versions would be easy.

Some sort of commenting/discussion system would be built-in as well. Obviously.

In other words, it would do pretty much what WordPress or Drupal can now do out of the box, only have some specific tweaks and optimizations for academic work. (In fact, such a system could be implemented through a WordPress plugin and/or theme!)

Now imagine the following: you no longer submit manuscripts to journals. At least not like you do now. “Journals” are replaced with a system of organizations of some sort that manage the peer review process and lend their seal of approval to work they find of high quality. You grant them access to your article, and the “journal” coordinates finding expert reviewers for your work and gives you feedback right there on your website: including reviewer comments and including final judgments like “reject”, “revise and resubmit” or, of course, “accepted”. An accepted article would be a seal of approval, vouching for the quality of your work, not a promise to publish in some collection.

Some interesting potential consequences of a system like this:

Instead of keeping all of their work secret to respect the demands of publishers, academics could do all of their writing in public. Individual academics would be self-publishers and would own their own copyright on everything they do. “Journals” would no longer publish anything. (I’ll keep calling them journals though as I haven’t thought of a better name yet.) Journals would only do the one thing they do well: manage the peer review system and put their authority and reputations behind the work that they feel is the best in the field.
Without the constraints of printing paper issues of a limited size, there’d be the risk of certain journals accepting everything. Which is fine: this would diminish the reputation of these journals and the more selective journals who only certify the best articles would improve their reputations over time.
Since you’re no longer really submitting to a specific journal, would it be possible to have multiple journals “accept” the same article? Possibly. And that seems weird but has some cool possibilities as well: a lot of times really important, influential articles show up in smaller journals and are only read within a small subfield, though they may deserve a bigger audience. The ability of the more selective, generalist journals to add their seal of approval to articles that others have already accepted could be a good thing.
Would the peer review process be public as well? For example, would the fact that some journal rejected your article, and the comments from reviewers, be public (if still anonymous) as well? This could go either way, but I think this would be a good thing as well.
What about the fact that you can change stuff so easily online? Would people keep going back and correcting errors after publication? This is why a good versioning system is key: a journal would review and accept a particular revision of an article and that information would be included with their decision. (If you’re worried about the ability of authors to manipulate this, source code management software like git actually uses a SHA1 hash of the contents of the files to name the revision. This acts as an integrity check on the data in any given revision. Something like this could be used to ensure that any given revision of a document always refers to the same document.)

Now maybe, as I discussed in the first half of this post, just moving the traditional journals online would be good enough. But there’s a lot I like about this bolder idea. It could have the best of the web as a publishing platform—flexibility, accessibility and affordability—but maintain the quality control of the traditional journal system. There are probably some obvious shortcomings I haven’t thought of or have underestimated (Without the constraints of actually publishing something, would we just end up with a mess of thousands of journals allowing no one to find anything?), but it’s still a worthwhile thought experiment. Academics have such little control over our publishing system now. It seems to run on pure inertia, and, in my opinion, doesn’t seem to work in favor of the interests of most academics.