48. From NodeConf EU 2019

Julián: Hello, welcome to Code[ish]. I am Julián Duque, developer advocate here at Heroku and today we will bring you a community focus episode. Recently, I had the opportunity to speak at NodeConf EU, the main conference in Europe for the Node.js community hosted at the beautiful city of Kilkenny in Ireland. I was able to chat with different members of the community that also spoke at the conference and wanted to capture some of the conversations to share them with our Code[ish] audience. We compiled three different conversations into this one episode. We will learn from Alex Korzhikov about building CLI applications with oclif and TypeScript. Tierney Cyren will tell us how to build open source communities and some of the lessons learned by leading the community committee at the Node.js Project. Chris Dickinson will share the work he has been doing on a new shiny project, entropic, a federated package registry for Node.js and JavaScript.

Julián: With me I have Alex Korzhikov, which is going to be talking about how to build CLI tools using oclif and TypeScript. So hello Alex, how are you doing?

Alex: Hi Julián. It's good. Nice to meet you here. It's actually a big surprise to meet someone from Heroku in a Node conf.
<!– more –>
Julián: So Alex, why don't you introduce yourself?

Alex: Yeah, sure. Yes, I'm Alex Korzhikov. Exactly. The pronunciation is correct. Yeah. I am an engineer at a ING bank, it's a huge bank. It's originally from Netherlands and I'm working there for three years or living in Netherlands already for five years. And that I was mostly… my career was with the JavaScript. So I started with JavaScript professionally and nowadays I also do JavaScript within the bank.

Julián: Oh, nice, nice. And what type of applications are you building in the bank with JavaScript?

Alex: Yes. So it's actually quite nice. I'm a part of a pipeline support system in a bank. So we are building a pipeline for front end applications, which we have a lot in the bank, you can imagine.
<!– more –>
Julián: So Alex was giving a workshop here at Node conf Europe about building CLI applications, using oclif on TypeScript and for the people that doesn't know and for the listeners out there, oclif is a framework library to build up CLI tools that was originally created here at Heroku. And that's pretty much the technology that it's been used for, or Heroku CLI, and also for SFDX, which is the Salesforce CLI tool. So Alex, can you tell me a little bit more why you decided to do a workshop around oclif and TypeScript? Are you using it for your project?

Alex: So basically we considered different tools and the idea originally was to overview different landscape over the CLI. So we did some experiments with a commander JS with Glue Gun, with Warpole and a with a natural JavaScript CLI thing. Yeah. We indeed stopped with the oclif, I think it's because it's a first choice in my opinion with the CLIs nowadays. Well yeah, I can tell a little more about why, why it's TypeScript because it's supporting TypeScript, that's the first one. But also I think it's super powerful and it's so easy to write a simple application in oclif. Yeah, it actually took me just two hours to make a workshop CLI for exactly this workshop.

Julián: So Node.js has been known as a technology for building web applications, but you can see Node.js out in the wild, not only for web but for desktop applications using platforms like Electrum. But it has taken a lot of usage out there by building CLI tools. So oclif helps you to create CLI tools in an easy way as Alex was mentioning. And I am a little bit curious what you… what do you cover at the workshop you were giving here? What type of things and best practices, best practices you are teaching to your attendees?

Alex: All right, so indeed the idea, first, was to, overview, to try different technologies. But in the end we actually had to cut and cut materials. So nowadays a workshop consists of, we start with the basics, we start with doing just a simple CLI with just the JavaScript package.json, NPM and that's it basically. Then we do a slight more functionality in size. So parse flags and for that we also need to cover process .argv and so on. And then we actually introduced TypeScript to the project so we tried to migrate these JavaScript application to TypeScript. That's a first run of TypeScript in the workshop. And after that we do all the older exercises with just oclif itself.

Julián: So I'm curious about one thing, why using TypeScript to create a CLI application? What are the benefits behind it?

