For all of you who have enjoyed iPRES 2019 and want to reminisce, but also for all of you who couldn’t join us in Amsterdam, we want to share some iPRES 2019 memories. Take a look at these videos: Opening of iPRES 2019 Geert Lovink, Institute of Network Cultures. Sad by Design: Politics and Psychology of the Social Media Age. Michelle Caswell, University of California at Los Angeles. Whose Digital Preservation? Locating our standpoints to reallocate resources. Eliot Higgins, Bellingcat. Bellingcat and beyond. The future for Bellingcat and online open source investigation. Closing Session Also, have a look at the best moments of iPRES 2019 in the flickr photo gallery, on twitter and in the collaborative notes.

Centre for Research in the Arts, Social Sciences and Humanities

This study presents estimates of the global expenditure on article processing charges (APCs) paid to 14 publishers for open access (OA) between 2019 and 2025. APCs are charged for publishing in fully OA journals (gold) and making individual articles OA in subscription journals (hybrid), but how much is paid, and for which articles, is not publicly known. We therefore curated an open dataset of publicly listed APC prices from 14 academic publishers (ACS, CUP, De Gruyter, EDP, Elsevier, Frontiers, IEEE, IOP, MDPI, OUP, PLOS, Sage, Springer Nature, and Wiley) and combined it with counts of OA articles from OpenAlex. We estimate that \$15.08 billion (in 2025 USD) was spent globally on APCs between 2019 and 2025. Adjusted for inflation, annual spending quadrupled from \$0.9 billion in 2019 to \$3.7 billion in 2025, with >85% concentrated among a few large publishers. Hybrid OA fees exceed gold fees, and the median fee paid is higher than the median price listed for both. Our approach addresses major limitations in previous efforts to estimate APC spending, offering much-needed insight into an opaque aspect of scholarly publishing, especially as transformative agreements make it more challenging to understand the costs of publishing OA.

Have you ever wanted a simple website to publish your details and showcase your research? Good news! Z-Profile is a new tool aimed at helping researchers create their own sites, manage their online identity, and share their publications. View the Z-Profile demo site Z-Profile gets data from a specially-prepared Zotero collection, does of bit of processing, then generates a static website using Zola. The site includes biographical details and a list of your publications. Once your site is built, you can publish it using any web host, or for free through GitHub Pages. There’s a documentation site with full details, but creating your own Z-Profile site can be as simple as: 1. create a Zotero collection containing your publications and biographical details 2. go to the Z-Profile Site Builder and log on with Zotero – your site will be automatically built and packaged in a zip file 3. upload the contents of the zip file to the web host of your choice ## Why did I create Z-Profile? I was thinking about updating the guide to open access publishing for Australian historians that I created several years ago, and got a bit sidetracked… The problem was explaining the green open access (sometimes called self-archiving) provisions in publisher agreements that enable you to share certain versions of your publications. It’s fairly common for publishers to allow you to share the author accepted manuscript version (AAM) of your publication _immediately_ (ie without any embargo) on your ‘personal website’. Obviously I wanted to say – ‘just do it’. Put your AAM on the web and tell everyone where to find it. But it’s never that simple. The definition of a ‘personal website’ is fuzzy, perhaps intentionally, adding to the uncertainty around what’s permitted. And anyway, how many humanities researchers have the time, energy, and knowledge to create and maintain their own website? If I was going to encourage people to take advantage of this opportunity, I felt like I also needed to provide them with tools to make it easier. I also think it’s important for researchers to have online profiles that are not wholly dependent on their employer or a company that wants to exploit their data – to have ‘a domain of their own’ (in the words of the excellent folks at Reclaim Hosting). Of course, there are some other great options for building a research profile – in particular, I’d strongly suggest you set yourself up on Knowledge Commons. But having your own site, under your own domain, gives you extra control and flexibility. And so… Z-Profile. ## What is Z-Profile good for? Z-Profile is deliberately minimalist in design and function. It’s intended for people who want to share their research, but aren’t really interested in building websites. If you want more features, or more control, there are plenty of other tools around that could do the job. The Z-Profile home page displays your biographical details. You can include: * a portrait photo * a downloadable CV * a brief biographical note (that can include links to other sites) * a list of social media accounts or website links * a list of selected publications All the publications in your Zotero collection are automatically listed on a publications page. This is linked to an individual page for each publication, providing additional details, and links to alternative versions. Example of a publication page with the embedded PDF of an AAM version For example, perhaps you’ve just published an exhibition review in _Australian Historical Studies_ and want to share it online. Reviews aren’t covered by the ‘transformative agreements’ negotiated between Australian universities and Taylor & Francis (the journal’s publisher) that support open access publishing. However, under the publisher’s ‘self-archiving’ policy ‘you can post your Accepted Manuscript (AM) on your personal website at any point after publication of your article’. To share your review using Z-Profile, you’d just: * use Zotero to capture the publication details from the journal website * attach a PDF of your AAM to the item record in Zotero * tag the PDF with ‘aam’ to tell Z-Profile what it is Then, when you build your site with Z-Profile, it’ll create a page with the review, and embed the PDF for easy reading and download. ## What Z-Profile is not Z-Profile is not a repository. Even if you use it to share your publications, you should also upload your AAMs and preprints to an appropriate repository where they’ll be preserved and made available after any publisher-imposed embargoes. If you’re in a university, talk to the local librarians about your institutional repository. Otherwise there are general-purpose repositories like Knowledge Commons Works and Zenodo. You don’t have to limit yourself to a single option – remember LOCKSS (Lots Of Copies Keeps Stuff Safe)! ## Some technical details Z-Profile is really just some templates and a bit of data plumbing. Here are the main components: * a Python script to get the data from Zotero and prepare the contents of your site for processing by Zola * some basic templates for Zola to convert the data to HTML * a Python Flask app that uses OAuth to request an API key from Zotero, then runs the Python script and the Zola build process * a GitHub template repository that contains the Python script, the Zola templates, and a workflow to run the build process in a GitHub Action * there’s also a discussion board in GitHub where you can ask questions or suggest improvements ## Please share! Obviously I think Z-Profile could be useful, otherwise I wouldn’t have been obsessing about it for the last few weeks. But I don’t really know until it’s out there in the world. So please let me know if you make use of it. I’m also aware that the sort of people who follow my stuff are likely to have the skills and confidence to build their own websites from scratch, without the need for something like Z-Profile. As ever, it’s hard to get information to the people who would benefit most. So please share Z-Profile with your less technically minded colleagues.

