More Enarx milestones

It’s been a big month for Enarx.

It’s being a big month for Enarx. Last week, I announced that we’d released Enarx 0.3.0 (Chittorgarh Fort), with some big back-end changes, and some new functionality as well. This week, the news is that we’ve hit a couple of milestones around activity and involvement in the project.

1500 commits

The first milestone is 1500 commits to the core project repository. When you use a git-based system, each time you make a change to a file or set of files (including deleting old ones, creating new one and editing or removing sections), you create a new commit. Each commit has a rather long identifier, and its position in the project is also recorded, along with the name provided by the committer and any comments. Commit 1500 to the enarx was from Nathaniel McCallum, and entitled feat(wasmldr): add Platform API. He committed it on Saturday, 2022-03-19, and its commit number is 8ec77de0104c0f33e7dd735c245f3b4aa91bb4d2.

I should point out that this isn’t the 1500th commit to the Enarx project, but the 1500th commit to the enarx/enarx repository on GitHub. This is the core repository for the Enarx project, but there are quite a few others, some of which also have lots of commits. As an example, the enarx/enarx-shim-sgx repository ,which provides some SGX-specific capabilities within Enarx, had 968 commits at time of writing.

500 Github stars

The second milestone is 500 GitHub stars. Stars are measure of how popular a repository or project is, and you can think of them as the Github of a “like” on social media: people who are interested in it can easily click a button on the repository page to “star” it (they can “unstar” it, too, if they change their mind). We only tend to count stars on the main enarx/enarx repository, as that’s the core one for the Enarx project. The 500th star was given to the project by a GitHub user going by the username shebuel-oss, a self-described “Open Source contributor, Advocate, and Community builder”: we’re really pleased to have attracted their interest!

There’s a handy little website which allows you to track stars to a project called GitHub Star History where you can track the addition (or removal!) of stars, and compare other projects. You can check the status of Enarx whenever you’re reading by following this link, but for the purposes of this article, the important question is how did we get to 500? Here’s a graph:

Enarx GitHub star history to 500 stars

You’ll see a nice steep line towards the end which corresponds to Nick Vidal’s influence as community manager, actively working to encourage more interest and involvement, and contributions to the Enarx project.

Why do these numbers matter?

Objectively, they don’t, if I’m honest: we could equally easily have chosen a nice power of two (like 512) for the number of stars, or the year that Michelangelo started work on the statue David (1501) for the number of commits. Most humans, however like round decimal numbers, and the fact that we hit 1500 and 500 commits and stars respectively within a couple of days of each provides a nice visual symmetry.

Subjectively, there’s the fact that we get to track the growth in interest (and the acceleration in growth) and contribution via these two measurements and their historical figures. The Enarx project is doing very well by these criteria, and that means that we’re beginning to get more visibility of the project. This is good for the project, it’s good for Profian (the company Nathaniel and I founded last year to take Enarx to market) and I believe that it’s good for Confidential Computing and open source more generally.

But don’t take my word for it: come and find out about the project and get involved.

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:

  1. 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.
  2. none of the creators of the demos knew anything about Confidential Computing until a few months ago.
  3. none of the creators knew much – if anything – about WebAssembly before coming to the project.
  4. 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:

  1. I’ve made a public commitment (even if it’s to a few people[1]), so it’s difficult to roll it back;
  2. 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;
  3. it sets expectations from other people as to what I’m going to do;
  4. 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:

  1. Initial CV/resume/github/gitlab/LinkedIn review – this to decide whether to interview
  2. 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
  3. Deep dive technical discussion led by Nathaniel, usually with me there
  4. Chat with other members of the team
  5. Coding exercise
  6. 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!

Cloud security asymmetry

We in the security world have to make people understand this issue.

My book, Trust in Computer Systems and the Cloud, is due out in the next few weeks, and I was wondering as I walked the dogs today (a key part of the day for thinking!) what the most important message in the book is. I did a bit of thinking and a bit of searching, and decided that the following two paragraphs expose the core thesis of the book. I’ll quote them below and then explain briefly why (the long explanation would require me to post most of the book here!). The paragraph is italicised in the book.

A CSP [Cloud Service Provider] can have computational assurances that a tenant’s workloads cannot affect its hosts’ normal operation, but no such computational assurances are available to a tenant that a CSP’s hosts will not affect their workloads’ normal operation.