Alex: Well, in my opinion, yeah, TypeScript now, it's kind of almost the first choice for, let's say, community driven tools and the libraries. So if you need lots of collaborations for your tooling, if it's open source or if you predict that someone will actually make merge requests to your project, I think TypeScript can help a lot with that. Like if you have strict types and you have strict protocols so it's easier for developers just to use it to consume your code and to not make too many mistakes on it and actually to use it much, much easier.

Julián: That's a great point. I have seen lately TypeScript being used a lot on library development specifically for that purpose you can enforce types, you can enforce the method signatures and it's going to open a lot of doors for people that want to contribute to your project. And it is good to see in it also on CLI applications. Can you tell me a little bit more about the benefits of using a tool like oclif by building CLI tools. What are the type of features that oclif is offering you while doing your work?

Alex: Well, at some point I think oclif is quite simple to use, so actually it doesn't have so many abstractions to manipulate with, for example, it has hooks, it has commands, plugins. Yeah. I cannot name too much more, I think that's… yeah, maybe a few more abstractions that's inside the framework itself. But generally with these abstractions like commands, plugins and the hooks and then you can, you can actually build your application on top of them easily and then yeah, using these classes, doing the OOP with them appropriately. It's really easy to construct a CLI. It can comprehend all the needs that your customer would… how they want to use your CLI and so on.

Julián: In terms of developer experience and user experience, what things do I need to be aware of while buildings CLIs? What are going to be the recommendations to make a CLI tool that is going to be easy to use and intuitive to use for our user?

Alex: Yeah, exactly. That's also a part of our workshops. So we start with this, a theory pieces or something like that. So we introduce some basic principles, which by the way oclif was also following quite a lot and we learned a lot from the articles provided by Heroku by oclif. Yeah. So basically, I think I… the user, not, should not be stuck with your tooling and that's why you need a… why you need help messages, version from flags, and so on. And autodocumentation, of course, and here on the workshop, we heard already good tips for example, to autocompletion which oclif has a plugin for and yeah, things like that, I think.

Julián: Are you using this stack, oclif and TypeScript, at your regular day job?

Alex: Yeah, actually we have a product, it's internal for the bank. We build it indeed on oclif itself. So we split all the functionality into plugins and now we also wrapped it in a Docker image. So it is enabled, is available for our customers of our frontend pipeline, let's say it like that.

Julián: Oh amazing. And since oclif supports plug-in development it's also enabling you and your organization to have cross-collaboration with other teams.

Alex: Yeah, yeah, exactly. It happens like that. Yeah. So we have lots of merge requests because yeah, we, our team is also is… should provide other products, let's say it like that. Yeah. I don't want to dig into my share in details.

Julián: Sure.

Alex: Yeah. But in general, yeah. We are really awaiting for a merge requests and there where TypeScript helps and oclif helps as well.

Julián: So for the people out there that didn't have the opportunity to be at the conference and at your workshop, do they have the opportunity to see that material or that company if they want to follow the workshop themselves, if it's online?

Alex: Yeah, exactly. So the workshop itself is available and a CLI at [ENI.ts.df 00:08:47]. So all my GitHub is the same, the same address. And indeed we have some references for a further reason, let's say it like that. And to be honest, many of them are just articles by oclif, like a 12 factor CLI if I'm not mistaken also was another article, an evolution of Heroku CLI, which I think is amazing material. But also my wish is to have even more knowledge on that because it doesn't explain, let's say, everything in details, it provides you lots of questions to think about that. So that's great.

Alex: Yeah, that's about CLIs and oclif. I think you can find a lot in a Heroku blog for that. But for TypeScript itself, yeah, also I suggest some materials in there. I think the… my last finding is the full, the complete guide to TypeScript is available on udemy, udemy.com, I think. Yeah, it's 24 hours and a half of TypeScript. So if you like all kinds of examples of where to use TypeScript and how to use OOP with TypeScript that's where you can find it.

