people – Alice, Eve and Bob

SVB & finance stress: remember the (other) type of security

Now is the time for more vigilance, not less.

This is the week that the start-up world has been reeling after the collapse of Silicon Valley Bank. There have been lots of articles about it and about how the larger ecosystem (lawyers, VCs, other banks and beyond) have rallied to support those affected, written (on the whole, at least!) by people much better qualified than me to do so. But there’s another point that could get lost in the noise, and that’s the opportunity presented to bad actors by all of this.

When humans are tired, stressed, confused or have too many inputs, they (we – I’ve not succumbed to the lure of ChatGPT yet…) are prone to make poor decisions, or to take less time over decisions – even important decisions – than they ought to. Sadly, bad people know this, and that means that they will be going out of their way to exploit us (I’m very aware that I’m as vulnerable to this type of exploitation as anybody else). The problem is that when banks start looking dodgy, or when money is at stake, people need to do risky things. And these are often risky things which involve an awful lot of money, things like:

withdrawing large amounts of money
moving large amounts of money between accounts
opening new accounts
changing administrative access permissions and privileges on accounts
adding new people as administrators on accounts.

All of the above are actions (or involve actions) which we would normally be very careful about, and take very seriously (though that doesn’t stop us making the occasional mistake). The problem (and the opportunity for bad actors) is that when we’re stressed or in a hurry (as we’re likely to be in the current situation), we may pay less attention to important steps than we might otherwise. We might not enable multi-factor authentication, we might not check website certificates, we might click-through on seemingly helpful offers in emails to help us out, or we might not check the email addresses to which we’re sending invitations. All of these could lead bad folks to get at our money. They know this, and they’ll be going out of their way to find ways to encourage us to make mistakes, be less careful or hurry our way through vital processes.

My plea, then, is simple: don’t drop your guard because of the stress of the current situation. Now is the time for more vigilance, not less.

What’s your website’s D&D alignment?

This is the impression – often the first impression – that users of the website get of the organisation.

Cookies and Dungeons and Dragons – a hypothesis

Recent privacy legislation has led organisations to have to adopt ways of allowing their users to register their cookie preference in ways which expose the underlying motivations of the org. I have a related theory, and it goes like this: these different registration options allow you to map organisations to one of the 9 Dungeons and Dragons character alignments.

This may seem like a bit of a leap, but stick with me. First, here’s a a little bit of background for those readers who’ve never dabbled in (or got addicted to -there’s little room between the two extremes) the world of Dungeons and Dragons (or “D&D”). There are two axes used to describe a character: Lawful-Neutral-Chaotic and Good-Neutral-Evil. Each character has a position across each of these axes, so you could have someone who’s Lawful-Good, one who’s Chaotic Neutral or one who’s Neutral-Good, for instance (a “Neutral-Neutral” character is described as “True Neutral”). A Lawful character follows the law – or a strong moral code, whereas a Chaotic one just can’t be bothered. A Neutral character tends to do so when it suits them. The Good-Neutral-Evil axis should be pretty clear.

Second bit of background: I never just accept cookies on a website. I always go through the preferences registration options, and almost always remove permissions for all cookie tracking beyond the “minimum required for functionality”. I know I’m in a tiny minority in this, but I like to pretend that I can safeguard at least some of my private data, so I do it anyway (and so should you). I’ve noticed, over the past few months, that there are a variety of ways that cookie choices are presented to you, and I reckon that we can map several of these to these D&D alignments, giving us a chance to get a glimpse into the underlying motivation of the organisation whose website we’re visiting.

I’ve attempted to map the basic approaches I’ve seen into this table.

Lawful Good	Neutral Good	Chaotic Good
Functional cookies only by default.	No cookies, and a link to a long and confusing explanation about how the organisation doesn’t believe in them.	No cookies at all, no explanation.
Lawful Neutral	True Neutral	Chaotic Neutral
Functional and tracking cookies by default, clear what tracking cookies are; all easy to turn off.	Functional and tracking cookies by default, completely unclear what the cookies do.	Random selection of cookies, and it’s unclear what they do, but you can at least turn them off.
Lawful Evil	Neutral Evil	Chaotic Evil
All cookies by default: functional, tracking and legitimate uses. Easy to remove with “reject all” or “object all”.	All cookies by default. “Legitimate uses” need to be deselected individually.	All cookies by default, with 100s listed. You have to deselect them by hand (there’s no “reject all” or “object all”), and there’s a 2 to 5 minute process to complete the registration, which finishes on 100% but never completes.

