Reading Time: 7 minutes

One of the many reasons I blog is because of the technology. Ever since I first learned html back in the late ’90s, I’ve been fascinated with web publishing. For many years I ran my own web server. Then, four or five years ago, I finally committed to having someone else host it. It takes care of the least interesting part – the hardware – and leaves me to tinker with the software. In the last couple of months. I’ve been going through some other similar transitions with my information tools.

[I’m trying something new. If you’d prefer to listen to this post, here’s me reading it. You can play it inline or right-click and download the audio file. If you have feedback, I’d love to know what you think.]

I posted recently about starting to use Mastodon. It’s exactly the sort of technology I love. It’s open source so people can build on it without permission. You can try it yourself or work with others. For a few moments, I looked into running my own instance.

But there’s a lot of responsibility. I stopped running my own mail server out of the security concerns. And I stopped running my own web server to ensure uptime. If it’s your own server or instance, no big deal. But if other people are relying on it or can be damaged by it, you’re taking on a responsibility that may grow over time.

A Mastodon post from a law-focused instance manager that says "Lawprofs, I'm aware that you're not currently able to see images and media from other instances in your feed. Our server is just about recovered from last night's crash, but it's still re-running some jobs that failed in the first hours of return to service (the good news is they're not failing anymore, just slow). I'll start attacking the images issue tomorrow if it hasn't resolved itself by then. In the meantime, you can right-click on  images in your browser to open them in a separate tab."
Screenshot of a Mastodon post by an instance administrator apologizing for their instance’s crash and outage.

Every time you use a piece of technology, you face this dilemma. What’s the cost of use? Even with open source that is free to acquire, what is the cost to run it? And when you use a free software – like your web browser, because your Microsoft Edge, Google Chrome, and Mozilla Firefox are all riding on open source technology that you probably didn’t pay for – you are just shifting the cost to someone else.

Every librarian should get this. It’s how our whole world works. “Libraries are a free and public good.” Free-to-you, perhaps. But not free. We pay taxes that may or may not get to the public libraries we support and use. We pay court filing fees that may or may not get to the courthouse law libraries we support and use. The people paying expect a free library, even if the people who control the money decide not to pass it along.

A discussion in which a Mastodon instance sysadmin discusses server stability and gets into a conversation about when it will be upgraded to the latest Mastodon software.
A screenshot of a Mastodon discussion about a server’s stability and when the server software will be updated to the latest version.

My personal decisions mirror what many libraries have done. Sometimes you can afford to run your own servers but you are paying for the hardware, internet bandwidth, and staff with skills. Or you outsource your servers, and pay for someone else’s hardware, internet bandwidth, and staff with skills. There’s a reason that cloud-based library catalogs are so popular.

I forget sometimes that some people may not view me as a hobbyist blogger. One thing that led me to shift to a hosted service was an email I got over a Christmas holiday. “Your web site is down, and we’re going to publish a link to it in a few days.” I’d moved from the point where only I cared to where someone else did! You think differently when you realize you have an audience.

And in the case of hosted instances, you may be taking on legal liability. I found this Twitter post really helpful, even though I would not have had anyone on my instance of Mastodon. It shows how you can do something with technology pretty easily and still have no idea about the legal consequences of it.

A tweet that says "Hey, US folks newly running Mastodon instances: do Future You a *huge* favor, mitigate your potential liability, and register with the copyright office and designate an agent to receive DMCA reports *right now*."
A screenshot of a tweet starting a thread that discusses legal liability for Mastodon instance owners in relation to US laws policing digital copyright and other topics

These are overt legal obligations when you run a web site that is publishing information by others. In my case, my biggest concerns are making sure that any resource I expose to the internet is secured and stable. It means that I need to keep it patched and the software up to date. It means that I need to make sure it’s hardened. And, at some point, this sort of maintenance loses its appeal for me.

Rethink on RSS Reading

One server I’ve been running for a long time is a Tiny Tiny RSS instance. Over the past decade, it has gone through a lot of changes. The software is open source but with a single developer who has steered its direction in ways that make it more difficult for me to keep up. I didn’t want to host a software app that might have security issues or become a danger to others.