In other words, the tenant has to rely on commercial relationships for trust establishment, whereas the CSP can rely on both commercial relationships and computational techniques. Worse yet, the tenant has no way to monitor the actions of the CSP and its host machines to establish whether the confidentiality of its workloads has been compromised (though integrity compromise may be detectable in some situations): so even the “trust, but verify” approach is not available to them.”

What does this mean? There is, in cloud computing, a fundamental asymmetry: CSPs can protect themselves from you (their customer), but you can’t protect yourself from them.

Without Confidential Computing – the use of Trusted Execution Environments to protect your workloads – there are no technical measures that you can take which will stop Cloud Service Providers from looking into and/or altering not only your application, but also the data it is processing, storing and transmitting. CSPs can stop you from doing the same to them using standard virtualisation techniques, but those techniques provide you with no protection from a malicious or compromised host, or a malicious or compromised CSP.

I attended a conference recently attended by lots of people whose job it is to manage and process data for their customers. Many of them do so in the public cloud. And a scary number of them did not understand that all of this data is vulnerable, and that the only assurances they have are commercial and process-based.

We in the security world have to make people understand this issue, and realise that if they are looking after our data, they need to find ways to protect it with strong technical controls. These controls are few:

  • architectural: never deploy sensitive data to the public cloud, ever.
  • HSMs: use Hardware Security Modules. These are expensive, difficult to use and don’t scale, but they are appropriate for some sensitive data.
  • Confidential Computing: use Trusted Execution Environments (TEEs) to protect data and applications in use[1].

Given my interest – and my drive to write and publish my book – it will probably come as no surprise that this is something I care about: I’m co-founder of the Enarx Project (an open source Confidential Computing project) and co-founder and CEO of Profian (a start-up based on Enarx). But I’m not alone: the industry is waking up to the issue, and you can find lots more about the subject at the Confidential Computing Consortium‘s website (including a list of members of the consortium). If this matters to you – and if you’re an enterprise company who uses the cloud, it almost certainly already does, or will do so – then please do your research and consider joining as well. And my book is available for pre-order!

10 ways to avoid becoming a start-up founder

It’s all rather like hard work, and so best avoided at pretty much all costs.

In last week’s article, I announced the start-up, Profian, for which we’ve just got funding, and of which I’m the co-founder and CEO. This week, I want to give you some tips so that you can avoid the same fate that befell me: becoming a founder, a role which is time-consuming and stressful. Just getting funding can take (did take, in our case) months of uncertainty and risk, and then, when (if) you get funding, there are the responsibilities towards your employees, your investors, government, the law and all the other pieces that whirl around your head (and into your inbox). It’s all rather like hard work, and so best avoided at pretty much all costs. Here’s my guide to doing that.

1. Avoid interesting work

Probably the biggest reason that I fell into the trap of starting a new company was that I couldn’t see myself doing anything other than working on Enarx, the open source project for which Profian is custodian, and on which we will be basing our products and services. I’d had other responsibilities in my previous job, but Enarx was what I cared about the most, and the idea of giving up working on it was unconscionable – I just had to do it. So started the quest to find a way to continue working on Enarx, and to do it full-time.

2. Don’t be passionate

It’s also probably best to avoid getting too excited about what you do. That way, you can give up after a while, and stop bothering your family and friends with your annoying obsession. Most importantly, investors are much less likely to give you money (not to mention customers much less likely to buy your products and services) if you’re basically luke-warm about the whole idea.

3. Work with dull people who you dislike

If you have the misfortune to enjoy spending time with your co-founder(s) and founding team, you’ll have less interest in working with them, not to mention working through complex and sometimes awkward topics such as how to split equity, who can absorb upfront expenses before funding comes through, when it’s appropriate for either or any of you to take some holiday (and for how long), and even more important questions like what colour your logo should be, and what font family best defines your brand. If you don’t like your team or co-founders, or find their company uninteresting, you are much more likely to give up on working with them, hence avoiding getting too far down the start-up road.

4. Ignore customer need

You may not have actual, paying customers early on (we don’t, yet), but at some point, you are probably going to need to get some. And one of the things that investors seem completely fixated on, in my experience, is how you’ll get revenue (very customers). The investors seem to think that you should listen to customers and gear what you’ll be producing to their (the customers’) needs and requirements. This suggests that your vision for the company should be diluted – nay, adulterated – by the market, as opposed to what you want, and what you think should be happening. In the very worst case, your investors may require you to talk to actual people from actual possible customers. If you can ignore their views, you’re much less likely to have to accept funding, and can give up much earlier.

