‍

Richard Rodger:  [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started.

Let's get right into some highly effective, highly detailed developer relations strategies. I'm talking to Eoin Boylan, the CEO of Evervault, a startup that does encryption as a service. The challenge they have is getting developers to use a pretty complex API. It's not just your usual restful crud API to manipulate data. We're talking about encrypting; we're talking about edge functions, all sorts of fun stuff.

One of the things that they have discovered, sort of by accident, is the effectiveness of having private Slack channels per client. Now as a user of Evervault systems in the service of one of our clients, [onbanks.app?] Time: 00.01.01, I've learned to really appreciate this way of supporting developers who are using your systems. We also talk a little bit about their really excellent documentation flow and how that's such a critical part of developer relations. All right, let's get into it. [0:01:19]

Main Interview

Eoin Boylan

Richard Rodger:  [0:01:20] Eoin, welcome to the Voxgig podcast. It is great to have you here on. Tell us all about Evervault, your startup. And you guys have a couple of interesting challenges, because you're not just a run of the mill Rest API; you do some fairly complex stuff. [0:01:39]

Eoin Boylan:  [0:01:41] Yeah. I think that's a good summary. Thanks for having me first. Evervault is an encryption service for developers. We provide tools that simplify how you encrypt data. Some of the interesting parts of Evervault are specifically around how we integrate our encryption into the developer's stack., and then how we simplify all the problems that come about from when you encrypt data.

So, if you've ever used encryption before, the – half of the problem is getting the encryption scheme right, getting it set up correctly, making sure it's fundamentally sound. And then the other part is that you're now sending around encrypted data around your infrastructure, your apps, business logic. There's larger strings that are being stored in your database than there previously were. So, alleviating all of those problems that come about from encrypting data is the second half of what Evervault does. [0:02:45]

Richard Rodger:  [0:02:47] Awesome. It's – they key thing here, which is something I didn't get when we first spoke, is the whole point of what you guys do is that when I'm storing sensitive data in my system. And we experienced this with our mutual clients, onbanks.app, who are really cool, by the way; check them out.

The whole point is, the – you – I as the developer, or the company that I work for, I never want to actually deal with the plain text, the unencrypted data. I want to – I'm using you as a service provider. I only ever want to see encrypted data. And then you have this issue where of course I have to do some sort of processing on the data, and you provide edge functions to do that, which is really cool.

But the whole thing sums together to an essential service that lets you deal with things like sensitive personal information, financial information, that type of stuff. But it's not as simple as just calling a Rest API to get some data and doing stuff done. So, you have this huge challenge around developer relations, onboarding, and getting people to even understand the basic concepts.

Let's maybe take a historical view of this. So, take us through the conception of Evervault right from the beginning in terms of conceiving of the problem. And then, not so much the startup business story, but the story of how you worked out how to engage with developers. [0:04:25]

Eoin Boylan:  [0:04:30] The initial problem that Evervault tried to address was data breaches. And when we looked conceptionally at the problem and you look at how data breaches occur, there's two main ways that that happens. Usually it's either through social engineering by one of your employees; clicks on an email or picks up a USB device, and then your infrastructure's compromised or there's vulnerabilities.

And if you look at – there's lots of tools for dealing with this, but if you look at vulnerabilities in particular, because of the amount of zero days that are out there right now, it's almost impossible to fully protect yourself from vulnerabilities. So, the next thing that we looked at was, what about the data itself, and could you obfuscate the data; could you anonymize it? And then we looked at encryption as another alternative to that.

The philosophy behind Evervault is that if you do have a data breach and your data is encrypted, that data is useless to the attacker. So, under that model, Evervault stores the keys and you store the data, which means in the event of a data breach, you have to both compromise the customer and Evervault itself. So, it increases the layers of the onion, which is a common analogy that is used in security. If we step back from that – sorry, I've lost my train of thought there, Richard. Do you want to repeat what you just said? [0:06:06]

Richard Rodger:  [0:06:07] We're talking about you guys – basically what you're doing is the [defense in?] Time: 0:06:10 depth, because everyone has to compromise, both your client and you. [0:06:16]

Eoin Boylan:  [0:06:19] Yeah. The – one of the interesting things you said when you started was that plain text data doesn't arrive in your infrastructure, which was the – which is the differentiator between Evervault and what exists already. There's plenty of ways of doing encryption right now. You can do it at the field level with your database. There's Cloud HSMs; there's things like HashiCorp Vault.

The common problem with them though is, the keys are also stored in your infrastructure, which means that if there is a vulnerability, some remote code execution or an attacker gets actual access to your systems, there's a high likelihood they could compromise both the key and the data itself, which can make some of these existing encryption systems almost redundant. [0:07:08]

Richard Rodger:  [0:07:10] Yeah, exactly. The nice thing about your system – I'm a developer using your system – is that we never go near the keys. It's really funny; in your API, there's an encrypt method, but there's no decrypt method, which is – I looked at your API the first time and I was like, "What?" [0:07:29]

Richard Rodger:  [0:07:30] Yeah. The – when you – as soon as you bring around decrypt, obviously, that involves a key. And if you need to expose the key to the developer, then you've ended up back to the problem that you're trying to solve again. Is that now the developer has both the encrypted data and the keys, which defeats the point of Evervault. [0:07:49]

Richard Rodger:  [0:07:49] Yeah, exactly. So, you guys could do everything right in terms of normal developer relations; have lovely documentation and code examples and all that sort of stuff. But that's – those are just hygiene factors these days. But how have you addressed this issue or how do you – how did it go as you went from the start of the company and you started engaging with developers and you started trying to explain this? [0:08:16]

Eoin Boylan:  [0.08:19] When we actually – sorry. [0:08:20[

Richard Rodger:  [0:08:20] How did you find that and how did you address getting that idea into people's heads? [0:08:23]

Eoin Boylan:  [0:08:26] When we started, we started on the – we had a very simple SDK that allowed you to encrypt. But it's actually in the browser and it allowed you to do encrypt data that was coming out of forms. And then we would use this encrypted data in our own applications.

And then slowly discovered, now that you have all this encrypted data, the decrypted part is the next challenge that you have to solve. The problem with that is that it involves the keys again. Where are you going to do that decryption? And then that evolved into the creation of our product, which is Cages, which allows you to send that encrypted data into a secure processing environment and decrypt it.

That's how the product evolved conceptually, but the main problem that we had then was trying to explain to developers how you would take code that exists in their back-end API, transplant it into Evervault systems and then interact with it over http. That was quite a challenge and was a large blocker to adoption.

What changed it was the next product that we came up with, which is Relay, which sits in between – well, it's a proxy, effectively, that sits in between your client and your back end and will automatically encrypt data. Once developers were like, okay, I don't have to go around my entire – every form I have, every field in my UI and start manually putting in all these encrypt calls to an SDK. I can just set up Evervault, point my domain to it; it sends it to my back end now, and then I can literally in a UI just click what I want to encrypt. That solved a tot of the initial hurdles that we have of onboarding developers into the products. But still working on that. [0:10:19]

Richard Rodger:  [0:10:21] And on that – so that feature came directly from feedback. Or for – or perhaps not from feedback, but you were paying attention to the onboarding blockers where people got confused. But how did you know that? Were people sending you messages saying, "I don't know how do this bit?" Or were you getting feedback? Did you have a booth at a conference where people were going, "Yeah, but I can't (inaudible, 0.10.43) this or-

Eoin Boylan:  [0:10:46] We'd actually do a lot of sit-down installations, so get your laptop, find a developer; get them to install Evervault, and then watch them as they use your SDK. This is, I think, a pretty common technique used by companies that come out of Y Combinator, but [0:11:03]-

Richard Rodger:  [0:11:04] This is the Stripe forced pair (inaudible) 0:11:06?

Eoin Boylan:  [0:11:06] Yeah, the Stripe installation I think is famous for. But it's an incredible tool for – or an incredible way of finding out exactly how developers interact with something that you've built. because you have all these built-in biases when you start building your own product. And then you assume that everything is wonderful because you've used it. And then you give it to someone who has never used it before and then they're just – they're using it in a completely different way.

They'll discover all these edge cases. The way that they write code is different to the way that you write code. The way that their system is setup is different to the way that your system is set up. But when you just sit down with them, run through exactly what they're doing, you can learn an insane amount of information.

So, what we would see then is that engineers would go into their application and they were just manually writing: encrypt, encrypt, encrypt, encrypt. All the time, for all these different places across their app. And we were like – this is literally the time to write the code was taking too long. There was too much of a barrier there; it was purely a frustration for developers.

So, one of the interesting things about what we do is that encryption is something that's – it's nice to say that everyone should be doing it, but it introduces a lot of complexity. So, bringing down those barriers, so reducing the amount of times that you have to call a function in an SDK. Reducing the amount of, say, setup that you have to do to integrate with our Relay product.

We optimized for that, so the least amount of touches that the developers would have to do to get encrypted, and it's something that we track. So, if you install Relay at the moment, you can literally get Relay up and going by changing a DNS record, and that's it. You can go into our UI then and start encrypting data. You don't have to call hundreds of functions and start playing with encrypting data all over your applications; it's as simple as changing a DNS record. [0:13:04]

Richard Rodger:  [0:13:05] Yeah, having used it myself, that is really nice, and it's interesting, because looking at your documentation, there's not actually a huge amount to learn, there's a very small number of methods. And with this Relay thing, you just call the new end point which is – gives – in the browser gives you plain text. So, everything is normal; it's just another GraphQL, Rest too, whatever.

And then at the back end you get gobbledygook, which is overly encrypted cybertext and – stored in the database, whatever. And it is nice and seamless, the way that that' fits together. Have you stopped doing the shoulder-to-shoulder pair programming; show us how you do things? Or is that still a fundamental thing that you guys with engagements now? [0:14:00]

Eoin Boylan:  [0:14:01] We've evolved it, I would say now, to the point where, when the customer onboards with Evervault, we set up an engineer-to-engineer Slack channel. And then as they're going through the process we just make ourselves available, basically 24/7, to anything that they encounter, any questions that they have.

If they want to jump on a call, if they want us to write some code for them, we make it clear at the beginning of the integration. We're here almost like a personal assistant for you to integrate Evervault. Ask us; there's no dumb questions. Ask us whatever you want. We're here to help with the integration process. [0:14:37]

Richard Rodger:  [0:14:38] And who's on the Slack channel? [0:14:38]

Eoin Boylan:  [0:14:38] Usually right now, that's – sorry? [0:14:40]

Richard Rodger:  [0:14:40] Who is on that Slack channel? Is it a first line support or is it your senior [0:14:44]-

Eoin Boylan:  [0:14:45] No, it's engineers. Usually what we do is – it's actually part of our on-call rota. Every week an engineer is on call at Evervault and that engineer is also responsible for responding to support tickets that come in from – well, they're not support tickets. This is something that we can talk about in a minute.

But when we set up these channels as soon as someone integrates, the on-call engineer is responsible for responding to any Slack messages that come in from the other company's engineering org. And then they're – they might not necessarily have the answer, but it's their responsibility, almost like a support agent, to figure out exactly who's responsible for this problem. And then can they get the solution out back to them as quickly as possible.

That's, I think, one probably part of engineering support that really annoys a lot of people, is that everyone's familiar of the process of, you go – you have some problem with some tool that you're using. You create a support ticket; you get an email thread back from someone who has – is in charge of delegating where it should go to inside their own company.

A couple days later you get a response back. But in that time period that's occurred, you've already solved the problem or you've figured it out or you've found an issue on GitHub or something like that. But with engineer-to-engineer Slack channels, there's no way around that. It's direct communication. You get the issue or you figure out what the problem is as quickly as possible; you get the response to the customer as quickly as possible, which in our case is the developer. [0:16:20]

Richard Rodger:  [0:16:22] Let's dig into this a little bit more, because it is – speaking as a user developer, it's a great experience. So, you’ve scaled the pair programming onboarding sale by moving to Slack channels, and that lets you support hundreds and hundreds of customers. And then you've had to scale those by developing internal processes that fit around your – who's on call, that type of stuff.

But you mentioned support tickets. So, if a query comes in which – some queries are just informational. But if a query comes in which requires dev on your end, let's say, and that dev might be building an example or changing new release or something. How do you manage that? how do you fit it into your dev process? You'd have – you don't have tickets, so how does that work? How do you scale it? [0:17:16]

Eoin Boylan:  [0:17:19] It's just about prioritization. There's a clear understanding amongst the engineers that the customer comes first, the developer comes first. And if it is an issue, what happens is, the on-call engineer can redirect the issue to the team that's responsible for that. And then it's the team's responsibility to decide, okay, what is the problem with this? Do we need to put some time into investigating the issue?

And then whatever's going on in the team right now, that issue will supersede. If it's releasing a new feature or they're working on some sort of bug or doing some sort of day-to-day engineering work, the customer issue takes priority over what's already on their queue. That's – honestly, that's not probably going to scale up to thousands of customers; I don't think that could ever work.

But right now, in the stage that we're at, when your product is very early, when – a lot of these problems as well is that – it's actually surprising. It's always at the integration phase. So, when the customer runs through the integration phase, once they get going, there's very few problems that arise after that. So, it's a very short-term situation for each customer.

The onboarding period for Evervault right now is about three days, so after that three-day period you – if it's in regards to a problem, there's always – engineers are always asked, like, is Evervault a suitable way to do something? Can we use it with this use case? Those are questions that can be answered by non-engineers. But in terms of actual engineering problems, past the three-day period, it starts to calm down quite dramatically. So, we've been able to scale it like that. [0:19:10]

Richard Rodger:  [0:19:11] Yeah, so there's a spike. But the ability to scale this very hands-on Slack channel approach, you'll probably scale it quite a lot without overburdening yourselves too much. Is it something you guys can still manage? Do you feel that it's becoming too much or is still well within normal operational limits? [0:19:41]

Eoin Boylan:  [0:19:43] Right now, it is definitely within operational limits. It's also – in Evervault we call every engineer a product engineer. It's something that – I think a differentiator is that the – there is – if you look at a traditional engineer career ladder, Evervault's engineer career ladder contains an entire column or a column in the grid matrix that everyone's familiar with. That's specifically about product.

Because we build a developer tool for developers, when we're having these initial integration discussions, it doesn't matter on the size of the customer or what language they're using or what framework they're using. We'll always discover something new and some new ways to improve the product.

So, we'll – like you said in your own experience, using Evervault, you got a response that Evervault hadn't seen before, even though we talk to thousands of APIs, which we then had to build into the product. So, a lot – I would say 70% of our product features come out of a lot of these early integration discussions with engineers. We'll figure out a new way that a framework works or a new way that someone's using an SDK, or they're using some library that we've never heard of. Or that their actual deployments that they do or where they're deploying code is different to some other customer that we've had.

So, it's – even though it might be an operational overhead, the value that we're getting from those conversations is so high, we want to keep it for as long as possible. And we don't want that to get lost in the ticketing system either, which I think is incredibly important. Because you have that automatic chance to ask the engineer on the other end of Slack exactly how their system's set up.

What languages they're using, what frameworks they're using, what versions they're on. And you can get it instantly, as opposed to going through weeks of email threads trying to find this stuff back, even if people do reply. Because I think a large part of the problem with tickets is that you might not ever get a response in the end, so the information is lost. [0:21:46]

Richard Rodger:  [0:21:48] Yeah, I'd certainly – it's certainly a much better experience from the developer side. I have seen other people using Slack channels, but they're more – they're shared channels, so, you're fighting everybody else. And then you can't really discuss anything sensitive; you can't get to the heart of the matter. [0:22:05]

Eoin Boylan:  [0:22:06] Yeah, it's almost been replacing the Google Groups style, for a company – the company communications, where there's multiple people trying to figure out how to integrate something. They have all the stakeholders in there and everyone's trying to blame each other. I think everyone's – or most people will be familiar with how these shared channels go. But no, these are a bit different, direct engineer to engineer channels. [0:22:29]

Richard Rodger:  [0:22:29] Is this something you came up with, or was somebody else doing it and you kind of picked up on it? Where did the original idea and [0:22:36]-

Eoin Boylan:  [0:22:38] I think we accidentally stumbled into it; I think a customer might have asked us could they do it. Because previously before that, we would have our support address, where you could email directly the engineering support or the Evervault support team, which back then would go directly to the engineers. But someone then, I think, asked to say, "Could we set up a channel where we can just talk directly from our engineering team to your engineering team?"

And we were like, "Sounds like a great opportunity for us to figure out more about how your systems work."  And Slack is so good for doing instant communications, it seemed like a no-brainer. And from there, every time now when a customer signs up to Evervault, they have the option to create a shared channel with our engineering team and ask whatever questions they like. [0:23:30]

Richard Rodger:  [0:23:32] Yeah, and off you go. And it's been critical to the success that I worked on, which actually generated an interesting little challenge. In the process of what we were working on, you ended up – your SDK ended up needing to magically bind itself into the http agent of the system we were using, the node system we were using. Because we had a dependency on other third-party SDKs, where we couldn't change the host.

So, that seems like something that you necessarily have to do. But my developer bones are just going, "Man, that's such a bad code smell. Magic." It's like the sin of adding custom methods to the string object; do that sort of thing.

So how do you deal with something like that? Because it's necessary and has to be done, and it doesn't feel like there's another solution. But then you may lose sales over it, because an architect might simply go, "No way, this is crazy. These guys are doing crazy things. We can't have that in our system." [0:24:53]

Eoin Boylan:  [0:24:55] So, I can – that feature, which is a feature of our Relay products, which is for all intents and purposes a forward proxy that will decrypt data as it leaves your infrastructure. We created the product first, so we created the proxy and then we had the challenge of integrating into everyone's development stacks.

When we came to that challenge, one of the things we're doing – so, it runs over https. There's a part of https that does proxying, in the protocol itself. But one of the large problems is that setting it up is quite complicated. You have to download a CA cert from Evervault; you have to trust that CA cert and then you've to send the connection over Evervault's – through Evervault's Relay products.

Doing that is a bit of a pain, and when we – we came to the decision. How much of the Magic should Evervault do and how much should the developer too. And the developers want to be downloading CA certs, installing them in their infrastructure, configuring them; refreshing them whenever they expire. And we made the decision that that's probably too much to do to get adoption in the products, so we take care of that for you automatically.

Now that – the way that it works is completely language dependent, because every language implements https proxy in completely differently. Java, node.js implement it in two completely different ways. Because like everything else in programming or in software engineering, you read an RFC doc and it's up to you to decide how you want to implement it. C#, for instance, doesn't even have support for https proxying.

So, there's – when we looked at the challenge that it was going to –  what the developers would have to do in all those different languages, we were like, "Okay, we can abstract away as much of this as possible," to the point where you can just install the SDK; enable Relay, decide what domains you want to send decrypted traffic to.

And it would automatically just send it through and it would end up in your destination in a decrypted state. That – the timeline of that was that originally what you would actually do is install the Evervault SDK, and it would automatically route all of your traffic through a Relay. Now that broke everything [0:27:22] --

Richard Rodger:  [0:27:23] Of course.

Eoin Boylan:  -- [0:27:24] immediately. So, this is one of these biased things where you're like, working my little local development and then in our testing of our – this works great. And then you install it into a customer's infrastructure and their database breaks. Because now they're trying to put a private database connection through an external third party. So, okay, this is a terrible idea.

So, then we started to bring in feedback from the guys; okay, how much of this do you want under your own control. And we ended up in the spot where it was – where you would decide, okay, I just want to add – I just want to send traffic to these domains. Only send traffic that's going to, say, Stripe or Adyen. That's the only traffic I want going through Evervault. So, you can configure that now through the SDK and that's homogenous across all the languages. [0:28:12]

Richard Rodger:  [0:28:15] And greatly appreciated. I don't know do you remember in the first dotcom boom there was an Irish company called Baltimore Technologies. [0:28:20]

Eoin Boylan:  [0:28:22] I do not [0:28:22].

Richard Rodger:  [0:28:23] They were the first Irish unicorn on the London Stock Exchange, I believe., a brief shining light. And you've just triggered some developer PTSD for me, because I do remember using their encryption product, and I do very much remember having to install local CA certs. And it was an absolute and utter nightmare. [0:28:49]

Eoin Boylan:  [0:28:51] Yeah, it's an interesting – the way that that product worked is quite interesting, because it's effectively a man in the middle server. which isn't something that – everyone's familiar with a reverse proxy, because everyone uses reverse proxies as load balancers, inside [Cuban Eddies?] 0:29:08, wherever.

Using a forward proxy, you're probably – a developer's only experience with a full, like http proxy is probably something like a web filter installed by the IT department. Or if they're pen testers, it's when they're running pen tests. It's not something that you interact with very frequently at all.

So, one of the challenges with Evervault and what we're trying to still do now is, some of the stuff that we've done is conceptually unfamiliar to developers. So, when we send this traffic out through a relay from your infrastructure – because that's not something that developers are familiar with, going that way, forward, out of your infrastructure and not reverse coming in. They're like, "What's happening here?  How does this work?  What is this Magic?" 

But then if you delve under the hood, read the documentation, you're like, "This is really simple. It's just whatever documentation I put into the SDK, it will do a forward http proxy to that location and do a TLS man in the middle." But if you just install the SKD and it just happens, everyone loses their mind. So, bringing in more context to the developer about what's actually happening is something we've been working on for the last, say, six months. [0:30:26]

Richard Rodger:  [0:30:28] Yeah. Definitely the experience and how you do the traceability and all that sort of stuff is absolutely key. Let's talk a little bit about the more traditional side of developer relations. Do you guys do all the traditional stuff as well? Do you go to conferences? Do you do blog posts; peak at meetups? How is that [0:30:57]-

Eoin Boylan:  [0:30:57] Yes.  We do ] 0:30:57]-

Richard Rodger:  (Inaudible, 0.30.57) -where does that fit in your strategy, developer relations strategy? [0:31:03]

Eoin Boylan:  [0:31:05] That's what we have been doing., I'd say, since the conception of Evervault, but it's hard to get notice, I'd say, in the noise. So, we've been more careful about where – what conferences we go to, which ones make sense for Evervault. What software we – where the developers that would be most interested in Evervault, what conferences are they going to be going to.

So, if you're dealing – if you're using Evervault as a product, you're more than likely doing something with sensitive data. There's some conferences out there that are specific to, say, health data. There's Health in Las Vegas next week, which I think is the largest health tech conference, and then there's all the open banking conferences.

So, making yourself – building the Evervault brand in those conferences is – has been an approach that we've taken, as opposed to going wild across everything that we could possibly go to. Because there is a point of diminishing returns and they are quite expensive, so you gotta be careful about how you approach that. And then the other thing that we've been doing is, for hiring, it's quite important. So, Evervault is – I think about now at this stage, maybe 70% of our stack is written in Rust, which [0:32:31]-

Richard Rodger:  [0:32:31] Wow. Sexy. [0:32:33].

Eoin Boylan:  [0:32:33] Yeah. Well, it's interesting. Because of the low-level systems that Evervault interacts with and because of the encryption, we ended up working with a lot of C libraries. And we've ended up having to interact with the kernel quite a bit. So, we were – initially, when we were creating Relay, Relay is underpinned by confidential computing. And interacting with these trust execution environments, you have to go down to the – quite a low level.

And one of the decisions we made was, okay, we're not going to write all this low-level code in C or C++. We didn't at the time have any experts and we thought that would be a bad idea. Rust had just – it was getting more mature; this was probably about two and a half years ago. So, we were like, "Okay, we'll try Rust."

One of the problems we did though have immediately was that no-one in Ireland knew anything about Rust. There was, I think a developer meetup with five or six people in Dublin and that was it. That was the extent of the Rust experience. Now what we do is, we sponsor the Rust meetup; we give talks at the Rust meetup, and then that's how we'll attract talent, developers to Evervault as well. [0:33:52]

Richard Rodger:  [0:33:54] I think that's an interesting aspect of developer relations, that a lot of people don't – it doesn't get much emphasis. But not only does it help you sell your product, but it's a huge benefit to recruiting. [0:34:09]

Eoin Boylan:  [0:34:11] Massive, yeah [0:34:11].

Richard Rodger:  [0:34:13] Almost as important, right?

Eoin Boylan:  [0:34:14] To differentiate yourself against – obviously, we've been through a massive tech hype cycle over the last few years. And if you're a smaller company, getting your brand out there so that developers know who you are. So, when you're – if someone reaches out to them from Evervault, they already know who Evervault is. They've been to the website; they understand the products. They understand that we're working with Rust and encryption and some quite interesting things. Getting that out there and -- in the large Dublin tech community is quite important. It's helped us massively. [0:34:50]

Richard Rodger:  [0:34:50] And do you guys – you contribute to the open source community around Rust, libraries, that type of stuff? [0:34:59]

Eoin Boylan:  [0:35:00] Yeah, so that's one of the biggest problems [0:35:01]-

Richard Rodger:  [0:35:01] If you have a proposal on the go on – you have projects, that type of thing? [0:35:03]

Eoin Boylan:  [0:35:04] Yeah. There's a few that we sponsor that we don't use, which is primarily because we use Rust. So, there's – probably the most popular open-source crypto library is libsodium, which is written in C++. So, Evervault sponsors that, to help the devs maintain that, just as more of a community effort to show we actually do care. Even though libsodium is nothing to do with Evervault, it's the most popular used encryption open-source library out there. So, it's important that – we think it's important that that is [0:35:35] -

Richard Rodger:  [0:35:35] Good signal, right? [0:35:36]

Eoin Boylan:  [0:35:36]-- is secure. Yeah, it's that – yeah, it's a good signal. and then other than that then, one of the problems we had originally with Rust is that a lot of Rust libraries are just [etifying?] Time: 0:35:49 into C, which means that they're just wrappers around existing C libraries. A lot of them are incomplete, unmaintained.

So, what we've been doing recently is bringing a lot of these libraries in house, running through them, auditing them ourselves, then re-releasing them back as open-source libraries into the community. And over the next six months, there'll be three or four, encryption specific, but libraires that are – that Evervault will be maintaining themselves. Which are, frankly some very helpful ones that we've brought into our Relay products. Now that we've got them into production, we've used them and we're going to start breaking them off and bringing them back out into the open-source community. [0:36:38]

Richard Rodger:  [0:36:39] I'd certainly like to have you in my supply chain, all right? That would be – (marketing) Time: 0:36:39 node world supply security is – don't be [0:36:49]  -

Eoin Boylan:  [0:36:50] That's-

Richard Rodger:  [0:36:50] Don't even think about it. Don't think about it too hard and just hope [0:36:52]…

Eoin Boylan:  [0:36:53] That's the other 30% of our stack. [0:36:54]

Richard Rodger:  [0:36:55] Yeah. A final topic – this has been really great, but a final topic then just to close out is, what tools do you use for developer relations? Obviously, Slack and things like that, but do you use any of the community management tools like – I don't know if you know of Orbit; Orbit.love is the website. Or basic forum software or any of that sort of stuff.  [0:37:24]

Eoin Boylan:  [0:37:26] No, we haven't used anything to manage our developer community outside of Slack right now. I don't know. We've experimented now with the idea of setting up a Discord. Or – it's more – that would be for people – developers who are interested in Evervault who don't necessarily want to sign up. Is – at the moment, there's no place other than email where if you're interested in Evervault conceptually and you don't want to go down, say, a traditional sales process, sales cycle, then you go in and just ask some questions about how the product works.

The biggest concern there for me is, that adds again to the operational engineer-to-engineer process that we have and you could end up getting completely swallowed. But that's – I think our next move is to go to Discord, which I think is becoming more and more popular from a lot of projects. [0:38:28]

Richard Rodger:  [0:38:30] And would you consider things like – one of my former business partners has an AWS consultancy; fourTheorem.com, they're called. And they do a weekly 15-minute podcast, live coding chat type thing, delving into the depths of AWS APIs. [0:38:48]

Eoin Boylan:  [0:38:50] Is this a shoutout to AWS Bites? [0:38:52]

Richard Rodger:  [0:38:53] Absolutely, right.  Yes, exactly. [0:38:54]

Eoin Boylan:  [0:38:54] Yeah. Very familiar. [0:38:55]

Richard Rodger:  [0:38:55] Great. It saves my life on a weekly basis. And then another former colleague of mine, Matteo Collina, has a new startup; he was our previous guest. And he does – he started doing live coding on Twitch. Is that something you guys would do or think about doing? Does it fit into your approach [0:39:17]-

Eoin Boylan:  [0:39:17] We're – started something similar, but it's a lot smaller, shorter clips. Similar to how AWS Bites, which is small, short videos on how certain topics in AWS work. We're doing it for certain features within Evervault. So, now, when we – every time we release a feature, we record a 1-2-minute demo of how you're use that feature. We'll write some code live on the demo and then that can be turned into a GIF and put in our docs, so you can always reference it.

Or we can send it out to developers and – how does – how do we set up Relay with Java or something? We just send them a short, two-minute video that literally shows us quickly write the code. Because it is simple enough where you can write it in two minutes, and then sending that out to them, and then they can reference in the docs later on.

This is something that – that's what we've been doing over the last two months, and something that we're going to continue doing. Because it's been really helpful for developers. And it cuts down the amount of support you have to do inside Slack, and you don't have to jump on a call. You can just send someone a quick video and they get integrated. [0:40:22]

Richard Rodger:  [0:40:23] One final question. How do you manage the documentation? You have to document your API; you have code examples, all this stuff. [0:40:31]

Eoin Boylan:  [0:40:31] Yeah.

Richard Rodger:  [0:40:32] Any  particular tool [0:40:32]?

Eoin Boylan:  [0:40:36] We have an interesting process that we've – I think it came from Amazon – which is that you write the docs upfront when you're building features. When we're adding a new functionality to, say – if we're adding some new scheme or we're adding a function to an SDK, we'll write the documentation for the SDK first and then implement the feature afterwards.

If it's something – an entirely new product that involves some new concept, we'll write out the documentation; put it into preview rel, send it around to all the engineers and make sure it all makes sense. And then from there, we'll start doing the technical implementation of the feature. It's working backwards ins the framework, but that's what we've been doing for documentation.

And then we build all of our own documentation tooling in house. We made that investment about two years ago. We looked at some of the more popular ones like Readwise and Gitbook, and decided that they all looked the same. And Evervault – we wanted to have the same branding across from our website to our app, to our docs; it was all unified.

And we didn't have the – it didn't allow us to customize it the way that we wanted. So, we put the investment into building our own docs, which is an XJS app that's backed up by Sanity, the CMS. So, anyone in Evervault can – if you're technical or non-technical, can edit the documentation; add new things through the Sanity CMS/Headless CMS system. And then the rendering layer is all in Next.js. [0:42:16]

Richard Rodger:  [0:42:17] Lovely. Yeah, I'd be – that idea is something I should follow in some of our own open source. Writhe the docs first, because they never get written afterwards. [0:42:26]

Eoin Boylan:  [0:42:28] Yeah, that's – or you release something and then someone finds something that's undocumented, and then you realize, I never wrote the docs for that. [0:42:35]

Richard Rodger:  [0:42:36] Our COO, Sinead Quealy, would love you guys. She'd [0:42:40] to write any more docs, and rightly so. [0:42:42]

Eoin Boylan:  [0:42:43] I think probably he more recent thing is that Stripe have released their documentation system [0:42:50]-

Richard Rodger:  [0:42:50] Have they?

Eoin Boylan:  --[0:42:51] as open source. So, we've been, in the last – only the last two weeks been doing a little text spike into seeing how that work, because there's some very nice functionality within that [0:43:02].

Richard Rodger:  [0:43:03] Absolutely. I'm going to check that out after this talk. Very good. Eoin, thank you so much. It's been an absolute delight. [0:43:09]

Eoin Boylan:  [0:43:09] Thank you.

Richard Rodger:  [0:43:10] Loads of really good stuff. Certainly, a lot of food for thought. I love the per-client Slack channel thing; I think that's got to become a best practice. It definitely makes a huge difference. [0:43:25]

Eoin Boylan:  [0:43:27] I'll let you know how it scales. [0:43:28]

Richard Rodger:  [0:43:29] Yeah, that's the only – well, do things that don't scale, as they say. Thank you so much. [0:43:34]

Eoin Boylan:  [0:43:35] Thank you, Richard.

Endnote

Richard Rodger:  [0:43:37] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at Voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0:44:04]

‍