 Hi everyone, I am Matteo Collina and today I'm going to talk to you about community frameworks because yes, in the JavaScript community we really like frameworks and maybe a little bit of my personal history, well probably not, you don't care, but I think that I have a story to tell, anyway, if you have some time please follow me on Twitter, it's, you know, I tweet about open source things and JavaScript, so yeah, maybe you would find it interesting. So let's jump into it. Long time ago I was, I wanted to be an open source developer and you know, it was, and I tried very hard and I built things with Ruby, with CoffeeScript, with Node.js, JavaScript, I, you know, I was, I tried very much and I tried very much to become an open source developer. I really wanted, I really, really wanted to do it. And yeah, I don't know, I don't know, it didn't go, it didn't go really well. You know, it's one of the key things that I wanted to do was to build an open source to help other developers build, build amazing things. And yeah, this was one of the greatest stuff that, you know, I wanted to, I really felt I wanted, I wanted to do this. And I wanted to help others, other developers building, building software. And probably don't feel as miserable as I felt when I started and so on. Well, I don't know, something like that. A little bit of the, of success came when I built Mosca in more or less 2013. At that point in time, I was, I was doing my, I was doing my PhD and essentially it's, as part of my PhD, I was researching things on the internet of things. And I needed a very flexible MQTT broker. MQTT is, you know, fantastic project, check out Node Red as well. So hey, we are part of the same kind of family. And when, when I was developing this broker, you know, I made a few mistakes. The first one was, it was a completely unmaintainable, really unmaintainable architecture internally. I made some mistakes. I didn't know how to structure a large and successful Node.js application back then. It's also, I never spent enough time in, in automation. And it making sure CI was stable. These was actually really problematic, especially if you're building a distributed system, working in distributed systems, this is really, really, really good. I didn't spend any effort in building a community of maintainers. I wanted to retain ownership of the project. And however, it's, it really got some nice traction. And it's, and with it, there was a, I don't know, maybe I can, I thought, well, you know, even though I did this as part of my PhD, this is part of my PhD, maybe I can make some money out of it. You know, it can help me, it can help me grow my career. However, I had no real funds. I didn't want to raise much, was not much of venture capitalist in Italy back then. Not that there is much now, but a little bit, things a little bit better. And the project essentially failed. It was a galactic failure for a few reasons. Well, the main reason was that, you know, I built a monster. And this monster was as too many dependencies, really too many. It was doing too many things. It was not modular. It was not, it had no community. And I thought it was, it was an era. I was an era and I could actually develop and maintain the software and make it great, which turns out the case. That's not our open source. That's not how open source work. And, you know, that's it. So what can we say? I also add a few different things in this. One is some company, which I'm not going to name on this talk, took my software, paired it with some other software and of some really, really good developer living in London and some other software from another great developer living in the US. And they cook it map together. They change the names, reach the color. So it moved from being a front color to be of another color. And they packaged it up and sold it to a very, very large company for tens of millions. And none of the three people that I mentioned actually made any money about this. Yeah, this didn't really go well for my, for myself, really. In fact, whenever this niche was developing and when it was starting to develop some of the, some of, you know, the project was growing a little bit and it had a community. It started to have the beginning of a community, maybe people, you know, started complaining and they started saying, well, I'm going to stop using this, your library, because you're not fixing this book. This was actually really, really bad. And it was like, it felt really bad. I don't know. I felt bad. I was like, I was completely and utterly destroyed by that, by that sentence, which is very strange, right? Why? Well, you know, why nobody is appreciating what I'm doing, why they're not, they're not, you know, I try to help the community, I try to help people, why I'm not, you know, being successful at all. Well, and then I started following in a bad trap, which is mostly called the imposter syndrome, you know, in, in many challenges, we can be personal, professional, professional. We are held back by the crippling thought that people like us could not be successful. And, you know, it's, I thought, you know, other people can do it because they are special or great and essentially better than me because of whatever. And, you know, this kind of what happened. And in fact, the reality is that, you know, any of that, that's not, there's not such a thing. You can know something, you can have something to say in the word, even if, and that's probably not what other people have something to say in the word. So there's no, there's not a thing as imposter syndrome. So, well, there's such thing as imposter syndrome, but, you know, you're not an imposter. Believe in yourself. In fact, you know, the key thought that resonated well with me was, and I started asking myself the question if I was just building software for myself. And this was, you know, who am I doing this software for? But I'm not, you know, I want to improve the experience for other people, others. I want others to enjoy my software. So it's, it's really, really tricky. And it comes for, with a lot greater responsibility, to be honest. Because there's a lot of other things that, you know, are required for open source to be successful. You need a product strategy, you need documentation, you need to have a developer experience on the product. For developers that are contributing to the project itself, you need to have a release strategy, you need to have long-term support, semantic versioning, a lot of things. People really like 1.0.0, by the way, and 2.0.0. You need to have licensing. You need to have reliable tooling, tooling, including CI. You need to have, you know, some form of outreach and promoting the project. And you need to provide some support for your user. So, yeah. The problem is that there was no chance, there's no chances that you can do all of that alone. Okay. I don't want to be delusional, but it's essentially too much work if somebody wants to do it only, and I say only, on their own. So, and with no money. And, yeah, well, you know, apparently I was a fool. And, you know, there was zero chances. I don't know what to say, but that's the reality. So, one of the things that you want to do is you might want to think, well, I can just do a startup. I want to do a startup to convert, to make sure that my project is safe. And by creating an economical company behind it, I can make sure that it's safe and successful. Well, you know, having a successful startup is hard. Doing a successful open source project is hard. Having a successful startup around open source is even harder. And remember that any cloud provider can compete with you tomorrow. And that's actually a very, very, very, very big problem. So, because they have unlimited resources, essentially. So, well, the question that you want to ask is that if there is another way, is there another way where you can target when you can be successful and create something? Well, you know, turns out there is. And an open source project is as good as it is its community, which is really, really, really, really critical. So, the only thing you need to, if you are, if you care about your open source project, and you want to build an open source project, you only need to care about your community. Who is your community? What are you talking to? That's what you should care about and where you should talk to. So, well, let's see, let's try again. Let's tell another story. And let's see what can do, we can do differently now. Okay. So, back in 2013, at this exact same time, when I was developing Mosca, I also built another product, another library called Levergraph. I don't know, you probably don't remember this. You shouldn't. Okay. The type of research that they've done in the, for developing this thing ended up spread around the world for other interesting things. So, I don't care. But what happened is that this is Levergraph was a nice graph database built on top of Leverapp, which is a wrapper for LeverDB. By the way, Leverapp is phenomenal. You should check it out. Okay. And this is, all of this is developed in the Lever community, which is a community first, and then a collection of module seconds for creating transparent databases. Note that in November 2022, which is sounds are really long time ago at this point, Rod, Rod Vag wrote about open open source. And, and he stated that individual making significant and valuable contributions are giving the commit access to the project to contribute as they see fit. This is critical. This is how you grow community. This is how you open it up and you enable others to join the project. In fact, it's that has put in the seed for open governance and the Node.js way. In fact, in Node.js, our collaborator is responsible as commit access to Node.js node and it's, they maintain, they collectively maintain Node.js. However, every collaborator can nominate somebody else. So, and nominee and the nominees should have significant and valuable contributions across the Node.js organization. Those are two excerpts from the node governance. The node governance is such a big file. So, you should, you might want to, you might want to check it out and read a little bit more, but it's actually very an interesting read and it's also really, really fascinating. So, let's keep going and see where we are. Now, if I am going to be asked to receive this question now after seeing all of this, and after knowing what a good community of users is, when somebody tells me that they're going to stop using my library because they're not, I'm not fixing a bug, well, there is only one answer to them and it's thank you. Please stop. It's really, really better if you use something else. And the reason is, is that they don't, you don't want to be filled to felt pressures in knocking them. And they don't want to be part of a community. They just want to free be, they just want free be, really. And well, everybody likes free beer, but there's no such thing as free beer to some extent. Somebody is, is paying for it. So, you don't want, you really, really need to, to do this. And they're not really useful. So, by the way, don't be that person. Okay. Really, don't be that person. Let me, let me, let me repeat this. Don't be the person that asks for a fix on a library without being willing to contribute any time into fixing that bug yourself. It might be that you need to contribute a very well written script to reproduce the problem or, you know, spend time to actually fix the bug yourself, but you need to help. Okay. Be a very good citizen of open source. So, let's keep going. And, and, and, you know, it's, even though I got involved in, in several successful open source projects, it's still sticking to my hem, into my mind on how can I build a successful and launch a successful of a sort of open source project myself. First of all, you need, I want, you need to scratch your own inch. You need to be able, you need, you know, you need to build something that you have, I use some unique perspective and you want to need to be something to say on that specific field. The second bit is that you want to be able to attract people that are interesting in solving the same problem and then build something together and share ownership. And, you know, it's, it's all about community folks. So, you know, that's it. Sorry, folks, you know, so let's keep going and talk about my experience. So, you know, in, in, in 2016, I was, in 2016, I was, I was in London and it was Valentine's Day. I was on a business trip. My fiance was not really happy about it, to be honest, but you know, it was, it was a business trip and I was, I had dinner with my colleagues and after that we spent the night coding a Flanger tool. Hi, Dave. Hey, miss you. So, in fact, and I found my niche. Okay. And I call it the, the adapter problem. Now, this is a piece of paper, right? And with a piece of paper, you know, you can, you know, you can only fold a piece of paper so many times. Okay. Like, I don't know, I keep folding my piece of paper, but you know, there is only a limit of time to time where I can fold it because after a while, I cannot fold it anymore. You see, it's too hard. And the problem with this is that you can only have so many abstractions before your code becomes extremely slow. And I got focused, I focused myself and I focused my career on improving performance of Node.js and Node.js applications. So, one of the first things that I built is Pino, which is a really nice logger. And wow, it's, you know, it took the, I presented it at a nice conference in San Francisco, then at a bunch of other events, somebody dedicated a poem to me and Dave, which is the other author of Pino. Thank you, Emily. It was a great moment and of Node.js lore. And in fact, in the key moment where things change was when I started to ask you know, a stranger, would you like to help maintaining Pino? This was one of the greatest moments because they said yes. And first of all, I met a friend, which was, you know, something that probably a life, hopefully a lifelong friend. But, you know, we have been chatting and working together for the last few years. And he, you know, he has been thanks to Pino and thanks to thanks to Pino, he went thanks to working in open source. He was able to change jobs, change jobs, change life. He increases his salary significantly, so hey, but it was kind of big surprise. And I have seen it firsthand how helping people, helping open source and building a community and being part of a community can help somebody career and can change somebody's life. So this is one of the greatest things that I think I am proud of. So, you know, Pino is now very successful, is the fastest, longer for Node.js. And it has very minimal features, so don't expect much, but it has a great community. And it's right now downloaded maybe four million times per month, which is, you know, pretty successful to some extent for my point of view. It has four active collaborators and it has now reached version six. Okay, successful library. So next, I started asking myself a nice question, is how can I build a new web framework for Node.js? Well, why do I want to build a web framework? Because I was not really happy about the performance of Node.js applications. And I was doing some benchmarking and a lot of consulting and turns out that there was some lot of time spent in Node.js framework and inside Node modules and inside libraries in there. And I wanted to fix that because most of the time, the CPU time should be spent in running a business code, is running the developer's application. The framework should not be in the way to gather good performance. So this time, I didn't want to be a fool. And in fact, I didn't want to, I knew I couldn't do that all alone. I actually, I've learned my lessons. So I started, I wanted, I really needed to build a community because this was, it's a Gargantuan work, like shipping a new web framework is Gargantuan. And I really wanted to build and I really wanted to build a community. So the first thing that I started is I didn't want to start developing the framework up until I could have find another human being that would have been interested in the journey, in sharing the journey with me and building with me together. Now, this has been one of the founding moments of, for me, because I was saying, I basically said, well, the open source, the code matters so little in what I want to build that I'm going to focusing on convincing somebody else. Right about that time, I ended up, I was doing a Node.js workshop, a Node training in Italy. And one of the attendees of my class asked, hey, Mateo, I would like to get started in open source. And I said, well, where do I start? What do I want to do? And then how can I do it? And then I said, well, I don't know. I would like to start working on a new web framework for Node.js to solve all these problems that I'm seeing on the others. And he said, oh, interesting. And then we started working together. And we started developing software together. And we were chatting every few days. We started tinkering. We spent long nights maybe doing stuff. And well, all remotely, by the way, all on GitHub and pushing things whenever we could. I helped him find his next two jobs. So again, I'm feeling very, very proud. And yeah. So it went, it went really, really well. So anyway, let's go and start about the genesis of a framework. And it's really, that's what led to Fastify. And Fastify is the framework with myself and Thomas, Delavedola, built together. And what we have started. First of all, it's based on open governance. In fact, it was, from the start, it was never to be my own thingy. It's a shared thingy. It's not my project. It's our project. I probably had the idea and some of the funding moments, but it's not mine. I'm not the first contributor of the project, okay? To be clear. Thomas is, I am not. And it's community first. We welcome first time contributors. In fact, we want to grow our community of collaborators. So if you want to join and want to contribute to a nice open source project, please come. We have a lot of things to do, really, a lot of open issues. It's also based on the concept of shared ownership. So if we don't want to be in a position of you asking us for a fix, for fixing a bug, we want you to fix your own bugs, okay? And that's how we grow our community. So this is everybody's frameworks. So everybody needs to contribute. It's also based on some few very important technical details. So first of all, we didn't want to have much overhead in production. Now, you can have, you need to have some because it's clear. It's not rust, okay? Where it has real overhead abstractions. But you can do pretty good things with Node.js. So you can actually have very little overhead. We want to have a good developer experience. We wanted to work both for small and big projects. So, you know, individual developers as well as big companies. And which should work well for both. And so it can be something that I can learn on my own and then use it at work whenever I get the chance. And it should be able to easy to migrate to microservices or serverless and back. So we needed to support both monoliths and microservices and be able to use both to migrate to both models very quickly without needing to rewrite the full code base essentially. You need to have a good security model and have a good security reporting. And by the way, thanks for providing this. It's based on the concept of plugins. So if something could be a plugin, it likely should. So we created an open core system where it's highly extensible, even though it's, you know, cost free. Those mechanisms are cost free. And it's highly extensible. You can plug in and add things in several places of the framework and customize it the way you want so that you can develop your own plugins and tune it to be the what you need on your project. It's also easily testable. And so code bitten will fastifies easily testable. It has a nice dot inject function, which is fantastic. And then it's, we didn't want to do any monkey patching off core of Node.js core. That is one of the most of my main critics for a lot of frameworks. So no monkey patching. Sorry. And it supports semantic versioning and have long term support strategy. And it should, you know, add there to HTTP one dot one. So fastify was then born. And it's right now one of the fastest web framework for Node.js. It's, it has 10 active contribute collaborators. And it has, you know, now rich version trees. No, it's in release candidate stage as a time of this talk. So, okay. And it has now an ecosystem of 140 plugins. And it's actually very easy and fun to use. So please, you know, check it out. I just want to say a few parting words, which is people use software I built. And there have been some, and I'm part of some great communities, Node.js, Pino, Fastify. And, you know, in 2020 modules that I maintain will be downloaded around 5 billion times, which is a little bit staggering, to be honest. And with this, I want to say thank you. Thank you for your time. And please check us out. Nearform is a professional services company based in Ireland. We do all things JavaScript. So if you need any help with Node or React or whatever, just hook us in and we can probably help you. And I just want to say thank you for coming to my talk. And I hope the story was nice and you, and you enjoyed and you enjoyed it. And see you next time. Bye-bye.