5. Assume you know best

Related to our last point, if you know best, then you don’t need to take advice from anyone. Possible investors love providing their expertise and experience, and there’s a wealth of material in blogs, wikis, podcasts, news articles, LinkedIn posts and beyond which allow you to tap the collected wisdom of thousands of people who’ve trodden similar paths before you. The excuse you can give is that they can’t all be right, so rather than listening to the various advice you’re offered (for free!), reading, listening to and watching the various sources and then taking the time to sift through them all and work out what’s relevant and useful, you might as well assume that you know best (and always have done), and keep plugging away at what you’re already doing. This is almost guaranteed to remove any chance of funding (let alone anyone wanting to work with you).

6. Set your pitch deck in stone

Before I started on this journey, I’d heard about pitch decks: they’re what you show to possible investors to try to interest them in working with you. They should be short, punchy and lacking in extraneous information. I could have suggested long, waffly decks with random cat pictures and irrelevant market sector data, but I think that an even safer way of avoiding attracting interest for your start-up is to create a one-off pitch deck right at the beginning of the process and then never to change it. This is related to the previous point about knowing best, but the pitch deck is such an important tool in the journey towards creating your start-up that I felt it was worth its own section. As you learn more (well, assuming you do – see last point) and get more advice, the way you present your great idea for the company, if not the idea itself, will change. Having a pitch deck which reflects this new, improved thinking, will only aid you on your path, and as we’re trying to avoid such a dangerous move, you’ll want to have a single pitch deck, crafted at the beginning of your quest, and completely immune from improvements or changes of any kind.

7. Tell investors what you assume they want to hear

This one is a little counter-intuitive. You might assume that telling people what they want to hear is a sure-fire way to ensure that they give you money, and will therefore make you more likely to end up as a founder. But no! If you tell people what you think they want to hear, rather than what you actually believe, investors will either see through you (most of them have met many, many founders and heard many, many pitches – they’re not stupid) and reject you, or you’ll end up with a bunch of investors who actually think you’re doing something completely different to what you want to do, and things will fall apart as soon as it becomes clear that you’re not aligned. This is likely to be around the time that you’re getting into the nitty-gritty of your business plan or agreeing final terms, and is a pretty safe way of guaranteeing that everything will implode just in time to stop you having to becoming a founder.

8. Reject support from friends and family

I mentioned, right at the top of this article, that the journey to founding a start-up was long and stressful. Well, there’s a possibility that, from time to time, friends and family will want to discuss things with you, and offer you support to get through the hard times. Taking this sort of support significantly reduces that likelihood that you’ll burn-out before the process is complete, as they may help you to keep some perspective, provide emotional support and generally keep your mental health on an even keel. Crashing and burning because you’ve failed to accept support offered by people outside the process, who can see things in a different light, where the entire world isn’t bounded solely by just incorporating the company, getting through the funding round, hiring your first employees, filing initial tax returns, setting up bank accounts and the rest, is an easy way to avoid becoming a founder. As an extra bonus, failing to involve your close family (spouse, partner, etc.) in the decisions about financial risk, likely time pressures, etc., is a recipe for family break-up if ever I heard one.

9. Remember it’s all about you

Who knows best? You (see above). Who’s running this show? You, again. Who’s this all about? You. Other co-founders, employees, investors, customers (again, see above) are incidental to the main event, which is you, the “hero founder” who will carry the company through thick and thin, providing the vision and resources to succeed, no matter what. This is the attitude you need if you want to alienate everyone around you (including family and friends, see above), and cause all your possible allies to desert you. Working as a collaborative team is so trendy and 21st Century: who needs support and buy-in when you have the drive to make it all happen yourself? Well, the answer will be you, as you won’t have any funding, employees or customers – but that’s what we were trying to avoid in the first place, right?

10. Don’t take any time off

You can fail to do all of the above, ignoring my advice and setting yourself up for a collaborative, well-funded, supported, successful company and still fail with this one, simple trick: make your entire life – every waking moment, every dream, every action, every thought and every word – about the start-up. Find no time for anything else. Become unhealthily obsessed with the company to the exclusion of all other. And you will fail. Taking time off would help recharge your passion, give you insights into other people’s views, allow you to accept support from friends and family and give you a sense of perspective: all things we’re trying avoid in our quest not to become the founder of a start-up. Refusing to take time off might seem like a way to concentrate all your efforts on succeeding, but in the longer term, it’s the opposite.