D&D alignments and website cookie preference approaches

Clearly, this is a tongue-in-cheek post, but there’s an important point here, I think: even if this glimpse isn’t a true representation of the organisation, it’s the impression – often the first impression – that users of the website get. My view of an organisation is formed partly through my interaction with its website, and while design, layout and content are all important, of course, the view that is presented about how much (if at all) the organisation cares about my experience, my data and my privacy should be something that organisations really care about. If they don’t respect me, then why should I respect them?

If I’m trying to attract someone to work for me, partner with me or buy from me, then my marketing department should be aware of the impression that visitors to my website glean from all interactions. At the moment, this seems to be missing, and while it’s not difficult to address, it seems to have escaped the notice of most organisations up to this point.

The 9 development stages for software (and kids)

We can draw parallels in the stages through which software projects and children tend to progress.

This week, one of my kids turned 18, and is therefore an adult – at least in the eyes of law in the UK, where we live. This is scary. For me, and probably for the rest of the UK.

It also got me thinking about how there are similarities between the development lifecycle for software and kids, and that we can probably draw some parallels in the stages through which they tend to progress. Here are the ones that occurred to me.

1. Creation

Creating a new software project is very easy, and a relatively quick process, though sometimes you have a huge number of false starts and things don’t go as planned. The same, it turns out, applies when creating children. Another similarity is that many software projects are created by people who don’t really know what they’re doing, and shouldn’t be allowed anywhere near the process at all. Equally useless at the process are people who have only a theoretical understanding of how it should work, having studied it at school, college or university, but who feel that they are perfectly qualified.

The people who are best qualified – those who have done it before – are either rather blasé about it and go about creating new ones all over the place, or are so damaged by it all that they swear they’ll never do it again. Beware: there are also numerous incidents of people starting software processes at very young ages, or when they had no intention of doing so.

2. Naming

Naming a software project – or a baby – is an important step, as it’s notoriously difficult to change once you’ve assigned a name. While there’s always a temptation to create a “clever” or “funny” name for your project, or come up with an alternative spelling of a well-known word, you creation will suffer if you allow yourself to be so tempted. Use of non-ASCII characters will either be considered silly, or, for non-Anglophone names, lead to complications when your project (or child) is exposed to other cultures.

3. Ownership

When you create a software project, you need to be careful that your employer (or educational establishment) doesn’t lay claim to it. This is rarely a problem for human progeny (if it is, you really need to check your employment contract), but issues can arise when two contributors are involved and wish to go their separate ways, or if other contributors – e.g. mothers-in-law – feel that their input should have more recognition, and expect more of their commits to be merged into main.

4. Language choice

The choice of language may be constrained by the main contributors’ expertise, but support for multiple languages can be very beneficial to a project or child. Be aware that confusion can occur, particularly at early stages, and it is generally worthwhile trying to avoid contributors attempting to use languages in which they are not fluent.

5. Documentation

While it is always worthwhile being aware of the available documentation, there are many self-proclaimed “experts” out there, and much conflicting advice. Some classic texts, e.g. The C Programming Language by Brian Kernighan and Dennis Ritchie or Baby and Child Care by Dr Benjamin Spock, are generally considered outdated in some circles, while yet others may lead to theological arguments. Some older non-core contributors (see, for example, “mothers-in-law”, above), may have particular attachments to approaches which are not considered “safe” in modern software or child development.

6. Maintenance

While the initial creation step is generally considered the most enjoyable in both software and child development processes, the vast majority of the development lifecycle revolves around maintenance. Keeping your project or child secure, resilient and operational or enabling them to scale outside the confines of the originally expected environment, where they come into contact with other projects, can quickly become a full-time job. Many contributors, at this point, will consider outside help to manage these complexities.

7. Scope creep

Software projects don’t always go in the direction you intend (or would like), discovering a mind of their own as they come into contact with external forces and interacting in contexts which are not considered appropriate by the original creators. Once a project reaches this stage, however, there is little that can be done, and community popularity – considered by most contributors as a positive attribute at earlier stages of lifecycle – can lead to some unexpected and possibly negative impacts on the focus of the project as competing interests vie to influence the project’s direction. Careful management of resources (see below) is the traditionally approach to dealing with this issue, but can backfire (withdrawal of privileges can have unexpected side effects in both software and human contexts).

