IndieWeb principles and I

IndieWeb is a community of people who want to build web that is independent of large corporate players and in the hands of the people building their own websites and tools. The website describes this as

The IndieWeb is a people-focused alternative to the “corporate web”. — We are a community of independent and personal websites based on the principle of: owning your domain and using it as your primary online identity, publishing on your own site first (optionally elsewhere), and owning your content.

Introduction

IndieWeb as a community is a rather developer focused group and as such, is not the only way to participate in the non-corporate web. For a long time, I didn’t feel particularly aligned with the IndieWeb (with capital I and W) movement.

Despite being a developer myself, I felt that some of the ideas touted in the movement were dismissive of non-developers but later I’ve started to feel that my initial encounters with the community may not have been representative of the whole.

To me, strict labels are not particularly interesting. Whether you call it IndieWeb, indie web, personal web, small web, cozy web or anything else, I’m more interested in the ideas that people have about the movement.

Rather than being a binary yes / no categorisation, IndieWeb is a spectrum of many things where you can decide for yourself which one you care about and how much. There’s no point in evaluating anyone’s rate of participation or pointing fingers to “but you post on social media so you’re not really indie”.

Principles of IndieWeb

Currently, the community wiki lists 11 principles of IndieWeb and some of them resonate stronger with me than the others so I wanted to write about those principles and how they relate to my website(s) and participation in the personal web.

1. Own your data

First principle is ownership of data. Especially after Facebook gained massive marketshare in the web, more and more people, communities, companies and organisations moved from having their own website to having a Facebook page.

It felt like a good and easy move at the time and I found myself doing the same. It only really hit me years later when I decided to make some notes about my past projects that everything really was in Facebook and completely controlled by them. Events, photos, posts, discussions — everything.

The realisation shook me. It was at that moment, when I realised I needed to first capture all that data to somewhere where I would have full control of them and focus on building the future stuff on ground we controlled — ie. our own websites. I still utilise social media and chat platforms like Slack and Discord to offer places for people to follow and participate. I focus on making sure that nobody is required to join those platforms though by providing all the information on an open website as well.

In my personal life in web, I had already been much more focused on having my own website throughout this time but the realisation did affect my approach to building this site as well. One of the things I started paying more attention was the third party dependencies I had with my stuff. I wanted to make sure that even if a tool, service or platform I use to build my website goes out of business or deletes my account or data, I can continue to build my site and keep it running and can replace it with a new one without losing anything important.

If you’re using your website to build any kind of brand, following or business, Chris Zukowski has a great article Don’t build your kingdom in other people’s kingdoms. In it, Chris writes about how important it is to have your own place where you can point people to when they are interested in what you’re building. Social media platforms can be good places to widen the reach but eventually, you don’t want to leave access to your followership, readership or customers to be controlled by a third party.

One approach to this is called POSSE (Publish on your own site, syndicate elsewhere). The idea is to post first on your own site and then post links to that to other platforms. I do this with my blog posts and digital garden notes but not with all of my social media posts like some people do. This way, people can read your writing, videos, art and whatever you publish regardless of which (if any) social media platforms they are on and if your social posts are deleted or your account limited, you and your readers don’t lose access to them.

2. Use and publish visible data for humans first, machines second

IndieWeb originated from a community of developers so a lot of the discussion in the community has to do with technical solutions, protocols, markup formats and what not.

All of that is secondary in importance though. We write and make art for other people first and foremost and it’s important to keep that in mind. All sorts of information about publish/edit dates, authors and so on should be written for humans first. If you want to make stuff integrate better with other technical tools, that can be done as a secondary thing.

Usage of microformats can help tools like webmentions and developers who use them to get easier access to right data to enrich the presentation.

3. Make what you need

My favourite principles are numbers 3 and 4. Make what you need is about building tools first and foremost for yourself first rather than building general tools for potential, hypothetical user. I love it.

I’ve been using building my own tools as a way to solve my day-to-day problems, to learn new technologies — and by writing about them, I’ve met likeminded people from whom I’ve learned more and with whom had a lot of fun.

While the principle itself can sound a bit gatekeep-y — “if you can’t build your own tools, you’re not IndieWeb” — that is not the goal of the principle. The principle list expands on the principle with the following:

Make tools, templates, etc. for yourself first, not for all of your friends or ”everyone“. If you design for some hypothetical user, they may not actually exist; if you make for yourself, you actually do exist. — Make something that satisfies your needs (also known as scratch your own itch), and is compatible for others, e.g. by practicing POSSE, you benefit immediately, while staying connected to friends, without having to convince anyone. If and when others join the indieweb, you all benefit.

I absolutely love building tools for my own site and I like to write about them in my blog to share ideas and hopefully help someone else learn from them. But the tools themselves are not general tools or something that other people can just pick up, install and start using.

