This is the text and slides from my talk at Everything Open 2026. It's not exactly what I said, partially because I slightly misjudged my timing and had to skip through a section towards the end, but mostly it is as delivered. Video of this talk will be available at some point, when the conference volunteer AV team get to it.

Getting situated - About me

Hello!

Yes, my name is indeed Hugh Rundle. No relation to Guy Rundle or the Rundle Mall. Also no relation to Hugh Jackman or Hugh Grant, though it's nice of you to notice the resemblance.

I want to acknowledge we're on unceded Ngunnawal and Ngambri land today. I'll be talking this morning about maintaining knowledge systems, making the relationships between things explicit, and maintaining autonomous but connected communities. Nobody in human history has done these things better than the Ngunnawal and Ngambri people here in Canberra, the Wurundjeri where I live in Naarm/Melbourne, or the palawa people of lutruwita/Tasmania where I was born.

I've been working as a librarian for 25 years. I lead a team at La Trobe University that maintains library technology systems with a focus on metadata, collection discovery and maintaining interoperability between many internal and external systems. My work in relation to library metadata is only on the discovery side. I'm not a trained cataloguer and I am not involved in the creation of library metadata.

My hobbies include doing things on computers, and reading books, which is basically what this talk is about.

Getting situated - about you

Who do we have in the room today?

• librarians?
• other GLAM people?
• developers/programmers?
• system administrators or IT people?
• FOSS project maintainers?

Where we're going today

So today I'm going to tell you a bit about BookWyrm. Then a little about how I became a maintainer. We'll explore some examples of how it has helped me think differently about librarianship, the nature of expertise, and then how you can get your professional mojo back if you're feeling burned out, and finally some lessons for maintainers and professionals.

Let's go.

A caveat about self-exploitation

Before I go any further - a caveat.

I am not advocating for workers to provide free labour for projects that their employers should be funding. If you're a worker and your workplace benefits from an open source software project you contribute to, they should be paying you to work on the project.

What is BookWyrm?

Ok, let's talk about BookWyrm! BookWyrm is a social reading application.

Users can track their reading, share quotes, reviews and comments about books, follow other users to read their statuses, and publish all of this to the fediverse via the ActivityPub standard used by software like Mastodon, Pixelfed, Pleroma, and Lemmy.

I'm really proud of BookWyrm and I think you should absolutely check it out, sign up, and contribute to the project. But today I'm not going to give you a long rundown of the features of BookWyrm. What we'll be exploring is how working on BookWyrm has helped me to think about library systems and standards, and my professional identity, in a different way.

It must be nice to read books all day

Library science is a large field with many potential aspects to be interested in and learn about.

An individual librarian will be interested in a subset of that to become expert in.

But the thing about being a librarian is that you can't really do it independently. You might be the only librarian working in your library, but the idea of a self-employed or sole-trading librarian doesn't make any sense. There's always a broader organisational context.

Librarianship can be slow to change, and our standards and practices are very sticky. Usually someone else is determining your priorities, and setting the schedule - whether than means setting arbitrary deadlines, or having your work locked in seemingly endless rounds of committee meetings.

So this is why professional education has the twin problems of "Why did they bother teaching me that?", and "I didn't learn this in Library School". Librarians can easily fall into the trap of feeling the need to defend our expertise when we feel it's not being recognised, whilst simultaneously worrying that we don't actually have any expertise worth defending.

We're stuck in the machine, with little control over our day to day work. Unable to give or receive meaningful feedback. Prevented from developing our professional identity unless it serves the direct interests of our employer. Dr Karl here would say we're suffering from an acute case of "alienated labour".

Being a maintainer

So I guess I was thinking about all of this in 2021 (what a time huh). Anyway, I discovered BookWyrm somehow. I created an account and immediately realised there was a feature I wanted that was missing - the ability to co-edit a book list with one or more other friends. I thought to myself, "I don't know anything about Django or ActivityPub, and I've never seen this codebase. But I know how to write a bit of Python code - how hard can it be?"

It turned out to be a little bit difficult, but just the right amount. So that's how I started, but how did I "accidentally" become a maintainer?

Essentially I became a maintainer on the BookWyrm by continuing to hang around, fixing bugs, making suggestions, adding new features, and eventually having the courage to review other people's code, and then I got permission to merge pull requests and realised "oh, I'm a FOSS maintainer now". So let's briefly talk about what that involves.