8. Resource management

Any software project always expands to available resources. The same goes for children. In both cases, in fact, there will always appear to be insufficient resources to meet the “needs” of the project/child. Be strong. Don’t give in. Consider your other projects and how they could flourish if provided with sufficient resources. Not to mention your relationships with other contributors. And your own health/sanity.

9. Hand-over

At some point, it becomes time to hand over your project. Whether this is to new lead maintainer (or multiple maintainers – we should be open-minded), to an academic, government or commercial institution, letting go can be difficult. But you have to let go. Software projects – and children – can rarely grow and fulfil their potential under the control of the initial creators. When you do manage to let go, it can be a liberating experience for you and your creation. Just don’t expect that you’ll be entirely free of them: for some reason, as the initial creator, you may well be expected to arrange continued resources well past the time you were expecting. Be generous, and enjoy the nostalgia, but you’re not in charge, so don’t expect the resources to be applied as you might prefer.

Conclusion

I’m aware that there are times when children – and even software projects – can actually cause pain and hurt, and I don’t want to minimise the negative impact that the inability to have children, their illness, injury or loss can have on individuals and families. Please accept this light-hearted offering in the spirit it is meant, and if you are negatively affected by this article, please consider accessing help and external support.

Closing Profian

In June 2021, a little under two years ago, I left Red Hat and joined Profian as the CEO – Chief Executive Officer. In mid-January 2023, we – the board – decided to close down the company. All 14 members of the company are looking for new jobs.

I’ve not been blogging much recently, and it’s been because I’ve been busy trying to sort out what we do with the company. We looked at many different options around getting more funding or even being acquired by another company, but none came to fruition, so we decided to close down the company as gracefully as we could. It’s not been an easy few weeks (or months, in fact), but I’ve pretty much come to peace with the decision.

I’ll be writing more posts about what happened, how we got there, and the rest, but here’s a quick version of what happened, as I posted in an internal chat room:

While pretty much everybody believes that Confidential Computing is on its way, there’s also general agreement in the market that it’s not ready for major market adoption for 12 or more months. This is partly due to the fact that the tech is still regarded as immature (and prone to vulnerabilities) and also largely because the recessionary pressures on all sectors mean that organisations are protecting their core existing services, rather than betting money on new tech. VCs are into “ARR”: Annual Recurring Revenue. They want to see fast growth, and paid pilots with (even with big players) which don’t lead to fast scaling of the business aren’t considered sufficient. The amount of money available wouldn’t have been sufficient to allow us to grow and defend a market share in order to get to the next funding round. We also looked at acquisition, but nobody was ready to bet on new tech to the extent of buying the company: again, because they’re defending their existing services and staff (and, in many cases, laying people off already).
Me, on internal Profian chat room

I’m currently focussing on four things:

helping the extremely talented Profian team find new jobs;
winding the company down;
taking some time to recover from the past few months – emotionally, mentally and physically;
starting to look for a new job for myself.

If you can help with #1 or #4, please get in touch. Otherwise, keep an eye out on this blog, and expect more posts. See you soon.

Enarx hits 750 stars

Yesterday, Enarx, the open source security project of which I’m co-founder and for which Profian is custodian, gained its 750th GitHub star. This is an outstanding achievement, and I’m very proud of everyone involved. Particular plaudits to Nathaniel McCallum, my co-founder for Enarx and Profian, Nick Vidal, the community manager for Enarx, everyone who’s been involved in committing code, design, tests and documentation for the project, and everyone who manages the running of the project and its infrastructure. We’ve been lucky enough to be joined by a number of stellar interns along the way, who have also contributed enormously to the project.

Enarx has also been supported by a number of organisations and companies, and it’s worth listing as many of them as I can think of:

Profian, the current custodian
Red Hat, under whose auspices the initial development began
the Confidential Computing Consortium, a Linux Foundation Project, which owns the project
Equinix, who have donated computing resources
PhoenixNAP, who have donated computing resources
Rocket.Chat, who have donated chat resources
Intel, who have worked with us along the way and donated various resources
AMD, who have worked with us along the way and donated various resources
Outreachy, with whom worked to get some of our fine interns

When it all comes down to it, however, it’s the community that makes the project. We strive to create a friendly, open community, and we want more and more people to get involved. To that end, we’ll soon be announcing some new ways to get involved with trying and using Enarx, in association with Profian. Keep an eye out, and keep visiting and giving us stars!