Julián: Oh that's amazing. I guess our listeners are going to love to follow your workshop and to take a look at those resources. So we are going to make sure those are going to be listed in the description of this episode. So for the listeners out there, you can also learn from the experiences that Alex had and what he shared here at NodeConf EU.

Julián: I'm with my friend Tierney Cyren. He's a senior cloud developer advocate at Microsoft working for the Azure cloud and he's also part of the Node.js project as a chairperson for the community committee. Today he's going to be talking about how to build successful open source communities and some lessons learned that they have been having by building communities for a while. So Tierney, if you want to introduce yourself more and they'll also tell us a little bit more about what you are doing, please, this is the right time.

Tierney: Yeah. So as Julián said, I am a developer advocate at Microsoft. I'm on the open source engineering team. So I get to spend most of my time on open source work and that takes on various forms. I spent a non-trivial amount of time on Node. I also do work in, some work in Electron, in TC39 as well every two months and GitHub issues as well. And then I also do some of my own projects like DLI, [inaudible 00:11:27] and good first issue and other things like that, that I'm able to kind of help fill gaps that I see in the open source community.

Julián: It seems you keep yourself busy.

Tierney: Yeah, maybe a little too busy.

Julián: Oh, but that's good. That's good, that's good having something to do that you are passionate about.

Tierney: Yep.

Julián: And that's one of the things that got me into working with the community was because I was very passionate about it. Like, being able to empower other developers and other people being able to offer channels to them to educate themselves, to give them training and sharing knowledge. It's something super rewarding so I want to hear more about your experiences and what got you into working with communities. But before that, what is an open source community? If you can define that for us.

Tierney: So it's a really good question. I've given this… The talk I've given here at NodeConf EU a few times and every time I try to ask my Twitter followers that, what is an open source community? And every time I get very different answers from them. Everyone kind of has their own definition of what it… what an open source community is to them. And so to me at least, it's everything outside of the code. So internationalization, documentation, diversity/inclusivity work, policy and governance. All of that stuff is governance plus so so much more. And generally I found that the people who are responding to my tweets when I ask this, generally you're kind of defining something within open source that's outside of the code as open source community.

Julián: What got you into open source communities? What was your first experience and what got you into the Node.js community in specific?

Tierney: So my first experience, when I was a teenager I used to play Runescape and there were clans and I wanted to make a forum for one. So I got involved in a forum system, I was looking around for a way to make a forum and I found a forum system. It was an open source forum system called myBB and I became more interested in the forum system than I was in the game. So I just spent more and more time doing forums than I did games. And so I got more and more involved in myBB and that was the first kind of interaction I had with open source. It was a relatively slow moving open source project. That's actually why I ended up kind of departing it and going to Node. Right around the time of the IO.JS work, I was getting a little tired of the pace at which they were able to move.

Tierney: And so I was digging into Node a bit and found this post from Mikeal Rogers saying we've shipped 1.0 of IO.JS and we also need help, including in nontechnical ways. And that specific line that sentence of include… we welcome nontechnical contributions, was super important to me because I still wasn't really confident in my ability to write JavaScript or contribute to Node or IO.JS in any meaningful way. But there was a website and the website had content. I could help contribute content, I could help contribute blog posts. There was the IO.JS Medium account. And so I ended up doing that and contributing in that way and that's actually how I met you.

Julián: That's true. Tierney and myself have a history, we used to work together and we met at the Node.js community, pretty much. And we were super lucky to have Tierney working at the other team where I was working previously. So what have you learned by building open source communities and especially with the Node.js community that has been experiencing these, these lot of changes?