In BookWyrm more or less everyone is a "contributor" - you don't have to write any code. Bug reports are welcomed, even when people sometimes express themselves poorly. Feature requests are considered and left open in case someone wants to take them on.

This is basically the section of the talk where I shout out and express big love for Mouse Reeve, the originator of the whole BookWyrm project. Mouse has made a big effort to develop a strong culture of care, support, and positivity in the BookWyrm project. I've learned a lot from Mouse about how to be an open source project maintainer.

I've learned how to give code review feedback that is encouraging and clear even when identifying a problem that blocks us from merging. About how to gently approach contributors who are perhaps not being their best selves when they write a frustrated bug report, or an angry reply.

I've also learned by example that it's not just ok but is actively helpful to admit when you don't know the best approach for a problem, or you can't remember why you wrote some code that way two years ago.

I cannot emphasise strongly enough how important this community management and culture building has been. If you want an open source project to succeed, building a positive and welcoming culture is far more important than any technical work you will ever do.

So I got involved because I had a specific thing I wanted to achieve, I would have to learn a bit in order to do it but it was adjacent to my existing knowledge, and I was made to feel welcome and supported. We'll come back to these things shortly, but first I want to give a couple of examples of some specific things that made me think differently about libraries.

Network topologies: resilience needs options

I initially thought what I wanted to talk about today would be linked data. This has been the hot new upcoming thing in libraries for over a decade, despite almost no library software systems actually using it.

But eventually I realised that what I really found interesting is network topologies, and how different assumptions about how data should flow and be managed within a network can make big differences to who gets to assert things.

A great deal of book metadata is created by librarians working in individual libraries. And the way a record enters a given library catalogue is usually via what we call "copy cataloguing". The basic facts of any book are generally agreed, so instead of 500 libraries all manually creating their own record from scratch, the first one to get a copy will make a record, and then everyone shares that.

In libraries, data typically moves in a hub-and-spoke model. For that record to enter another library's catalogue, typically it will come in via one of two methods:

1. A "union catalogue" - typically a national library
2. A "knowledgebase" - which brings together and normalises multiple types of library resources including books, ebooks, academic journals, journal articles, and collections/packages. Typically these are commercial vendors

Either way, what we tend to have is libraries or publishers sending metadata in to a small number of primary nodes, and each of those primary nodes makes decisions about how to merge duplicates to create a single master record that is the most complete and accurate.

In BookWyrm, we see a different conceptual model.

BookWyrm essentially uses a peer-to-peer data model, but with some additional data sources like Open Library and Inventaire that aren't considered peers.

Instead of relying on half a dozen data sources considered to be authoritative, BookWyrm trusts anything it can find data from and then progressively enhances local records as more data becomes available. We do this by recording a bunch of unique identifiers, and adding details if we have a local match on an identifier but we're missing other data.

Title: An Example Book
Author: Sam Smith
SFID: SF1234
OLID: OL9876

As an example of this, let's say we originally import a record from Open Library. Open Library is very hit and miss with its metadata and frequently has duplicate records. So maybe our new record has an OpenLibrary ID, and maybe a Science Fiction Database ID, but no ISBN or any other identifier.

Later, someone we're following from another BookWyrm instance posts a status saying they have started reading our book, which sends a linked data object to our instance. The data in their instance came from Inventaire.

This record doesn't have an Open Library identifier but it does have an SFDB identifer, so there's something to match the two records to each other.

Title: An Example Book
Author: Sam Smith
WikiData: Q23456
SFID: SF1234 # <-- match and merge 
ISBN:978-0123-4567-89
LibraryThing: LT9999
Subjects:
  - Software
  - Network Design

When our instance sees this post, it can see that our friend is referring to the same book we have from OpenLibrary. It updates our local record with the ISBN, LibraryThing ID, and subjects. So that's cool, right?

Now, there are good reasons that libraries don't just automatically update records when they receive a POST request from another catalogue.

But in terms of network topology, why can't libraries pull records from anywhere and make decisions – whether automated or via human checks – about what to merge and what to keep?

Well the answer is that we absolutely could. In fact there are library data transfer standards for this - z39.50, which was later improved by SRU/SRW. The whole point of these is to pass data around a peer-to-peer network. But when we use these standards, it's usually to pull in records from the same big central nodes.

