Obnam is going to be an encrypting, de-duplicating, secure, and fast backup software implementation that's easy and convenient to use.

I've been developing a new generation of Obnam for a couple of years now. So far I have mostly been exploring architectural and implementation design choices on my own. Obnam is now getting close to actually being able to make and restore backups. In a sense, it's becoming real.

Open source software tends to be healthier and more useful to more people for longer if there is a supportive community around it. I would like to build such a community around Obnam. This blog post is the start of that.

By community I mean a group of people with a shared interest in the software, who also feel they belong together, and who are interested in nurturing the community and software.

I've been been building Obnam for my personal use and also because I can't stop thinking about the many fascinating technical problems of implementing backup software. As long as I'm the whole of the target audience, I have no time pressure or any other outside pressure to make it usable. I like this very much, although it does get a little lonely sometimes.

While Obnam still isn't ready for use, it's getting there, and I've started to think about the future. Once I use Obnam myself, I expect others will also want to use it. This will bring in many kinds of pressure. I do not look forward to dealing with that entirely on my own.

I'd like to build a community of people around Obnam for many reasons:

• mutual emotional support when building the software

• doing things together for each other is just more fun

• the software will be better when those who use it get heard

• while I'm the greatest hacker who will exist(1), I am painfully aware that I do not know everything and sometimes I make mistakes; a community can help guide me and others

  Footnote 1: That's a joke.

• sharing the burden will allow the community to carry a heavier load and avoid burning out an individual maintainer

• sharing knowledge will make the software live longer, and when I some day won't be available any more, the community can keep the software alive, and improve it, without me

• a vibrant community seems like a better way to defend the freedom of the software than relying on legal action

I'm not particularly good with people or indeed with building or managing communities, but here's what I'm thinking as a start:

• Aim for a community of people that helps build and guide the software. This means people who contribute in any way. This means code changes, but perhaps more importantly, help with needs and wants ("acceptance criteria", or"requirements"): everyone's specific needs for backup software is a little different from others’, and discussing these is hugely important. (That doesn't mean everyone gets to have every wish fulfilled, but discussing needs and wants is the way to find out what's most important.)

  Just saying "thank you" is also an important contribution. It's amazing how much that helps. It's also quite unusual, I'm afraid, except for the very popular projects.

  Trying out the software and giving clear feedback is hugely important. This can be ad hoc, or more systematic. It can be running benchmarks, or trying things on unusual systems. Do you have a mechanical watch you built yourself that runs NetBSD on fourteen bits of storage? Telling the developers how the software behaves on that exposes limitations and assumptions that may be helpful for other use cases. Again, supporting your use case may be impossible, or too much work, but knowing about it is still useful.

• Helping run the community is itself important. Any group of people will need some level of management to thrive. Even if it's just two friends who occasionally meet for lunch. A larger group, especially of strangers, will need more work. What are the rules? How to change them? What kind of behavior is acceptable? How are decisions made? Who's in and who's out? I have opinions, but this is not my particular area of expertise, so other people stepping up is helpful.

More concretely:

• I've set up an instance of the Zulip chat system (https://obnam.zulipchat.com/). A community needs a place to meet, and Zulip is my current preference, until the community chooses to change it. I will continue to post on the fediverse and the obnam.org blog. Documentation will go into the Obnam or website Git repositories. The chat is for discussion.

• I'll be the initial moderator for the chat. I’ve set up an initial code of conduct. As the community grows, I hope others will step up.

• Start building a culture of defining acceptance criteria, via the chat system. This will guide the design of the first release, which I expect to happen as soon as Obnam can make and restore backups reasonably conveniently.

For any of this to work, people need to be interested in enough to participate and contribute. Would you? If so, join the Obnam Zulip and join the discussion. See you there.