I’m currently involved – heavily involved – in Enarx, an open source (of course!) project to allow you run sensitive workloads on untrusted hosts. I’ve had involvement in various open source projects over the years, but this is the first for which I’m one of the founders. We’re at the stage now where we’ve got a fair amount of code, quite a lot of documentation, a logo and (important!) stickers. The project should hopefully be included in a Linux Foundation group – the Confidential Computing Consortium – so things are going very well indeed. We’re at the stage where I thought it might be useful to reflect on some of the things we did to get things going. To be clear, Enarx is a particular type of project: one that we believe has commercial and enterprise applications. It’s also not mature yet, and we’ll have hurdles and challenges along the way. What’s more, the route we’ve taken won’t be right for all projects, but hopefully there’s enough here to give a few pointers to other projects, or people considering starting one up.
The first thing I’d say is that there’s lots of help to be had out there. I’d start with Opensource.com, where you’ll find lots of guidance. I’d then follow up by saying that however much of it you follow, you’ll still get things wrong. Anyway, here’s my list of things to consider.
1. Aim for critical mass
I’m very lucky to work at the amazing Red Hat, where everything we do is open source, and where we take open source and community very seriously. I’ve heard it called a “critical mass” company: in order to get something taken seriously, you need to get enough people interested in it that it’s difficult to ignore. The two co-founders – Nathaniel McCallum and I – are both very enthusiastic about the project, and have spent a lot of time gaining sponsors within the organisation (you know who you are, and we thank you – we also know we haven’t done a good enough job with you on all occasions!), and “selling” it to engineers to get them interested enough that it was difficult to stop. Some projects just bobble along with one or two contributors, but if you want to attract people and attention, getting a good set of people together who can get momentum going is a must.
2. Create a demo
If you want to get people involved, then a demo is great. It doesn’t necessarily need to be polished, but it does need to show that what you’re doing it possible, and that you know what you’re doing. For early demos, you may be talking to command line output: that’s fine, if what you’re providing isn’t a UI product. Being able to talk to what you’re doing, and convey both your passion and the importance of the project, is a great boon. People like to be able to see or experience something, and it’s much easier to communicate your enthusiasm if they have something that’s real which expresses that.
3. Choose a licence
Once you have code, and it’s open source, you want other people to be able to contribute. This may seem like an unimportant step, but selecting an appropriate open source licence[1] will allow other people to contribute on well-understood and defined terms, making it easier for them, and easier for the organisations for which they work to allow them to be involved.
4. Get documentation
You might think that developer documentation is the most important to get out there – otherwise, how will other people get involved and coding? I’d disagree, at least to start with. For a small project, you can probably scale to a few more people just by explaining what the code does, what it should do, and what’s missing. However, if there’s no documentation available to explain what it’s for, and how it’s going to help people, then why would anyone bother even looking at it? This doesn’t need to be polished marketing copy, and it doesn’t need to be serious, but it does need to convey to people why they should care. It’s also going to help you with the first point I mentioned, attaining critical mass, as being able to point to documentation, use cases and the rest will help convince people that you’ve thought through the point of your project. We’ve used a github wiki as our main documentation hub, and we try to update that with new information as we generate it. This is an area, to be clear, where we could do better. But at least we know that.
5. Be visible
People aren’t going to find out about you unless you’re visible. We were incredibly lucky in that just as we were beginning to get to a level of critical mass, the Confidential Computing Consortium was formed, and we immediately had a platform to increase our exposure. We have Twitter account, I publish articles on my blog and at Opensource.com, we’ve been lucky enough to have the chance to publish on Red Hat’s now + Next blog, I’ve done interviews the the press and we speak at conferences wherever and whenever we can. We’re very lucky to have these opportunities, and it’s clear that not all these approaches are appropriate for all projects, but make use of what you can: the more people that know about you, the more people can contribute.
6. Be welcoming
Let’s assume that people have found out about you: what next? Well, they’re hopefully going to want to get involved. If they don’t feel welcome, then any involvement they have will taper off soon. Yes, you need documentation (and, after a while, technical documentation, no matter what I said above), but you need ways for them to talk to you, and for them to feel that they are valued. We have Gitter channels (https://gitter.im/enarx/), and our daily stand-ups are open to anyone who wants to join. Recently, someone opened an issue on our issues database, and during the conversation on that thread, it transpired that our daily stand-up time doesn’t work for them given their timezone, so we’re going to ensure that at least one a week does, and we’ve assured that we’ll accommodate them.
7. Work with people you like
I really, really enjoy meeting and working with the members of Enarx project team. We get on well, we joke, we laugh and we share a common aim: to make Enarx successful. I’m a firm believer in doing things you enjoy, where possible. Particularly for the early stages of a project, you need people who are enthusiastic and enjoy working closely together – even if they’re separated by thousands of kilometres[2] geographically. If they don’t get on, there’s a decent chance that your and their enthusiasm for the project will falter, that the momentum will be lost, and that the project will end up failing. You won’t always get the chance to choose those with whom you work, but if you can, then choose people you like and get on with.
Conclusion – “people”
I didn’t realise it when I started writing this article, but it’s not really about project mechanics at all: it’s about people. If you read back, you’ll find the importance of people visible in every tip, even including the one about choosing a licence. Open source projects aren’t really about code: they’re about people, how they share, how they work together, and how they interact.
I’m certain that your experience of open source projects will vary, and I’d be very surprised if everyone agrees about the top seven things you should do for project success. Arguably, Enarx isn’t a success yet, and I shouldn’t be giving advice at this stage of our maturity. But when I think back to all of the open source projects that I can think of which are successful, people feature strongly, and I don’t think that’s a surprise at all.
1 – or “license”, if you’re from the US.
2 – or, in fact, miles.
Alice, Eve and Bob - a security blog 
4 thoughts on “7 tips for kicking off an open source project”