The centralised hub-and-spoke model is ultimately a management decision, not based on any iron laws of bibliographic data. If we decide to trust a central node to make most of the decisions for us, we can make fewer decisions ourselves, with less local expertise. That is, we don't have to employ so many highly qualified cataloguers. This is obviously cheaper, very efficient, and often it's uncontroversial for basic metadata like title and author.

But it's not without problems, one of which is that it tends to de-skill the profession, which means if we want to change the model later, we may no longer have the expertise or vision required when our situation changes. Like, maybe in future we might not trust all those central nodes quite so much.

Like many other people, English-speaking librarians got some hard lessons in geopolitics last year. With many of the biggest hubs in the hub-and-spoke model being American libraries or corporations, this ...is a problem. But it's not insurmountable.

Working on BookWyrm has helped clarify for me that our systems and data models are not set in stone. Networks are ultimately built on the questions of who do you trust, and what do you trust them to say. Network resilience requires not just a decentralised model, but the ability to decentralise judgements about what data we trust, why, and what action we're going to take as a consequence.

BookWyrm currently trusts everyone, although it is possible to disable connections from a certain node.

Libraries currently trust a small number of central nodes - three of the biggest being the Library of Congress, OCLC (based in the United States), and Ex Libris (based in Israel).

Each of these two data topologies and trust graphs has strengths and weaknesses, but the very fact they are different has been useful to my ability to think about both of them.

How to be an expert

Initially when I started helping out with BookWyrm I was very reluctant to assert any expertise at all. I was very self-conscious about my coding abilities, and had a lot to learn both about Django and the details of ActivityPub. And of course, the problem we talked about at the top: it's pretty easy to wonder whether you know anything worthwhile from librarianship when you're in my area of work.

So, how do you know you're an expert?

I finally got over myself when I started to see a few recurring conversations in the BookWyrm issues, and realised I was confused about them. Why, I wondered, is everyone talking about this well-known issue as if nobody has tried to solve it before?

That's when I realised I was thinking several moves ahead of everyone else. Not because I'm a genius, but because I had expertise in the subject matter.

I think there are two main give-aways that maybe you're an expert on something even if you don't think you are. These are both about understanding problems rather than about having the answers.

It's not that simple

The first I call "It's not that simple". In this first case, normal people think something is much simpler than it actually is.

For example, what are the defining features of a book series? In BookWyrm we currently have a model for series that boils down to this:

1. Some books have series
2. Every series has an order
3. Two books with the same series name that share an author are in the same series

This is a pretty reasonable heuristic if you're thinking about most fiction series. But what if it's one of those series where the original author has died and their child has continued to write more in the series, like John and Christopher Tolkien? What if it's something like a TV tie-in fiction series where some of the books are by the same author and some aren't? What if it's a non-fiction series where the authors for every book are different? What if it's a sub-series within a series, like the Rincewind books that are a subseries within Terry Pratchett's Discworld series? What if there's no particular order that the books are expected to be read in, or there are multiple accepted orders?

It's not as straightforward as you might initially think.

So I have a merge request waiting where I created a new model for Series that can deal with all these different scenarios. You might notice that it took me four years to summon the courage to assert that I knew what I was talking about there.

You're struggling because it's really hard

Our second indicator that you might be an expert I call "You're struggling because it's really hard".

In this scenario, the expert is watching people get frustrated with themselves because the non-experts think the solution should be simple, and they don't realise that experts struggle with it too.

BookWyrm is a decentralised, multi-lingual, multi-script environment with incompatible legacy data and very loose controls on data input. Show that to a cataloguing or discovery specialist in a library and they will quickly end up with a migraine or worse.

There are currently a few open requests on the project that essentially boil down to people wanting reliable authority control that can automatically display data in the language and script an individual user prefers. Now it's not that I think this is impossible, and certainly not that I don't think it's desirable. I think it's a very interesting problem. But it's also really, really hard because it's a bunch of difficult problems inside each other. Part of my role as a maintainer is to explain that it's not that we don't care about this problem, it's just going to take a while to work out some possible solutions, and we should be careful that we don't make it worse with a quick fix.

Now, I could make a joke here about Falsehoods Programmers Believe About Bibliographic Metadata. But that would be unhelpful and snarky, and that's not the kind of talk I want to give today.