Back in the (conference) groove

Ah, yes: conferences. We love them, we hate them.

Ah, yes: conferences. We love them, we hate them, but they used to be part of the job, and they’re coming back. At least in the IT world that I inhabit, things are beginning to start happening in person again. I attended my first conference in over two years in Valencia a couple of weeks ago: Kubecon + CloudNativeCon Europe. I’d not visited Valencia before, and it’s a lovely city. I wasn’t entirely well (I’m taking a while to recover from Covid-19 – cannot recommend), which didn’t help, but we had some great meetings, Nathaniel (my Enarx & Profian co-founder) spoke at the co-located WasmDay event on WASI networking, and I got to walk the exhibition hall picking up (small amounts) of swag (see Buying my own t-shirts, OR “what I miss about conferences”).

For the last few years, when I’ve been attending conferences, I’ve been doing it as the employee of a large company – Red Hat and Intel – and things are somewhat different when you’re attending as a start-up. We (Profian) haven’t exhibited at any conferences yet (keep an eye out for announcements on social media for that), but you look at things with a different eye when you’re a start-up – or at least I do.

One of the differences, of course, is that as CEO, my main focus has to be on the business side, which means that attending interesting talks on mildly-related technologies isn’t likely to be a good use of my time. That’s not always true – we’re not big enough to send that many people to these conferences, so it may be that I’m the best person available to check out something which we need to put on our radar – but I’m likely to restrict my session attendance to one of three types of session:

a talk by a competitor (or possible competitor) to understand what they’re doing and how (and whether) we should react.
a talk by a possible customer or representative from a sector in which we’re interested, to find understand possible use cases.
a talk about new advances or applications of the technologies in which we’re interested.

There will, of course, also be business-related talks, but so many of these are aimed at already-established companies that it’s difficult to find ones with obvious applicability.

What else? Well, there are the exhibition halls, as I mentioned. Again, we’re there to look at possible competitors, but also to assess possible use cases. These aren’t just likely to be use cases associated with potential customers – in fact, given the marketing dollars (euros, pounds, etc.) funnelled into these events, it’s likely to be difficult to find clear statements of use cases, let alone discover the right person to talk to on the booth. More likely, in fact, is finding possible partners or licensees among the attendees: realising that there are companies out there with a product or offering to which we could add value. Particularly for smaller players, there’s a decent chance that you might find someone with sufficient technical expertise to assess whether there might be fit.

What else? Well, meetings. On site, off site: whichever fits. Breakfast, cocktails or dinner seem to be preferred. as lunch can be tricky, and there aren’t always good places to sit for a quiet chat. Investors – VCs and institutional capital – realise that conferences are a good place to meet with their investees or potential investees. The same goes for partners for whom setting aside a whole day of meetings with a start-up makes little obvious sense (and it probably doesn’t make sense for us to fly over specially meet them either), but for whom finding a slot to discuss what’s going on and the state of the world is a good investment of their time if they’re already attending an event.

So – that’s what I’m going to be up to at events from now on, it seems. If you’re interested in catching up, I’ll be at RSA in San Francisco, Open Source Summit in Austin and Scale 19x in San Antonio in the next couple of months, with more to come. Do get in touch: it’s great to meet folks!

Emotional about open source

Enarx is available to all, usable by all.

Around October 2019, Nathaniel McCallum and I founded the Enarx project. Well, we’d actually started it before then, but it’s around then that the main GitHub repo starts showing up, when I look at available info. In the middle of 2021, we secured funding a for a start-up (now named Profian), and since then we’ve established a team of engineers to work on the project, which is itself part of the Confidential Computing Consortium. Enarx is completely open source, and that’s really central to the project. We want (and need) the community to get involved, try it out, improve it, and use it. And, of course, if it’s not open source, you can’t trust it, and that’s really important for security.

The journey has been hard at times, and there were times when we nearly gave up on the funding, but neither Nathaniel nor I could see ourselves working on anything else – we really, truly believe that there’s something truly special going on, and we want to bring it to the world. I’m glad (and relieved) that we persevered. Why? Because last week, on Thursday, was the day that this came true for me. The occasion was OC3, a conference in Confidential Computing organised by Edgeless Systems. I was giving a talk on Understanding trust relationships for Confidential Computing, which I was looking forward to, but Nick Vidal, Community Manager for the Enarx project, also had a session earlier on. His session was entitled From zero to hero: making Confidential Computing accessible, and wasn’t really his at all: it was taken up almost entirely by interns in the project, with a brief introduction and summing up by Nick.In his introduction, Nick explained that he’d be showing several videos recorded by the interns of demos they had recorded. These demos took the Enarx project and ran applications that the (they interns) had created within Keeps, using the WebAssembly runtime provided within Enarx. The interns and their demos were:

