For those that have heard, it seems that Elsevier is getting its hands on one of the largest open source feeds in the social sciences. This, recall, is the same publisher that saw a defection of the Lingua editorial board. At any rate, it seems that Elsevier is at it again. They have just acquired SSRN (here, here and here). The
Elsevier claims that it will leave everything as it is. The reaction to this is, at best, wary and skeptical. At any rate, you might want to take a look and weigh in on the pros and cons.
To help the debate along, I found a pretty good defense of the value added that big publishers bring to the scholarly enterprise (see here). So, even if Elsevier does overcharge and make obscene profits from what is largely the counter work of others, maybe they do provide a useful service or two. Take a look.
This list reads a lot like the stuff Microsoft used to put out about total cost of ownership for open-source software and why their proprietary deals are better. Both evaluate the subject matter with respect to current practices and ignore that there is a completely different paradigm of how things can and should be done. And in both cases the keyword is community-level division of labor.
ReplyDeleteThere's little point in nitpicking the individual points on the list, so I'll just use a few illustrative ones: 39) XML generation, 43) search engine optimization, and 58) platform migration. None of these should ever need to be done by more than one person for the whole scientific field.
XML generation is part of the publishing tool chain; keeping the generator up-to-date is the responsibility of whoever is the maintainer of that part of the tool chain. So if papers are produced via, say, scientific markdown, this is the job of the developer team for scientific markdown. Not the authors, not the editors, not the technical staff (if there's any) but whatever programmer on the development team knows the ins and outs of XML and DTD standards.
This is also true for the specific issue of search engine optimization mentioned there. That Google now penalizes websites without a mobile-friendly version is something that should only worry the developers of whatever website toolchain you use, e.g. OJS. They have to create the theme, test and debug it, make it available to users, and also backport it to older stable versions that are still in productive use by journals. [Search rank optimization for the website in general isn't much of an issue: the user already knows that he wants to get to your journal, whether you're number 1, 2, or 3 on Google doesn't matter. Search rank optimizations for individual papers is also pointless: if the user knows the paper, it will pop up on page 1, if they do a general topic search, it is their scientific responsibility to look beyond page 1. And the decisive factor for page rank in Google scholar is links and citation count, neither one of which you can influence.]
Platform migration has two aspects: moving servers and updating the web frontend to a newer version. Moving servers should always be straight-forward because there is already an established procedure for that (clone your website, test functionality, then update the DNS entries, take the old server offline after DNS changes have percolated). Updating the web frontend might be painful right now, depending on the tool, but mostly because we have failed to divide the labor. Most servers are already virtualized, so journal frameworks should be distributed as virtual appliances. Then it is the responsibility of whoever designs these appliance to provide a clear upgrade path and point out cases where backwards compatibility had to be broken and the user must make some modifications by hand.
tldr: I'm sure hosting a journal is a lot of work if you roll your own code, setup and tools for everything. But you shouldn't. You should reuse whatever tools are already available, and share any modifications you make with the community. Many of the points in that list disappear in that case, and the remainder should be of no interest to not-for-profit entities (battling piracy, maintaining trademarks, protect credit card transactions, maintain e-commerce systems, conduct market research, customer data stores) or are just a symptom of how needlessly corporatized mainstream publishing has become (organizational education, reporting, publisher insurance policies, benchmarks).
That linked list is good. It's easy to overlook all of the (largely hidden to authors) steps that go into making a successful and sustainable undertaking. The LSA's journals are run by a non-profit organization and rely on open-source software, but they are still very expensive to run on a per-paper basis. And they are slow, which hurts careers. If you want highly qualified people to manage the process, reliably, then somebody's gotta pay them.
ReplyDeleteI'm not in general a fan of charging authors the sticker price of publishing. But I don't see any way that the system will become more efficient until authors are forced to see the true costs of the system that they acquiesce in.