They exist to solve my practical problems with my website structure and the other tools I use. If I’d try to build them into general use tools, I’d never get my own problems solved. It would take so much more time and work and might even require me to change how I build my website.

4. Use what you make

The partner in crime of the previous principle is the fourth one: use what you make.

Whenever I write or talk to people — especially students, juniors and career changers — about learning the skills and entering the industry, I talk about how it’s very powerful to build tools for yourself. As you build something for yourself that you use regularly, you don’t have to imagine use cases or features because those arise from the actual needs as you use the tools.

Using your own tools also gives you good insights into what features or fixes to prioritise as you know very well what’s bothering you and on the other hand, what can be worked around.

To run my own website, I have built functionality to track software versions used in blog posts, tooling to enhance Notion’s heading levels, most popular posts feature, custom cookie consent, blog comments via Mastodon, tool to connect related blog posts, tools to fetch blog posts from Notion that I use as my CMS and more.

5. Document your stuff

Yes! Document and share what you’ve built so others can learn from your experiences. My blog has dozens and dozens of blog posts of tools I’ve built and how I run my site.

Luckily, I’m not alone. For example, 11ty Bundle is a brilliant website that aggregates blog posts and videos about developing websites with Eleventy. There are currently around 1500 posts(!). Big shoutout to Bob for running it!

Writing technical blog posts to document your work is such a good move. I go back to my own blog posts regularly to check how to do something. If I’ve done the work of learning from official docs and community forums to solve a problem, I’m in a great position to write it down so I can skip all that the next time. Who would be better at telling you how to do something than past you who already did it?

I also find technical writing a good way to refactor and improve my code. When I’m solving a problem, I’m in problem solving mode. Writing code is more about than solving the problems though, it’s also a way to communicate. When I switch to writing a blog post, I often notice problems with my code and instead of explaining them away in the post, I go back and fix them, resulting in way better code.

Sharing the work with the public audience can also lead to good opportunities to learn more, improve the code and connect with new people. I’ve been very lucky and privileged in my journey that vast majority of my online interactions with people after sharing my work has been such positive ones. And then there’s the person who commented on my post as:

Great blogpost to advertise yourself to potential employers that youre completely useless.

6. Open source your stuff

I tend to share most of my code as open source but with my personal website, I’ve decided to keep it private, mainly for content reasons. I don’t want to post blog post drafts (that might never end up reaching the public eye) into a public repository.

I’ve been thinking about releasing all the tooling publicly but then again, separating them from my website project would lead to a lot of extra complexity and work and as I mentioned earlier, they mainly work with my specific setup, I’ve figured it’s enough for now to share them in my blog posts as I talk about them.

7. UX and design is more important than protocols, formats, data models, schema

This is very much a rehashing of the second principle.

8. Modularity: Build platform agnostic platforms

As I mentioned earlier, I’ve started to pay much more attention lately to how I’m dependent on third party services and how crucial those dependencies are.

In my website self-sustenance checkup blog post, I wrote about what I’ve done to make sure that nothing on the critical path is dependent on someone else. I use services like Notion for CMS and Netlify for hosting but even if either of those would go down or block my access, I would be able to continue running, building and deploying my site with very little extra work.

There are some parts where I rely on existing services — like Mastodon for comments and Netlify for my most read posts feature — but none of them are critical and if I’d lose access to them, nothing would really break.

9. Longevity: Build for the long web

I think the best way to build long-lasting websites is to build static sites. When your website is a folder of files, it can be deployed to pretty much any webhost and displayed on browsers old and new.

Static sites also don’t require maintenance. If you stop updating your site, it can still be available in the web for years and years with no problems.

In Thoughts on accessibility in personal web, I briefly mentioned how my site has print styles. They exist for accessibility reasons but they also mean that my blog posts can be printed out on paper if someone really wants to store them in a non-digital way. (I’ve been thinking about printing yearly blog chronicles for myself.)

10. Pluralism

The community itself aims to be a diverse community and I applaud that it’s has been made into one of the main principles. Web is beautiful and there’s space for all sorts of websites and projects that showcase the diverse group of authors who build them.

11. Above all, have fun

Building a personal website should definitely be fun. Only the imagination and the ability to learn how to implement imaginary ideas are the limit when it comes to what your website can look like or what you can publish there.

For me, it’s also a perfect balancing act to my day job as a developer. With my own site, I can build whatever I want, whenever I want, with any tools and technologies I want and with any timeline I desire. No clients, no corporate stakeholders, no responsibilities — just pure bliss of telling the computer what to do.

When there unavoidably comes times when I don’t care about developing my site or I don’t have time or energy to focus on it, it lives in the web with zero effort, waiting for me to return when time is right.