Alt: Beaver Forgot: Damn It!

Protecting women from rape doesn't mean swooping with a sense of victory, it means starting a conversation that might leave you feeling like shit.

I spent Monday at the Software Heritage offices in Paris speaking at the CodeCommons plenary, and the slides are on GitHub. The talk was about connecting package identities to archived source code. Getting ready for it meant a couple of weeks poking at the SWH archive and its identifier scheme with a to-do list that kept growing, and I’ve ended up with a small pile of tools that are now feeding into ecosyste.ms, starting with the research software service. ### Software Heritage Software Heritage has been building a universal archive of source code since Inria launched the project in 2016. It crawls GitHub, GitLab, Bitbucket and a long tail of smaller forges, plus package registries and distro sources, and stores what it finds in one deduplicated Merkle DAG. As I write this that DAG holds about 30 billion source files, 23 billion directories and 6 billion commits from 445 million origins. A file that turns up in both an npm tarball and a Debian source package is stored once, addressed by the hash of its bytes, and the graph records every place it was seen. The Vault reconstructs any snapshot, commit or directory on request as a git bundle or tarball you can download, so retrieval is by content rather than by whichever URL the code was hosted at. ### SWHIDs Every object in the archive has a SoftWare Hash IDentifier of the form `swh:1:<type>:<sha1>`. The five types are `cnt` for a file’s bytes, `dir` for a directory tree, `rev` for a commit, `rel` for a tag and `snp` for a snapshot of a repository’s refs at one point in time. Optional qualifiers after a semicolon pin an origin URL, a visit, a path inside a directory or a line range inside a file. Version 1.2 of the spec was published as ISO/IEC 18670 last year, the first ISO standard for intrinsic software identifiers. A SWHID is intrinsic, computed from the bytes with no registry and no issuing authority, and because the hashes are git’s own object hashes any git checkout on your disk is already full of valid SWHIDs whether or not Software Heritage has crawled it yet. A purl like `pkg:pypi/[email protected]` is at a different corner of Zooko’s triangle: a human can read it and it’s unique within PyPI’s namespace, but resolving it to actual bytes depends on PyPI still being there to serve that release. I spend a lot of time in ecosyste.ms holding both kinds of identifier for the same software, and that mapping was the subject of the CodeCommons talk. ### swh-git The most direct way I’ve found to get code back out is swh-git, a git remote helper that adds an `swh::` transport. With `git-remote-swh` on your `PATH` you can clone by origin URL or by SWHID: git clone swh::github.com/octocat/Hello-World git clone swh::swh:1:snp:f72e9d06dd0e58236a34328f094ca894a809f230 The first form resolves to the origin’s most recent archived snapshot, and the second pins a specific one and produces the same bytes on every run. Behind the transport, the helper requests a git-bare bundle from the Vault, polls while it’s prepared (which can take several minutes for a large repository the first time), downloads it into your user cache directory, and serves the clone from there with `git upload-pack`. Fetch, `ls-remote` and shallow clones all work against the cached bundle, and push is refused since the archive is append-only from the crawler side. There’s also an HTTP proxy mode for tooling that expects a plain URL rather than a custom transport, so `git clone http://127.0.0.1:8080/github.com/octocat/Hello-World.git` does the same thing through `git http-backend`. I built this for the recovery case, where an origin URL now 404s or the forge it was on has shut down, and `git clone swh::<the old url>` gets you back to a working repository with full history and tags. The helper also accepts `rev`, `rel` and `dir` identifiers, so a directory SWHID from a paper citation or an SBOM component becomes a checkout in the same way. ### Computing SWHIDs Since a SWHID is derived from content, you can compute one anywhere you have the bytes, and I wanted that in the two languages I use most. The swhid gem covers Ruby with parsing, qualifiers and generation for all five object types, and it’s what the ecosyste.ms services use. swhid-go does the same in Go with a CLI on top and SHA-1 collision detection built in. Both are wired into the upstream conformance test suite that the SWHID working group maintains, so they’re checked against the reference vectors alongside the Python and Rust implementations. Compiling swhid-go to WebAssembly gives you swhid-wasm, a browser page that fetches a package by name from npm, PyPI, crates.io, RubyGems or pub.dev, or takes a local archive you drop onto it, then unpacks and hashes the whole tree client-side. You get content and directory SWHIDs for every file, executable bits, symlinks and duplicate detection, and the package bytes stay on your machine. Once the tree is hashed the page batch-posts the identifiers to the archive’s `/api/1/known/` endpoint to colour in which ones are already preserved, and there’s a button to submit the package’s public URL to Software Heritage for archival. Early builds of the wasm page needed a same-origin relay for that lookup, because the browser’s CORS preflight for a JSON `POST` was reaching the Anubis bot-protection layer in front of the archive and getting an HTML challenge back instead of CORS headers. I reported it and the SWH team have since adjusted the Anubis configuration so preflights pass through, and the page can now call the archive directly, though by that point the identifiers are already computed and the lookup itself is optional. ### Web API All of the above ends up calling `archive.softwareheritage.org/api/1`, which SWH document thoroughly in prose. There’s no machine-readable spec yet, though it’s something the team are interested in, so swh-openapi is my stopgap, generating an OpenAPI description from the same docstring data the published reference is built from. swh-go is a Go client generated from that with pagination, auth and rate-limit handling written by hand, and both should be retired once there’s an official spec. ### Critical package coverage With a client in hand I ran a coverage check, swh-critical, over the roughly 9,800 packages in the packages.ecosyste.ms critical set and their 7,000-odd source repositories on 23 and 24 September. Of those repositories, 71.3% had their current default-branch commit already in the archive, and 89.9% of matched release tags were present as revisions. Among the repositories whose current commit was missing, 95.1% still had an older snapshot once I checked the former URLs ecosyste.ms records across renames as well as the current one. The 46 hardest cases in the audit had no snapshot at any URL I tried and no matching release objects either, and drilling into those with full clones and tree hashes from the published package tarballs still turned up archived content for every one. Across the whole audit the pattern was older history already in the archive with only recent commits missing. I think ecosyste.ms can be most useful to Software Heritage as a partner on that last part, since the archive tracks over 445 million origins, far more than the crawler can revisit at a uniform cadence, while ecosyste.ms has dependent counts, download numbers and a criticality score for each package that give a decent signal for which repositories matter most to keep fresh. Feeding that back as a ranked stream of Save Code Now requests means the crawler’s next visit goes to the source of something with a hundred thousand dependents rather than an abandoned fork. ### science.ecosyste.ms The first place that feedback loop is running in production is science.ecosyste.ms, the ecosyste.ms service that tracks research software. For each project with a high enough science score, a background job clones the repository, computes revision and directory SWHIDs with the Ruby gem, and posts them in batches to `/api/1/known/`. Projects with objects missing from the archive get their origin submitted through Save Code Now, another job polls the visit until it completes, and any SWHID newly known after our request is recorded as a confirmed contribution. The stats page rolls those up every six hours with a JSON API alongside, and individual project pages now show SWHIDs next to the DOIs and citation metadata they already had. Research software was the right place to start because that community already cares about persistent identifiers and long-term reproducibility. ### packages.ecosyste.ms The next step is doing the same for package versions on packages.ecosyste.ms, which means computing directory SWHIDs for published tarballs as well as git checkouts and storing the purl-to-SWHID mapping as a first-class field. At that point an SBOM component like `pkg:npm/[email protected]` resolves through ecosyste.ms to a `swh:1:dir:` you can verify against the tarball you downloaded and fetch from the archive independently of npm. It also turns the one-off swh-critical audit into a rolling measurement, with coverage tracked per registry and new gaps fed back through the same Save Code Now route. ### Scanning the archive The scanners I’ve been building under git-pkgs can also treat the archive as a corpus rather than a backup, since they already run against any checkout. manifests parses package-manager manifest and lockfiles across ecosystems, licenses does fast SPDX detection against the ScanCode rule corpus, and brief reports a project’s whole toolchain and conventions as structured JSON. With swh-git in front of them the checkout comes from the archive by SWHID instead of a live forge, and any of their outputs anchored to a `swh:1:rev:` is reproducible by anyone with the same identifier. Longer term I’d like to try running these against the SWH graph dataset export directly rather than one Vault checkout at a time, which would make questions about lockfile adoption or license drift across whole registries answerable from preserved source rather than whatever happens to still be online. Software Heritage has already built the archive and standardised the identifier; what I’ve been doing is plumbing to reach it from the package-management side and to point ecosyste.ms data at the repositories where another crawl would help most. All of it is MIT or Apache-2.0 licensed, and I’d be very happy to see any of it picked up or replaced by something better.