Tierney: Yeah, so there's… I go over this in my talk a bit but there's kind of four key things I've learned. One of the things I've learned was don't build too much. And I learned this both from Node and from myBB where building out too much infrastructure and too much structure to how you approach things before there's a community there to fill it ends up being a little burdensome to that community and it actually hampers the growth of your potential ecosystem or if you have one already you're kind of guiding it in your own way rather than how the community wants to guide it. So it's an important thing to be able to go ahead and let your community drive itself rather than you driving it. I think that's very much true of how Node before IO.JS and the merge back was, is that it was a few people driving it in a very specific direction and it was their vision, not the ecosystem's vision and not the community's vision of it.

Julián: So it is better if the community, it's organic, pretty much, at the beginning. Organic, getting interest from people and after you have something established, start establishing the boundaries, the governance or the different things that are going to make that community successful.

Tierney: Yeah, for sure. And then the next one I kind of learned was about empowering contributors, right? So you actually have to give people trust and you have to believe in them and you have to like act on that. Not just you doing it, but you have to actually take the action of empowering them by giving them commit access or giving them elevated responsibility as they kind of continue contributing. And so there's one thing that I like to consistently refer to which is open open source. I believe you can view it at openopensource.org but it's basically just a kind of little bit of guidance around how you can kind of, build out an empowered community by when someone comes around, just give them commit access. You give them that trust when they contribute to your project. And so that's something that I think is super powerful. And how we've approached Node in that basically anyone can come around and if they contribute they'll be a part of the project at that point.

Julián: Yeah and it makes you feel an owner of the project too, that you are like part of the project. Not just like an external contributor but you are just part of the project.

Tierney: Yeah. The next thing I kind of have learned through helping build open source communities along the way has been, accepting help. It's been a thing that I struggle with. I end up being a person who just kind of goes and does things and ignores process and just gets it done and that itself is super burdensome. But also there's people there who have additional context who are super helpful and generally willing to help if they're part of the project and also it's easy to burn out in open source. There's an endless amount of things to do, especially if you are in the leadership of a project, it's relatively challenging to not kind of carry that with you always and feel obligated to continuously do that. Even once your work day's done or once your… the time you set aside to do open source, is done.

Julián: So it seems that you have also experience from burnout.

Tierney: Indeed, I do.

Julián: Can you tell us… can you tell us a little bit more about what brought you to being worn out by contributing to a community and how you overcome that or what?

Tierney: Yeah, so for context, I'm currently chairperson of the community committee and the worst burnout I've ever had was when I was previously chairperson of the community committee on Node. There's a lot of work that comes with positions like this and it's not really like I'm making big decisions, it's more of I'm helping other people find success so I become a manager, basically. My time doing this is mostly spent on ensuring other people's barriers are lowered, that there's nothing blocking them from doing what they want to do and making sure that our community and our ecosystem is a very welcoming place and that I can help others find success.

Tierney: It's challenging doing that because that's very draining, especially when you're helping people around the world. We are not limited to the US or US friendly time zones, and so that is like a tiresome thing in terms of just how much effort you have to put in. And that's not like a commentary on why you shouldn't do it, but it is something that you should definitely try to protect yourself from a bit and I'm not good at setting up barriers for myself or telling people no. So that's something that I ended up having to learn was being able to say no and kind of push back or understand when things weren't necessarily urgent and be able to kind of address them when I will not be burnt out.

Julián: Yeah. I think, in open source, the hardest challenge is people. Yep. The big challenge is not technical. I mean the code and the technical aspects can be fixed and they are solvable, but dealing with the people, it's something super complex. What are other challenges that you have seen while working at open source communities?

Tierney: One of the biggest challenges that I've seen, it's an interesting one because it's basically being willing to say you're wrong as a community. So one thing that in Node we've moved to do a lot better is refactor our governance and how we kind of run the project more rapidly and more willingly. We used to kind of really stick to the same process we had and it was like this is the process we need to kind of get through all the steps. But sometimes that wasn't necessarily necessary. And so refactoring your own direction actually can be a super healthy thing. And that's one thing that is a very challenging thing to do because it's an admission that you're wrong and it's admission that you need to do better and you haven't been doing perfect, but it's also like that is the state of being human and that's how you know we exist in open source. Like you said, humans are the hardest part of open source and so we have to be refactoring how we approach humans in the same way we refractor how we approach code.