This is not the first time that developer and app complexity caused me to run into a dead end. I ran into the same thing with PressBooks, an ebook publishing platform that was integrated with WordPress. I’d used the PressBooks plugin for WordPress to create some ebooks. Eventually it became something so complex that the devs removed the plugin and essentially said, use our platform or create your own technology stack.

For Tiny Tiny RSS, the turning point came when the developer decided to start shifting to Docker instances. For me to run a Docker container, I’d need to purchase more hosting. Up until now, I’ve been able to just run Tiny Tiny RSS as a typical PHP app alongside my other PHP apps – my photos with Piwigo, my web site analytics with Matomo, and my WordPress instances.

I had always had the idea of creating a public-facing RSS stream of things that I read and wanted to share. Sort of like sharing on a social site like Twitter or Mastodon but I would read within Tiny Tiny RSS and then use its features to create an aggregated feed for others. I think this idea has some great possibilities for communities – law libraries trying to engage with lawyers, for example – so long as there are ways to stream the RSS into their workflow. It could be Outlook RSS feeds or it could be through RSS capture on an intranet like SharePoint.

Or for those who partake, an RSS feed reader. #RIP Google Reader. I don’t recall now but Google Reader died about the same time, 2013, as I started using Tiny Tiny. Coincidence?

But the technical changes in Tiny Tiny RSS meant I was increasingly having to manually check for app updates. And then download them from Git, unzip and update them. And if anything broke, I’d have to fix it. It was a lot for an RSS feed reader.

Especially since there are plenty of alternatives. I played with some that I’d seen you all come to this site with: Old Reader, Feedly, Reeder, RSSOwl. I ended up landing on Feedly because it gave me the closest feel to my old Tiny Tiny instance and had an inoffensive Android app and was free.

I can’t say I’m a huge fan. Like so many news reading tools, it has a pro version that locks down functionality. For example, I follow a lot of Google Alerts as RSS feeds. This is a pro feature, as is following Twitter. Cost-shifting.

If you try to manually add a Google Alert in Feedly, it flips you to an upsell screen to buy a Pro account. In the end, I found that Feedly doesn’t know from its elbow about what you’re importing in your RSS feed file (OPML). As long as the Google Alerts are RSS feeds in your import file, Feedly will display them regardless of whether you have a Pro account or not.

Just take your Google Alerts and create your own OPML file. OPML files are just text and written in XML. Here’s an example for you to start with. Change the three items that have squared brackets – text, xmlUrL, and htmlUrl – and you’re good to go. Have more than one? Just repeat <outline type=”rss” …> line as many times as you have Alert URLs. Then go to the Feedly function to organize your feeds (Settings > Organize). Choose the Import OPML file button at the top right and import the text file you saved. (You may need to save it as something.opml but I’m not sure)

<?xml version="1.0" encoding="utf-8"?>
<opml version="1.0">
    <title>RSS Feed Export</title>
    <outline text="Google Alerts">
      <outline type="rss" text="[your Alert name]" xmlUrl="[your Alert's RSS URL from your Google Alert dashboard]" htmlUrl="[the same URL you used for the xmlURL]"/>

Do I feel bad for bypassing their Pro version? No, because I was able to import Alerts from my initial OPML without even realizing I was doing anything that wasn’t part of my free subscription. So they’re either not serious about it or they assume their customers who aren’t able to edit a text file think it’s worth paying for one-click support for Alerts.

The costs for me to follow information have dramatically fallen, even if I’ve also lost the technical tinkering aspect that I love so much. But it was a bit like having one foot on a boat gunwale and the other on the dock. As the boat slips away, you feel pulled in two directions and need to choose. For me, I chose the lower friction RSS feed reader route. All I need to do is periodically export my Feedly OPML file (login to Feedly, then go to ) and I can always port my feed list to any other reader.

Tiny Tiny RSS didn’t take a lot of my time, although it was always at the back of my brain, tickling away, when I read my feeds. Like a simmering pot that could boil over. And, with RSS feed readers, my needs are so simple that there’s nearly zero friction to move to another one if I decide Feedly isn’t for me (or I’m not for it).