TCP Echo Server (Moksh Pathak & Deepanshu Arora) – Mosksh and Deepanshu showed two demos: a ROT13 server which accepts connections, reads text from them and returns the input, ROT13ed; and a simple echo server.
Fibonacci number generator (Jennifer Chukwu) – a simple Fibonacci number generator running in a Keep
Machine learning with decision tree algorithm on Diabetes data set (Jennifer Kumar & Ajay Kumar) – implementation of Machine Learning, operating on a small dataset.
Zero Knowledge Proof using Bulletproof (Shraddha Inamdar) – implementation of a Zero Knowledge Proof with verification.

What is exciting about these demos is several-fold:

three of them have direct real-world equivalent use cases:
1. The ROT13 server, while simple, could be the basis for an encryption/decryptions service.
2. the Machine Learning service is directly relevant to organisations who wish to run ML workloads in the Cloud, but need assurances that the data is confidentiality and integrity protected.
3. the Zero Knowledge Proof demo provides an example of a primitive required for complex transaction services.
none of the creators of the demos knew anything about Confidential Computing until a few months ago.
none of the creators knew much – if anything – about WebAssembly before coming to the project.
none of the creators is a software engineering professional (yet!). They are all young people with an interest in the field, but little experience.

What this presentation showed me is that what we’re building with Enarx (though it’s not even finished at this point) is a framework that doesn’t require expertise to use. It’s accessible to beginners, who can easily write and deploy applications with obvious value. This is what made me emotional: Enarx is available to all, usable by all. Not just security experts. Not just Confidential Computing gurus. Everyone. We always wanted to build something that would simplify access to Confidential Computing, and that’s what we, the community, have brought to the world.

I’m really passionate about this, and I’d love to encourage you to become passionate about it, too. If you’d like to know more about Enarx, and hopefully even try it yourself, here are some ways to do just that;

visit our website, with documentation, examples and a guide to getting started
join our chat and then one of our stand-ups
view the code over at GitHub (and please star the project: it encourages more people to get involved!)
read the Enarx blog
watch the video of the demos.

I’d like to finish this post by thanking not only the interns who created the demos, but also Nick Vidal, for the incredible (and tireless!) work he’s put into helping the interns and into growing the community. And, of course, everyone involved in the project for their efforts in getting us to where we are (and the vision to continue to the next exciting stages: subscribe to this blog for upcoming details).

A new state of mind

I’m quite proud; though maybe slightly ashamed that I didn’t do it before.

Last year, I co-founded Profian with Nathaniel McCallum, a colleague from Red Hat. It’s a security start-up in the Confidential Computing Space, based on the open source Enarx project. There’s an update on that on the Profian blog with an article entitled Design to Roadmap to Product.

It’s an article on what we’ve been up to in the company, and a records the realisation that it’s time for me to step into yet another role as one of the founders: moving beyond the “let’s make sure that we have a team and that the basic day-to-day running of the company is working” to “OK, let’s really map out our product roadmap and how we present them to customers.”

A new state of mind

Which leads me to the main point of this short article. This is not an easy transition – it’s yet another new thing to learn, discover which bits I’m good at, improve the bits I’m not, get internal or external help to scale with, etc. – but it’s a vital part of being the CEO of a start-up.

It’s also something which I had, to be honest, been resisting. Most of us prefer to stick to stuff which we know – whether we’re good at it or not, sometimes! – rather than “embracing change”. Sometimes that’s OK, but in the position I’m in at the moment, it’s not. I have responsibility to the company and everyone involved in it to ensure that we can be successful. And that means doing something. So I’ve been listening to people say, “these are the things you need to do”, “here are the ways we can help you”, “this is what you should be looking for” and, while listening, just, well, putting it off, I suppose. Towards the end of last week, I ordered a book (The Founder Handbook) to try to get my head round it a bit more. There are loads of this type of book, but I did a little research, and this looked like it might be one of the better ones.