Julián: Yeah. And I think also communication.

Tierney: Yep.

Julián: It's going to be one of the biggest challenge.

Tierney: Yes, 100%. And I think communicating effectively is a super important thing, to be able to actually be a welcome and inclusive community. One of the challenges I face in Node and that I think many of us end up engaging with, is that the only "blessed" platform for discussion in Node is GitHub. That's the only official medium outside of the Node dev IRC, which is mostly used by a few core folks. Most of the people in Node don't really go outside of GitHub, but there's not really a way to direct message people on GitHub and there's not really a way to talk with people on GitHub outside of issues. And so that introduces an issue where people have different things they use.

Tierney: In China WeChat is super popular, in Europe WhatsApp is super popular. I use Twitter DMs a lot. I will respond to Twitter DMs within five minutes usually. So… And some people just like email. So as someone in a leadership position and as someone building a community or trying to help enable a community to build itself, going to where people are and being willing to kind of compromise your own comfort for someone else's helps build a more welcoming and stable community.

Julián: So obviously building communities and our community as massive as the Node.js one has a lot of challenges. But what are the good parts like the rewards or the personal gratification that you get by being involved in the community and having a responsibility and leadership role in the community? So tell us a little bit more about those rewards.

Tierney: Biggest reward is seeing other people succeed. Seeing other people become impactful and become contributors and become truly vital to a project is so so so amazing. That's the best part of anything I get to do is just seeing other folks succeed and especially… it's especially rewarding when I got to play a part somehow in that success.

Tierney: In terms of personal success, I don't really get a ton out of it. It's not something that I benefit directly from and I think that's super important to know going into open sources, it's not for you. Folks who go into open source wanting to personally benefit or become a rock star or something like that aren't going to find success and they're not going to end up being happy with their contributions, their time spent on that. It's more of a community focus thing and it's something that if that seems rewarding to you, helping other people, finding others success and building something that others use that is incredibly important.

Tierney: And even on that last one, I do want to add that one of the most incredible, wonderful things I get to see is the bizarre ways people use Node and because I go to events and I'm able to, able to do that, I get to see some really, really interesting uses of Node and that itself is also incredibly valuable in that I get to see ways that Node is enabling folks to do things that would have been extremely challenging and a much higher barrier if Node didn't exist and wasn't continuing to kind of evolve and grow.

Julián: Do you have any recommendations to folks that are trying to build or to be part of an open source community?

Tierney: My biggest recommendation would be to find something that you are really passionate about and feel like you could spend 10 years working on.

Julián: Today I had the honor to be a speaking with Chris Dickinson. Chris Dickinson is working on a new package-manage system for Node JS and JavaScript which has got a lot of traction in the community and the problem they're solving is very interesting. So we are going to be speaking today about it. So Chris, please tell us what you do?

Chris: Currently, I work as a staff engineer at Ease Technologies LLC. I previously worked at NPM as a registry engineering for the last four years and worked on Node core before that so some overlap there, I was on the TSC for a bit.

Julián: You're not part of the Node project right now?

Chris: No. Eventually I had to put down those duties to focus on the NPM registry job so…

Julián: Okay, so very involved in the Node community, not only in the core project but in the whole ecosystem which is NPM. I have a question for you, what is entropic? I mean it has been very trendy lately but a lot of people doesn't know it. So can you explain a little bit more what is entropic and the motivations behind it, the type of problems you are trying to solve?

Chris: Over the course of the last year or so we've had kind of a rocky time, NPM personally had kind of a rocky time. The thing that we ran into is that being the sole operator of the centralized package registry–NPM has a lot of power, but NPM is also a VC backed company and so it is primarily a financial instrument. So there are people with money that invested in the company and eventually they're going to expect more money out of the company. Right now that means the company's in good hands. The people working there are good stewards of the registry but they might not always be the stewards of the registry.