You've heard me this morning talking about how BookWyrm generally works as a project where contributors with different expertise work together to solve problems. It's not a competition: to be a successful contributor you need to think like an orchestra musician, rather than like a rockstar.

Getting your mojo back with a mental health SPA

So that's my experience with BookWyrm. Now I want to tie this all together. How has working on BookWyrm helped me to get my professional mojo back, and what might we learn from that?

I think the keys here are

• Stretch goals (S)
• Shared Purpose, (P) and
• Agency (A)

Stretch: work on things that are just a bit out of your current ability/knowledge

You're probably having PTSD right now remembering all the times your boss asked for "stretch goal" in your performance plan. What I want to talk about here has nothing to do with increasing productivity or hitting arbitrary targets. You're likely to be in a professional funk if your capabilities are not a good match for your responsibilities and goals. That can go wrong in both directions.

Humans get bored when we're entirely within our comfort zone. If you can do everything asked of you without really thinking about it or putting in any effort, you're going to have very low engagement. If your job is merely something you do to pay your bills and you're able to compartmentalise your life, that's probably not a problem. If you're like most people, however, what you work on – whether professionally or voluntarily – is part of your identity. When our work is too easy, ironically we start to feel that we're not really valued. Brains, huh.

On the other hand, if your work is too far outside your area of knowledge and skills, you have a different problem. You feel stressed. You feel like it's impossible, that you're too stupid. Maybe you don't actually know anything at all. Maybe you should give up this job and go live in the forest.

So if you want to get out of your funk, you need to be working on something in-between these two states. Where it's just a bit outside your experience and knowledge. You'll get to learn something new, but it's entirely achievable because you can build on what you alread know. This is basically what educators call scaffolded learning.

Purpose: solve problems people care about

After you've nailed the stretch goals, we need to think about purpose. What is the purpose of your work?

I think not being able to satisfactorily answer that question is the biggest cause of professional burnout. But why? It's primarily because at some point many of us wake up and realise that what our organisations say their purpose is doesn't match what they seem to prioritise.

Stafford Beer, one of the founding theorists of cybernetics and systems theory, famously stated that "The purpose of a system is what it does". It's when we are commited to the stated purpose of an organisation but the organisation is actually doing something different, that we become dissolutioned and burned out.

For example, I work in a university. Normal people think that the purpose of a university is to research new knowledge and educate the next generation.

What universities actually do, however, is publish papers nobody reads in journals nobody can afford, in order to make their numbers go up in ranking systems nobody understands, so they can attract research funding and student enrollments so they can pay people to publish more academic papers.

So what about BookWyrm? The JoinBookWyrm page says:

BookWyrm is a social network for tracking your reading, talking about books, writing reviews, and discovering what to read next.

Ok but what does the BookWyrm project do? Well, it ..talks about books, and how to connect people to those books and to each other.

Notice what neither of these statements focuses on. The purpose is not to build software. It's not dedicated to be "An ethical alternative to XYZ". It's a project to help people talk to each other about books.

So first of all, our stated purpose and what we do are aligned. This is super dooper important.

Secondly, it defines a clear inside and outside. If you're interested in talking about books and helping other people talk to each other about books, you're in. If you want to talk about something else, we don't do that here.

Lastly, inside that purpose, our options are quite open.

Here's where I realised something about libraries, specifically in terms of how our systems are designed, built, and managed. Very broadly, we can sort people into three roughly analagous groups within each of libraries and BookWyrm:

In libraries, there is pretty much never any communication directly between developers and users. Everything is mediated through librarians. There are a lot of reasons for this, but in essence it's because usually there is a vendor relationship between developers and librarians, and separately a service or institutional relationship between librarians and users.

In the BookWyrm project, an individual person could be a developer, and an instance admin, and a user - like Mouse. In my own case, I'm a developer and a user but not an admin. In any case, the point is that everyone in this chain is considered a first-class contributor. Bug reports and enhancement ideas directly from users are encouraged and genuinely welcomed.

It's the enhancement requests that really made me reflect on what can be missing in library software conversations. Take this request, for example:

Now it's not that library catalogues don't sometimes include information about things like "mood", "style", or the "features" of a story. But this kind of information usually comes from external plugins and third-party services, and there aren't really any standard definitions. One will look in vain for concepts like "atmosphere" or "how it will make you feel" in standard library metadata schemas.