Summary

I find that writing “how not to” articles is a useful and fun way to provide a different perspective on sometimes important topics. I can’t pretend that the road to start-up foundership has been easy, nor that I’ve avoided taking some of the advice above, but it’s certainly exciting and worthwhile. And I wish I’d seen this article, or one like it, before I started.

Announcing Profian

Profian, a security start-up in the Confidential Computing space

I’m very excited to announce Profian, a security start-up in the Confidential Computing space that I co-founded with Nathaniel McCallum, came out of stealth mode today to announce that we’ve completed our Seed Round – you can find the press release here. This is the culmination of months of hard work and about two years of a vision that we’ve shared and developed since coming up with the idea of Enarx. Profian will be creating products and services around Enarx, and we’re committed to keeping everything we do open source: not just because we believe in open source as an ethical choice, but also because we believe that it’s best for security.

Enarx grew out of a vision that we had to simplify use of Trusted Execution Environments like AMD’s SEV and Intel’s SGX[1], while not compromising on the security that we believe the industry wants and needs. Enarx aims to allow you to deploy applications to any of the supported platforms without needing to recompile for each one, and to simplify both the development and deployment process. It supports WebAssembly as its runtime, allowing a seamless execution environment across multiple hardware types. Engineering for Enarx was initially funded by Red Hat, and towards the end of 2020, we started looking for a way to ensure long-term resourcing: out of this Profian was born. We managed to secure funding from two VC funds – Project A (lead investor) and Illuminate Financial – and four amazing angel investors. Coming out of stealth means that we can now tell more people about what we’re doing.

Profian is a member of two great industry bodies: the Confidential Computing Consortium (a Linux Foundation project to promote open source around Trusted Execution Environments) and the Bytecode Alliance (an industry group to promote and nurture WebAssembly, the runtime which Enarx supports).

The other important thing to announce is that with funding of Profian comes our chance to develop Enarx and its community into something really special.

If it’s your thing, you can find the press release on Business Wire, and more information on the company press page.

A few questions and answers

What’s confidential computing?

I tend to follow the Confidential Computing Consortium’s definition: “Confidential Computing protects data in use by performing computation in a hardware-based Trusted Execution Environment”.

What does Profian mean?

It’s Anglo-Saxon, the language also sometimes called “Old English”, which was spoken in (modern day) England and parts of Scotland from around the mid-5th century BCE to 1066, when Norman French had such an impact on the language that it changed (to Middle English).

One online Anglo-Saxon dictionary defines profian thus:

profian - 1. to esteem; regard as 2. to test ; try ; prove 3. to show evidence of ; evince

It’s the root of the English word “to prove”, from which we also get “proof” and “proven”. We felt that this summed up much of what we want to be doing, and is nicely complementary to Enarx.

How is Profian pronounced?

Not the way most pre-Conquest Anglo-Saxons would probably have pronounced it, to be honest. We (well, I) thought about trying to go with a more “authentic” pronunciation, and decided (or was convinced…) that it was too much trouble. We’re going with “PROH-vee-uhn”[2].

What does Enarx mean?

You’ll find more information about this (and how to pronounce Enarx), over at the Enarx FAQ. TL;DR – we made it up.

Who’s part of the company?

Well, there’s me (I’m the CEO), Nathaniel McCallum (the CTO) and a small team of developers. We also have Nick Vidal, who we recruited as Community Manager for Enarx. By the beginning of October, we expect to have six employees in five different countries spread across three separate continents[3].

What’s next?

Well, lots of stuff. There’s so much to do when running a company of which I knew next to nothing when we started. You would not believe the amount of work involved with registering a company, setting up bank accounts, recruiting people, paying people, paying invoices, etc. – and that’s not even about creating products. We absolutely plan to do this (or the investors are not going to be happy).

No – what’s next for this blog?

Ah, right. Well, I plan to keep it going. There will be more articles about my book on trust, security, open source and probably VCs, funding and the rest. There have been quite a few topics I’ve just not felt safe blogging about until Profian came out of stealth mode. Keep an eye out.


1 – there are more coming, such as Arm CCA (also known as “Realms”), and Intel’s TDX – we plan to support these are they become available.

2 – Anglo-Saxons would probably have gone with something more like “PRO-fee-an”, where the “o” has sound like “pop”.

3 – yes, I know we’ve not made it easy on ourselves.