Chris: So I left NPM this year and joined up with Ceej, CJ Silverio, right after that because we were both concerned about the state of package management. We were kind of concerned about the fact that no matter, when you have a centralized registry, no matter who is operating, whether that's a single company or a foundation, it kind of concentrates power into the hands of very few people and what we were thinking would be a good solution to this problem was to federate this, kind of to swing back away from centralization towards federation sort of the earlier days of the internet and make more people the operators of the registry. This also has the happy effect of spreading the cost of operating the registry across many people instead of just a single company or foundation. For an example of the sort of costs that running a centralized registry incurs, you may be familiar with the changes that went into NPM CLI to make caching more efficient.

Julián: Yeah.

Chris: While that helps on a individual developer level, you get systems like Travis CI or GitHub Actions or something like that where there is no persistent cache between runs. And so every time somebody cuts a new change and tests it and runs NPM install, that always hits the registry and there's only one registry. So there's a concentration of costs.

Julián: I mean, it's a distributed system, so if you divide and conquer and distribute, it's going to be like a better way to solve that problem. Yes, I can see that centralization might be a big problem, especially for something as big as NPM, which is the largest package ecosystem in the world. I mean, it's larger than the Ruby ecosystem. Perl, which was like also big back in the days. Even the Linux one that has like a lot of packages in NBM. How many packages has NPM right now? The NPM registry.

Chris: When I started we were getting something like 500,000 requests a week or something like that. And by the time I left it was during a weekday, a billion requests a day.

Julián: Wow.

Chris: So that's a lot of traffic and the disk storage space is one thing but just the cost of bandwidth there is another thing entirely.

Julián: How are you solving that issue? Like that decentralization because yes, right now there is just one registry and you can easily install by using NPM or another client that supports that registry. But what are the things that you are doing to be able to have a federated registry and be also compatible with the current ecosystem? Because I guess that the idea is not to break the ecosystem and have like a way different thing but something that can like work and interact with what we currently have.

Chris: Yeah.

Julián: So how are you solving that problem?

Chris: So the idea is that there will be multiple entropic instances. Like he'll be able to bring up your own entropic instance, for example. My… I could run a personal registry dot. Never saw to us entropic instance, just for myself, and publish packages there. Whenever anyone starts depending on one of those packages on their own entropic instance, those packages will be mirrored over once to that new other instance. So you kind of have the packages mirrored on use. This means that we can actually enforce too that packages don't really go away so you don't get into a situation like leftpad where a core dependency gets published and you had to worry about this a lot more in a decentralized system because, for example, I could let the registration of neversaw.us slip. And my entropic instance would suddenly go offline and you want to make sure that my packages are still available to the people using them. The way they we were kind of supporting, I'm going to call them legacy packages, but the existing ecosystem packages, there is a namespace within each entropic instance called legacy.

Chris: And so you have essentially a portal back to NPM. The idea being that you can say I depend on legacy slash lowdash from my registry.neversaw.us and that will automatically mirror in the packages from NPM. At that point you have those available to you. We can do a stale while revalidate occasionally on that to pull in new versions. But the idea is generally that because we're storing these content addressable fashion, if two entropic instances like registry.neversaw.us and registry.entropic.dev both pulled down lowdash, the contents will be de-duplicated so it won't be like you're storing really that much more information for that.

Julián: If I understand correctly, anybody can have its own registry even if it is a company or an individual, right?

Chris: Mm-hmm (affirmative).

Julián: How to prevent a bad actor creating the entropic registry and tampering with the packages to do some malicious things? There like… what are the security and the trust the story behind entropic right now to prevent these type of things.