So, it arrived, and I started reading it. And, darn it, it made sense. It made me start seeing the world in a new way – a way which might not have been relevant to me (or the company) a few months ago, but really is, now. And I really need to embrace lots of the things the authors are discussing. I’m not saying that it’s a perfect book, or that no other book would have prompted this response, but at some point over the weekend, I thought: “right, it’s time to change and to move into this persona, thinking about these issues, being proactive and not putting it off anymore”.

I’m quite proud, to be honest; though maybe slightly ashamed that I didn’t do it before. I cemented the decision to jump into a new mindset by doing what I’ve done on a couple of occasions before (including when I decided to commit to writing my book): I told a few people what I was planning to do. This really works for me on several levels:

I’ve made a public commitment (even if it’s to a few people[1]), so it’s difficult to roll it back;
I’ve made a commitment to myself, so I can’t pretend that I haven’t and let myself drift back into the old mindset;
it sets expectations from other people as to what I’m going to do;
people are predisposed to being helpful when you struggle, or ask for help.

These are all big positives, and while telling people you’ve made a big decision may not work for everyone, it certainly helps for me. This is going to be only one of many changes I need to make if we’re to build a successful company out of Profian and Enarx, but acknowledging that it needed to be made – and that I was the one who was going to have to effect that change – is important to me, the company, our investors and our employees. Now all I need to do is make a success of it! Wish me luck (and keep an eye out for more…).

1 – a few more people now, I suppose, now that I’ve published this article!

How to hire an open source developer

Our view was that a pure “algorithm coding” exercise was pretty much useless for what we wanted.

We’ve recently been hiring developers to work on the Enarx project, a security project, written almost exclusively in Rust (with a bit of Assembly), dealing with Confidential Computing. By “we”, I mean Profian, the start-up for which I’m the CEO and co-founder. We’ve now found all the people we’re looking for initially on the team (with a couple due to start in the next few weeks), though we absolutely welcome contributors to Enarx, and, if things continue to go well, we’ll definitely want to hire some more folks in the future.

Hiring people is not easy, and we were hit with a set of interesting requirements which made the task even more difficult. I thought it would be useful and interesting for the community to share how we approached the problem.

What were we looking for?

I mentioned above some interesting requirements. Here’s what the main ones were:

systems programming – we mainly need people who are happy programming at the systems layer. This is pretty far down the stack, with lots of interactions directly with hardware or the OS. Where we are creating client-server pieces, for instance, we’re having to write quite a lot of the protocols, manage the crypto, etc., and the tools we’re using aren’t all very mature (see “Rust” below).
Rust – almost all of the project is written in Rust, and what isn’t is written in Assembly language (currently exclusively x86, though that may change as we add more platforms). Rust is new, cool and exciting, but it’s still quite young, and some areas don’t have all the support you might like, or aren’t as mature as you might hope – everything from cryptography through multi-threading libraries and compiler/build infrastructure.
distributed team – we’re building a team of folks where can find them: we have developers in Germany, Finland, the Netherlands, North Carolina (US), Massachusetts (US), Virginia (US) and Georgia (US), I’m in the UK, our community manager is in Brazil and we have interns in India and Nigeria. We knew from the beginning that we wouldn’t have everyone in one place, and this required people who we were happy would be able to communicate and collaborate with people via video, chat and (at worst) email.
security – Enarx is a security project, and although we weren’t specifically looking for security experts, we do need people who are able to think and work with security top of mind, and design and write code which is applicable and appropriate for the environment.
git – all of our code is stored in git (mainly GitHub, with a little bit of GitLab thrown in), and so much of our interaction around code revolves around git that anybody joining us would need to be very comfortable using it as a standard tool in their day-to-day work.
open source – open source isn’t just a licence, it’s a mindset, and, equally important, a way of collaborating. A great deal of open source software is created by people who aren’t geographically co-located, and who might not even see themselves as a team. We needed to be sure that the people we were hiring, while gelling as a close team within the company, will also be able to collaborate with people outside the organisation and be able to embrace Profian’s “open by default” culture not just for code, but for discussions, communications and documentation.

How did we find them?

As I’ve mentioned before, in Recruiting is hard. We ended up using a variety of means to find candidates, with varying levels of success:

LinkedIn job adverts
LinkedIn searches
Language-specific discussion boards and hiring boards (e.g. Reddit)
An external recruiter (shout out to Gerald at Interstem)
Word-of-mouth/personal recommendations