Now, this is probably because these are really subjective and hard to pin down. But when I saw this request come through it made me think about what is and is not considered worth recording in library catalogues, and what that says about how we decide such things.

What else are we missing when we isolate our conversations with the people using our libraries from the conversations with people creating the data standards and writing the software that drives discovery?

Agency: work at your own pace on things you're interested in

So we've talked about the importance of stretch goals, and how to ensure you've aligned your purpose. Finally, I want to talk about agency. There's two aspects here that I think are important to how BookWyrm operates.

The first is not all that unusual in any FOSS project: code contributors get to choose what they work on. This is, of course, quite different to a professional workplace. I have to work on all sorts of things in my paid work that I am not particularly interested in. FOSS is great for letting people follow their interests.

But there's another aspect that is really important, in my view, and that is about time.

One of the most corrosive things I have seen in FOSS development is the phenomenon of "stale bots". These are scripts that automatically close issues, and sometimes pull requests, after a certain amount of inactivity. The intention here is to provide clarity and close off things considered no longer relevant. But this is really just corporatising your project. It's the equivalent of a clean desk policy, where everything has to be tidied away or thrown in the rubbish regardless of any context or usefulness.

The BookWyrm project has a very relaxed attitude to time. If someone logs a bug where we're not sure whether it's been fixed, or an enhancement request nobody has had time to work on, we just leave it open until someone can pick it up. If a new feature takes months to implement, so be it. If you sent in a pull request for review, we'll try to get to it soon. But, you know, maybe all the maintainers are busy that week.

Allowing things to take as long as they take is, in my opinion, vital to the health of open source software development. If someone takes six months to finish their pull request, so be it. Maybe they've stretched themselves a bit too far and they need to develop their understanding further before finishing. Maybe they had a life crisis in the middle of it. Maybe their work life got busy. Maybe they have a baby. Maybe their country got invaded.

If you're tempted to start creating rules about how long things are allowed to sit idle, or are hassling someone to finish a new feature, consider where that impatience is coming from. Are you responding to the non-existent venture capitalists whispering in your ear about 10x growth?

The whole point of hobby software projects is that it's not supposed to feel like work.

Isn't this just "scratching your own itch"?

FOSS Old Timers might be thinking some of this sounds familar. You might be thinking "Hey, isn't this just Eric Raymond's idea that people should 'scratch their own itch'?" I would argue that it is not quite the same, and that the differences are important.

The key aspect to all of this is that you're working as part of a community. You can more easily stretch your skills and knowledge with a supportive group around you, chipping in with their own knowedge. A shared purpose keeps you on track and feels good. Feeling that you have been offered agency is nicer than feeling like nobody cares either way about what you are doing.

Now you could have Agency to Stretch yourself towards a Purpose without anyone else being involved. But if you're looking to recover from or avoid professional burnout, you'll have a lot more success if you're doing something that other people care about in relation to a shared purpose. That is, you're scratching their itch.

Most people get more satisfaction from giving gifts than receiving them.

Lessons Learned

Ok, so let's wrap this up. What are these "insights" that I promised you?

Maintainers

Does your project allow contributors to relax in the SPA? That is:

• are you welcoming to contributors wanting to stretch themselves?
• does your project have a clearly state and shared purpose? Are you sure that the stated purpose matches what is really happening?
• do contributors have agency to work at their own pace with their own priorities? Have you created or implied a false sense of urgency? Does your project allow for multiple priorities (e.g. maintenance and new features) to be worked on separately, or is everything tightly coupled?

This is certainly not a new insight, but if you're a FOSS project maintainer then your primary job is to lead and foster the community, not to ship code.

Professionals

• if you're looking for a way to respark your professional passion, consider a project that's a bit sideways from your professional expertise
• never describe yourself as "non-technical" - you have technical expertise in something. There's a reason library cataloguers traditionally work in departments called "Technical Services":

Librarians (and maintainers)

Finally something for maintainers and librarians to think about. Librarians have skills that could be useful in any FOSS software project.

We're trained in "the reference interview" technique to work out what people actually want as opposed to what they asked. Librarians who do a lot of reference work are going to be great at triaging and clarifying bug reports and feature requests.

We're also trained in classifying things and organising information. Library cataloguers are going to be great at organising and labeling your bug tracker so things can easily be found, and you don't get so many duplicates.

Now go join BookWyrm. I'll see you there.