Chris: So the way that we're doing this right now is we're using public key cryptography. The idea behind this being that we can verify the identity of the author and a signing registry. So whenever you spin up an entropic instance it will have a public and private key pair. When you first mirror between two entropic instances we will consult with a ledger of known entropic instances and their public keys and we'll say, okay, please try to sign this content. We'll give them a nonce or something and if they can sign it and their advertised public key also matches that ledger's public key then we know that that entropic hasn't been tampered with so it can… we can verify that it continues to be the same thing.

Chris: It's very much patterned off of SSH's trust on first use pattern where you… the first time you SSH, and you might have seen this before, where you trust this post.

Julián: And it's a problem that hasn't been solved yet in NPM, like the signing of packages because I have seen a lot of discussions in the community how to properly solve the problem. I mean, it's not an easy problem to solve.

Chris: Yeah.

Julián: So you already have the solution in entropic, that's…

Chris: At least part of it. We have the server signing in place. We don't quite have the author signing in place because we're building out the client at the same time. We can kind of like… It's fluid enough that we can start to tweak different solutions based on what we see pop up. One interesting thing is that the NPM registry does also sign package contents so we could potentially use that to verify for example that when you pull down a legacy package, you know it matches to some degree.

Julián: Okay. What are the main challenges the project is having right now?

Chris: So the main challenges the project is having right now are attention from maintainers so we all have day jobs in the core maintainer team. So we are working out how to best set healthy boundaries both for ourselves and the project and then figuring out a cadence for communication to make sure that we are pushing forward concretely on the work that needs to be done that furthers us to the goal of making it possible for anybody to spin up a entropic instance cheaply so that we can actually invert the cost, invert the relationship between growth of registry and cost of supporting that registry ecosystem.

Chris: The second challenges, we are covering some new ground, at least, new to us ground. So if anybody is really familiar with distributed ledgers, that's something that we're looking into right now. We were originally going to have a centralized notary service like Go but we kind of consider this to be a valuable enough attack surface area and the project is sort of still nascent that we wouldn't feel super comfortable saying, "Oh yes, these three maintainers in their part time, maintain this very valuable attack surface." So we want to go with something that is like actually a distributed ledger that is doesn't provide vector for attack.

Julián: So I imagine as an open source project you are open and looking for contributors.

Chris: Oh yes.

Julián: So how people can start contributing to the project, the special areas that requires more attention right now?

Chris: So the best place right now to go is, we have a project board on GitHub is the only like org level project board in the entropic dev org and that sort of lists out the decisions and work left to be done. In the near term future, we want to move our factual entropic doc dev website that's sort of like the brochure page for the project over to a GitHub static site. And if anybody's interested in helping out with that, that would be super useful. We're also working on the package manifest format, the entropic TOML. So what that involves is specking out like all the functionality that we want to see in that format. This is a super crucial bit to get right because it means that we can start building the client and the registry in parallel, instead of having to do things at lockstep.

Julián: If I don't have maybe the technical skills or I can't contribute directly to the open source project is there a way for individuals or companies to back the project financially or donate infrastructure? Do you have something in place to receive support from individuals and companies right now?

Chris: Not presently. We are working on opening up an Open Collective and we'll post about that on our GitHub issue tracker when we have that all sorted out. I think for the time being the best way to support the project is to keep an eye out for announcements like the Open Collective. If you are interested in building out the brochure website, if you are interested in becoming an operator or have spare instances sitting around and an interest in running some Terraform and Kubernetes or eventually some Lambdas, that's an excellent way to support the project as well. Where the big next step for the project is to start spinning up extra instances so we can really test out the protocol for syncing between them. And I really believe in this community and I think we can take JavaScript to the stars together.

Julián: Thank you for listening to Code[ish]. And stay tuned for more content about NodeConf EU. We are going to be releasing a couple more episodes that, due to its length, they are going to be released as individual episodes, each one. So, stay tuned for more information about what happened at NodeConf EU.