It’s difficult to judge between them in terms of quality, but without an external recruiter, we’d certainly have struggled with quantity (and we had some great candidates from that pathway, too).

How did we select them?

We needed to measure all of the candidates against all of the requirements noted above, but not all of them were equal. For instance, although we were keen to hire Rust programmers, we were pretty sure that someone with strong C/C++ skills at the systems level would be able to pick up Rust quickly enough to be useful. On the other hand, a good knowledge of using git was absolutely vital, as we couldn’t spend time working with new team members to bring them up-to-speed on our way of working. A strong open source background was, possibly surprisingly, not a requirement, but the mindset to work in that sort of model was, and anyone with a history of open source involvement is likely to have a good knowledge of git. The same goes for the ability to work in a distributed team: so much of open source is distributed that involvement in almost any open source community was a positive indicator. Security we decided was a “nice-to-have”.

How to proceed? We wanted to keep the process simple and quick – we don’t have a dedicated HR or People function, and we’re busy trying to get code written. What we ended up was this (with slight variations), which we tried to get complete within 1-2 weeks:

Initial CV/resume/github/gitlab/LinkedIn review – this to decide whether to interview
30-40 minute discussion with me as CEO, to find out if they might be a good cultural fit, to give them a chance to find out about us, and get an idea if they were as technically adept as they appeared from the first step
Deep dive technical discussion led by Nathaniel, usually with me there
Chat with other members of the team
Coding exercise
Quick decision (usually within 24 hours)

The coding exercise was key, but we decided against the usual approach. Our view was that a pure “algorithm coding” exercise of the type so beloved by many tech companies was pretty much useless for what we wanted. What we wanted to understand was whether candidates could quickly understand a piece of code, fix some problems and work with the team to do so. We created a github repository (in fact, we ended up using two – one for people a little higher up the stack) with some almost-working Rust code in it, some instructions to fix it, perform some git-related processes on it, and then improve it slightly, adding tests along the way. A very important part of the test was to get candidates to interact with the team via our chat room(s). We scheduled 15 minutes on a video call for set up and initial questions, 2 hours for the exercise (“open book” – as well as talking to the team, candidates were encouraged to use all resources available to them on the Internet), followed by a 30 minute wrap-up session where the team could ask questions and the candidate could also reflect on the task. This also allowed us to get an idea of how well the candidate was able to communicate with the team (combined with the chat interactions during the exercise). Afterwards, the candidate would drop off the call, and we’d generally make a decision within 5-10 minutes as to whether we wanted to hire them.

This generally worked very well. Some candidates struggled with the task, some didn’t communicate well, some failed to do well with the git interactions – these were the people we didn’t hire. It doesn’t mean they’re not good coders, or that they might not be a good fit for the project or the company later on, but they didn’t immediate meet the criteria we need now. Of the ones we hired, the levels of Rust experience and need for interaction with the team varied, but the level of git expertise and their reactions to our discussions afterwards was always sufficient for us to decide to take them.

Reflections

On the whole, I don’t think we’d change a huge amount about the selection process – though I’m pretty sure we could do better with the search process. The route through to the coding exercise allowed us to filter out quite a few candidates, and the coding exercise did a great job of helping us pick the right people. Hopefully everyone who’s come through the process will be a great fit and will produce great code (and tests and documentation and …) for the project. Time will tell!

Open source Christmas presents

Give the gift of open source to more people.

If you find this post interesting, you’ll find a lot more about how community and open source are important in my book Trust in Computer Systems and the Cloud, published by Wiley.

Whether you celebrate Christmas or not (our family does, as it happens), this time of year is one where presents are often given and received. I thought it might be nice to think about what presents we could give in the spirit of open source. Now, there are lots of open source projects out there, and you could always use one to create something for a friend, colleague or loved one (video, audio, blog post, image, website) or go deeper with a project which combines open source software and hardware, such as Mycroft or Crowdsupply. Or you could go in the other direction, and get people involved in projects you’re part of or enjoy. That’s what I’d like to suggest in this article: give the gift of open source to more people, or just make open source more accessible to more people: that’s a gift in itself (to them and to the project!).

Invite

First of all, people need to know about projects. “Evangelism” is a word that’s often used around open source projects, because people need to be told about them before they can get involved. Everyone can do evangelism, whether it’s word of mouth, laptop stickers, blog posts, videos, speaking at conferences, LinkedIn mentions, podcasts, Slack, IRC, TikTok[1], Twitter, ICQ[2] or Reddit. Whatever is your preferred medium to talk to the world, use it. Tell people why it’s important. Tell people why it’s fun. Share the social side of the project. Explain some of the tricky design issues that face it. Tell people why it’s written in the language(s) it’s in. Point people at the sections of code you’ve written and are proud of. Even better, point people at the sections of code you’ve written and are ashamed of, but don’t have time to fix as you’re too busy at the moment. But most of all, invite them to look around, meet the contributors, read the code, test the executables, read the documentation. Make it easy for them to find the project. Once we get back to a world where in-person conferences are re-emerging, arrange meet-ups, provide swag and get together (safely!) IRL[3].

Include

Once your invitees have started looking around, interacting with the community, submitting issues, documentation or patches, find ways to include them. There’s nothing more alienating than, well, being alienated. I think the very worst thing anyone can say to a person new to a project is something along the lines of “go and read the documentation – this is a ridiculous question/terrible piece of documentation/truly horrible piece of code”. It may be all of those things, but how does that help anyone? If you find people giving these reactions – if you find yourself giving these reactions – you need to sort it out. Everyone was a n00b once, and everyone has a different learning style, way of interacting, cultural background and level of expertise. If there are concerns that senior project members’ time is being “wasted” by interactions, nominate (and agree!) that someone will take time to mentor newcomers. Better yet, take turns mentoring, so that information and expertise is spread widely and experts in the project get to see the questions and concerns that non-experts are having. There are limits to this, of course, but you need to find ways not just to welcome people into the project, but actually include them in the functioning, processes, social interactions and day-to-day working of the project which make it a community.

You should also strongly consider a code of conduct such as the Contributor Covenant to model, encourage and, if necessary enforce appropriate and inclusive behaviour. Diversity and Inclusion are complex topics, but there’s a wealth of material out there if you want to take engage – and you should.

Encourage

Encouragement is a little different to inclusion. It’s possible to feel part of a community, but not actually to be participating to the development and growth of the project. Encouragement may be what people need to move into active engagement, contributing more than lurking. And there’s a difference between avoiding negative comments (as outlined above) and promoting positive interactions. The former discourage, and the latter can encourage. If someone contributes their first patch, and gets an “accepted, merged” message, that’s great, but it’s pretty clear that they’re much more likely to contribute again if, instead, they receive a message along the lines of “thanks for this: great to see. We need more contributions in this area: have you looked at issues #452, #599 and #1023?”.

These sorts of interactions are time-consuming, and it may not always be the maintainers who are providing them: as above, the project may need to have someone whose role includes this sort of encouragement. If you’re using something like Github, you may be able to automate notifications of first-time contributions so that you know that it’s time to send an encouraging message. The same could go for someone who was making a few contributions, but has slowed down or dropped off: a quick message or two might be enough to get them involved in the project again.

Celebrate

I see celebration as as step on again from simple encouragement – though it can certainly reinforce it. Celebration isn’t just about acknowledging something positive, but is also a broader social interaction. When somebody’s achievements are celebrated, other people in the community come together to say well done and congratulate them. This is great for the person whose work is being celebrated, as the acknowledgement from others reinforces the network of people with whom they’re connected, bringing them closer into the community.

Celebrating a project-related event like a release and including new members of the community in that celebration can be even more powerful. When new members are part of a celebration, and are made to feel that their contributions, though small, have made up part of what’s being celebrated, their engagement in the project is likely to increase. Their feelings of inclusion in the community are also likely to go up. Celebrations in person (again, when possible) allow for better network-building and closer ties, but even virtual meet-ups can bring peripherally-involved or new members closer to the core of the project.

Summary

Getting people involved in your open source project is important for its health and its growth, but telling people about it isn’t enough. You need to take conscious steps to increase involvement and ensure that initial contributions to a project are followed up, tying people into the project and making them part of the community.

1 – I’m going to be honest: I wouldn’t know where to start with TikTok. My kids will probably be appalled that I even mentioned it, but hey, why not? The chances are that you, dear reader, are younger and (almost certainly) cooler than I am.

2 – I’m guessing the take up will be a bit lower here.

3 – In Real Life. It seems odd to be re-using this term, which had all but disappeared from what I could tell, but which seems to need to re-popularised.