Hi everyone, My name is Patrick Acu and if you've ever heard of Dino, this episode is for you. It is an open source JavaScript runtime to uncomplicate things. Joining me today is Leo Keptmeyer as long term open source contributor. It landed him a job at Dino as software engineer and he shares the insurance and outs of what's going on.
So enjoy. I'm really curious how you eventually ended up at Dino because I know yourself thought I know you dropped out of, I think it was high school and then you picked up programming and you just started contributing basically here and there. How did you end up in Dino? What's the story there? So it was completely random. It was a YouTube recommendation. A YouTube recommendation. It was Ryan's talk.
Raise the algorithm, yeah. Yeah, it was Ryan's talk. 10 things I regret about Note. OK and on the same day, like 3 hours before I saw the video, they created the discord server. OK. So if it wasn't for that coincidence, I would not have joined the community because I didn't want before that. We're using, I can't remember what this is called, like something git. It's like some chat platform, some projects here. I can remember the name, but it was not my type of thing that I
use really. And I use Discord for a day-to-day basis. It's like years, yeah, just to talk with friends and then three hours before they created the Discord server. So like that was a pure coincidence. Like a one-on-one? Yeah, easy. So I joined the community and then I saw some issues like the way asking people for help. Obviously it was the beginning of the project, relatively new. Yeah, it was, it was early 2020. Yeah, I believe so. Yeah, shortly before the 1.2 release.
Yeah, I joined, started contributing a bit here and there. Like 1 issue was removing comments because there were too many comments and it was causing issues with like some script Yeah And then I want to make a Discord bot library because I was using Discord bots and note of course and that's like the basic thing I guess that everyone starts off nowadays, but. It's a nice thing, I think, yeah. But there wasn't a library for Dino.
So I started making one and then I encountered a bunch of issues and it's like they don't have that many people at the time that are working like full time on a project as well, like 5 people. So the first issue is, oh, you're missing this implementation of this web spec. I've never done this, but I mean, let me take a look not And then slowly start getting more deeper. Like the first one was like something with form data and like fetch responses or something missing.
And then the next one after that was implementing all of web sockets because, you know, didn't have any web sockets. Yeah, So I implemented that and then it just went deeper and deeper and deeper. And it was. And contributing nearly full time. Yeah. And then after a while, I got hired. Nice. I asked Ryan, Hey, can I join him then? Yeah. Great.
Before we get into Dino, before people that don't know who's Ryan. Randall, yeah, the creator of Node JS and he started the project like Node was started in 20 O 9, publicized 2011, I think, don't quote me on that. And then he left the project at some point, I think 14, yeah, 2014 maybe or 2012, I don't remember. But then he started Dino because he wanted, he rather he had regrets with Node and he wanted to make things right. So he started a new project, and that's Dino, Yeah.
Was the video you saw because you said it was 10 mistakes? I made a note, obviously, that I'm going to. Correct. In Dino, there's no better marketing than that from the creator of let's say, Oh yeah, it's like the best thing. Oh yeah, It was like a massive success. And obviously that's so many people heard about Dino from that. Yeah. And like if you look at the graph of like star history on Get Up it like on the data presentation, it went like up, straight up like over 20,000
stars in like a day or two. That's insane. Like we will talk about the the hockey stick curve and then and that's it. That's basically it. But that struck a chord with you also in that you wanted to kind of join this community and collaborate and participate or was it just, this looks interesting this? Looks interesting. Really. I didn't really care about who the fuck is who is. This. Guy, I don't care. I don't really care about famous for celebrity host, stuff like
that. You're a person, nice. Why do you deserve anything more than being treated special? I like the sober aspect of like, the thing doesn't mean anything. You're still a human. Yeah, at the end of the day. Yeah, because that's how I feel as well. But how did you get into programming in the 1st place? Because I know it wasn't your traditional education journey. No, I mean, in middle school I did an English International School in Italy, and they had a more extensive computer science
program in middle school. And that's where I said like, awesome basic HTML and stuff like that. Yeah. And then I wanted to Java a bit for like half a year. And that was like, OK, I'm never going to touch this again. Don't want to touch Java. I agree. Let's leave. It, I've not tried cotton yet. I need to, but Java itself, we can leave it something. And then, yeah, that's just picked up. And then I was always doing a few things here and there just for fun on the side and yeah,
just good interest. And then at some point I, well, history is history showing start contributing to DNR and that's it. But I know you do like very, I would assume more so low level stuff like implementing Websock. This is not the easiest thing. Yeah, especially if you're like you came from either a traineeship or maybe some type of educational background. But a lot of that, you basically educate it yourself. Yeah.
How did that happen? Because I think you brush over it. But for me, that's the a lot of the interesting stuff. I mean, I didn't know any low level programming really like touch C, like one time in class and that was it. Yeah. And do any low level program whatsoever. But for me it just made sense. It just. Clicked Yeah. OK, like I only knew a bit of JavaScript and TypeScript like basic like I didn't really
understand promises at a time. Yet when I start contributing to that's how bad it was, OK. But now, yeah, it just makes sense. And now I understand all of that much better as well. Yeah. Do you? Because I sometimes I have engineers on on the episodes and they when they see something, they want to go deep and truly understand how it clicks. And for me, I don't really have that. Like I want to use whatever's available how how it works on a low level. Like I want to understand it,
but that's not my main interest. I want to use it to what I want to do more so on either product level or in solving a problem. Where do you fall kind of on the spectrum because I know you have a lot of the in depth knowledge, but is that also what makes you tick? I would say in between, I guess of the two things, it depends honestly, though, yeah, it's, I mean, let's say I'm using some random package to something.
I'm not gonna like deep dive into it, but if there's like something or this could be made better maybe or there's some problems here, then I will actually start deep diving into the package and like submit PRS to the original package or make a fork or create a completely new project from scratch. But not begrudgingly, Sir. No. OK. Yeah, no, no. So this is just business as usual. Yeah. Nice. Yeah, I mean, it just seems I don't need to waste my time and like deep diving into everything.
But when Destiny Two, I'll do it and I don't mind doing. It, yeah, yeah, I think it's also part of the journey. And then sometimes you have to go deep and sometimes you have to get out of there. I feel like that's where where I'm at as well when it comes to kind of contributing to open source. I know that's something you've been doing. I know it's something you're
fond of as well. What I hear for people is that there's kind of this hurdle because it is, especially if you're either coming from an educational journey or you're switching from a different career in and of its own. Contributing to open source, I feel like is going to give you a lot of the skills that you need when you either are in a company or we have something that needs to go out to a lot of users or
in production in that way. And people see kind of a hurdle with contributing in the 1st place because you it's harder to contribute. There might be a lot of time overhead that it needs to be a lot of QA and an approval process and sometimes APR might be open for months before you get merged. Like what was your first kind of dive into contributing to open source? I mean, open source itself was who, how did I start off?
I think it was just I was one of those terrible people that was just open random PRS to get Hectoba T-shirts. OK, That. Yeah, at one point I did that for like a year or two, like whenever Hectoba came around, just did that, which I regret nowadays and shouldn't have done that. Prestigious issue, yeah. Yeah, which nowadays I don't really care anything about it. Actually remove that thing. It's annoying people. It's learned from that. Yeah, people opening random PRS.
That's so fucking. Yeah, because now you're on the other side, Yeah. And yeah, but no, I guess that's how I start. And then like actually starting properly contribute. It was Dino like Dino was learning low level programming, contributing just basically everything all at once was for me just a deep dive. What would you recommend to people that then feel this kind of hurdle because you already were nodding your head and saying yes like APR can be over for months sometimes.
Yeah, I mean proud people every now and then. If that's the case, like if you have APR open for a long time, but don't be annoying, don't overly bother people. Don't just write bump on the PR Don't just go to like maintain us and constantly ask them for questions like they also have to do other things like it's they have many PRS to handle like let them do the job. It's like a one to many ratio. But they will get to it like it's you're not ignored, not for
no reason. Like just it takes time. Especially like for projects like Dinar, we have so many PRS open. Oh yeah. I think we have currently like over 150 PRS open or more over 200 nowadays. Yeah, we had the rule to knock over 100. OK, no, that didn't work. It just. Project just grows quickly and that's a problem. So sure, getting more people helps, but that has its limit. So yeah, just wait, let's see if they don't reply. Just ping every now again.
Like don't be obnoxious. We don't like obnoxious people. No, I can imagine. Yeah, But you still want people to contribute, right? Yeah. There's like 150 PRS open, That's from a point of where people want to contribute. And if there's like an open source like project that has 150 PRS open where people are still actively contributing and merging things, that's a good thing. Oh yeah, for sure. I mean issues grow and grow like with way too many issues.
I think we are like over 10,000 open issues, which is also a problem because you need to fix a lot of stuff. But like a lot of those issues are like feature requests and additional stuff or like this very specific edge case, which like impacts 1 user. Obviously, we have priorities. We cannot advertise everything at once.
So again, PRS may stay open for a while if they're extremely low priority, especially if they're large PRS, If they're small, simple PRS like I don't know, let's say up to, I don't know, 300 lines, I would say it's relatively small ish depending on what you're touching. I don't think that's an issue. But if you're like going in the thousands of lines changed, that's more difficult to land, especially if it's again low
priority. Yeah, there's like a full context switch and low priority means it's going to take a while. Yeah, yeah, I get that. What do you think of then the the skills you gain, well, contributing to open source projects? How do you think it translates into what you might do professionally when you land a job, let's say? I would not necessarily say contributes that much, honestly. Sure, there's some relationship to like being clear and commutative with PRS and issues and like.
Yeah. That translates to some degree, but for some people it doesn't. OK, I know a lot of people that are really good at a job but are not like amazing like communicators or like just very reserved and just don't talk much. I know. I mean, that's half of the program is probably out there. And yeah, you don't need to be like outspoken or anything like that to get into programming and open source. Just text communication. It's different than verbal
communication, of course. So that's one point. Just so basic text communication is, I would say, a skill that you you need to learn. Yeah, Because you need to communicate what these changes you're doing, why you're doing it, excitement. If there's some more in depth reason, then obviously you have to explain that. But on a higher level, I wouldn't say this too much, honestly, that is necessary and that you really need to pick up.
Obviously programming, yeah, kind of difficult if you don't know that that's demos. Yeah. But that aside, I mean if you're enjoying something then do that. Like that's pretty much it. Enjoy the project you're working on and even if you don't know how to communicate properly, still contribute. Like even if your text verification is not that great, still do it or get better at it even if you think you will not. That's fair.
I think that's we might differ from opinions because I do think that the soft skill side is getting more and more, let's say important in what problems people solve. And I get that when you're solving, let's say, the technical problems and your soft skills at the end of the day, like it, it matters within your team, but it doesn't matter with regards to getting business buy in or if you're a big
organization. I I mean, buy in is still a big thing or even convincing other people with regards to what you need to do for priorities even. But I do see a shift where that becomes more important. And it might either be because we're not really innovating all of us all at the same time. And sometimes we're solving the same problem. So we have to advocate for what. But I do think the soft skills matter, or at least matter more than they used to.
Yes, I would say that is true. But if you're skilled enough, honestly it doesn't like. You have to be really scared, yeah. No, I know people that they don't talk whatsoever, like even on text basis. Yeah, and you just send them like an issue and they will fix it without saying a word. Like they just do the job. They don't communicate at all. I know multiple people like that. It's not ideal in some scenarios, but I mean if it works.
If they solve the right thing, because they can also solve the wrong thing. If there's a misinterpretation, sure. But I mean they should be able to communicate at least as far to get clear ideas on what they need to work. On fair, fair, Yeah, Yeah. What in your view makes a really good engineer then? Because I'm curious about that. What makes a good engineer? That's a tough one. I mean, there's so many different aspects to it. I don't think there's like 1
clear cut way. Yeah, obviously being commutative it it's, it's really good to have that skill being able to make up proposals and like write proposals for like a feature or something properly that is fairly good. And it's something I can't do really at least haven't done properly yet. Like writing out a proposal for me just seems like a massive pain, OK. And like extensive list of precision, like what we need to
do here and there and there. I'd rather just jump straight into it. Just came into it. Yeah, but that's not the ideal way, especially for a company, like a company especially that has priority. They want to know like what the process is for this thing to be added and like etcetera. So that is a good skill to have that I don't have. And yeah, you don't. What else? I wouldn't say being a Jack of all trades is a good thing, but neither a bad thing.
It depends obviously on what you're working on and the skill set you have. But like there's people that are really good at one very specific thing and that's really good and other people are really good at many different things. It really depends honestly on what you're working on, just the circumstances. So in that regard, I I wouldn't pick one of the two cases. It really depends. And that aside, I mean, don't be an asshole. That's the most important one, yeah, Yeah.
Yeah, just don't be an asshole. That's quite simple. I like your remark that at the end of the day, if you're a generalist or a specialist, like both have their use cases. Yeah. And their value, which also means that you as a programmer, you can be unique in what you like and what you're good at versus someone else. And there's no right or wrong. Yeah. Yeah. What what did you like? Do you see yourself as a generalist or a specialist, or how did you learn to become either?
It's, I think a bit in between. I mean, I know general Rust, I do various different parts of the Dino copies, but I do have a specific knowledge of like web standards and just following standards and stuff like that, which I think it's good to have a mix of both. Specialization helps you find a job, for example. I mean, if you know something really well, companies will want to have you. But the problem is finding companies that will want that
specific skill. Yeah. And that's why generation is good, because if you join a company, you don't need that specific skill. And you don't know, just generalization, like general stuff, then you're kinda. You're out. Yeah. That's it. Yeah. Which is like if I leave Dino for example, if that would ever happen, where do I go? I mean, I cannot web stuff like either go Chromium based and that's like learning C&C and I don't want to do that.
No, thanks. Yeah. The rest is gaining traction here and there. Yeah, but they're not specific for the web stand as well. Less. I mean there is Mozilla with Servo projects. I mean that is I guess it's fully Rust, so I guess that would be my other viable place to go. But like Mozilla itself still does a lot of C so like that would also not be viable for me. So like for me in my specialization category of web knowledge does not transfer too many places like Apple.
I don't think they use Rust. No, I don't think so. No, no. Maybe use a little bit of gold that I know, but otherwise not rust. Yeah, so. I don't have many places to go with my specific knowledge. No, I mean I enjoyed it and I'm gonna stay for a long time. For a long time, I hope at least. You never know, but. I'm really curious then. So regardless, or if you're a specialist and a generalist, you taught yourself and it just
clicked. And for people that are trying now, I feel like the more we go into the future, the more information is out there, the more even automation tools come in to make you more productive. Yeah. And to hopefully accelerate that learning journey. But for people that were to start out and see and seek a career in software engineering, or for people that want to pivot, how would you advise them to start out when it comes to learning the skills they need? That really depends to person to
person honestly. Like have have people asking me, oh, how can I learn this? Like I had a friend ask me how can I learn the Ross? Yeah, I just told him look at the Ross book. I mean, the Ross book is actually really good. It's quite good, yeah. Yeah. So like. Anyone should go through that, but most specific knowledges like it's it's really tricky. Find something you enjoy. You don't enjoy games, try making a game or try making like an emulator, like making chip 8 emulator.
It's like something I did like three or four years ago, like I just started knowing Ross like it's not like sure it's not simple, but it's a good project to like get into like some deeper knowledge. So like just find something you want to build, even if you don't want to build, but find something you might be interested in. Like as long as you're interested in it, then you will learn. Even if you don't enjoy it that much. But have like let's say making
an emulator. I don't really have an interest in emulators, let's say for example, but I have an interest in how games work under the hood, etcetera. And you learn that by making an emulator. Even though I don't care about an emulator. I think it's the right examples. So it depends. Yeah, I think that's the best advice. Look at what you like and that might actually entail what you want to create or get it at least energy out of creating
something similar. Yeah, Correct. And then start from there and see what you need because that's it's different, right? Because some of the questions I get, usually I do these Q&A episodes where people ask questions and this is one of them. Or they ask what the best framework is or which language
to pick up first. And that's the more technical side of it, what you need to do whatever you want and then you're turning it around, look at what you want to do and then figure out what you need to do that. Yeah, exactly. I mean language, and it really depends on what you're trying. To build. You're not gonna use JavaScript for making like an operating system. I mean there's people that do
that, but they're crazy. But no, for that you would like use a low level programming language like CC, Rust or I guess I don't know, I mean Go. I wouldn't say it's ideal for making an operating system, not yet. You don't really want GC in there, No. But yeah, it really depends what you're trying to build. Yeah. But then there's still like, for example, I tried to pick up Rust in like a hackathon or
acceleration day. And for me, there was quite a hump in things that I needed to accommodate for to get stuff up and running. And I come from like like a go background. I started out in operations in the first language. I picked up professionally outside of educational journey, which was mainly Python was Go. And then it was very simple to start, contribute and execute on an existing code base. We were already live on
production. So, so then start from zero to one because I wanted to create something with Rust for me was quite a bump. So then throughout that experience, if someone were to ask me, should I start with Rust? That's my first programming language. I'd be like, man, would I then advise that maybe not. Maybe start with something similar where the concepts are more defined or you have that
more out-of-the-box. Get a general understanding and then try Rust. But you said Rust was actually quite easy on the pickup for you. Yeah, for me it was. So things just click again. Yeah, that's magic, man. Honestly, like, again, I only knew JavaScript and some TypeScript. Yeah, it made sense. OK, this makes sense. This is weird, but it makes sense. Makes more sense than C So yeah, I mean, yeah, no mix.
I mean, I guess it really depends from person to person and like what you prefer and learn what you think you might enjoy. I mean, I tried Haskell at one point. I tried for one week. I didn't really continue. That was like many years ago, so. It's like you went back, you were like. Yeah, no, I mean I want to get back into it again just to like, understand what the fuck I was not understanding properly back then.
But I mean, I like Rust. Haskell has its own use cases, obviously, but not the use cases I need. I like that you like Rust also because the I am a lot of ghost operates and people like ghost sucks go Rust here or blah blah. And this this different train of thought that says they can coexist. And I think I'm in the in the latter part where I think, OK, you can solve the same problems. But at the end of the day, languages can coexist.
But still, how language is getting a gets adoption in different companies is kind of a chicken and egg problem, because as a bigger organization you want to use what's established. And right now it's still JVM based, it's very much still Java, and Java's improving regardless. But companies are looking for Java engineers then. And we have people that are enthusiastic either about Rust or about Go. Smaller organisations might experiment with that, but they're different from bigger
adoption basically. So language needs to find its footing to get adoption, but also it needs to have adoption to fight it's footing. Yeah, I mean, that's the same problem with Dino itself as well. Yeah. So like, yeah, it's a tricky issue. I mean, there's obviously some people that always will push for it, even at smaller companies, and smaller companies will then do it. And some are successful, some are not. That's just business for you. But yeah, for larger companies,
it's tricky. I mean, getting adoption from a larger company means that you need to have someone inside the company that is relatively high up, that is interested in the technology. Like I can have like some junior engineer, like some big tech company wanting to use Dino and trying to push it internally. It's not gonna work. But if like a senior manager says, oh, this looks interesting, let's try this out, then it most likely will happen.
So it really depends on the situation on the people that are interested in the technology of adoption. And I mean the same problem was with Rust, I would say. I mean I was at a Rust conference a few months back in Delft and there was a talk about using Rust at Airbus or satellite software. Like you would not expect that to be the case. No, they are doing that. So like find the right people in the right place and then it will
be adopted. But if I was finding those people that are in the right place, so like, yeah. And that then also interested in the thing. So yeah, as a project like Dino or like a language like Russ trying to find adoption, it's it's tricky. It's not something too simple. Yeah. But there's a interesting thing that I now see more and more. Before there was like a license model, right? And Red Hat is an example of that.
I mean, even Intelligent has their open source variant and then the Ultimate Edition, which is a license based. But Dino is not like that, right? Dino is not license based or is it? No, it's like the business side of it. So to be clear, it's Dino, what we call Dino internally, it's the CLI. Yeah, the CLI is what most people see as Dino as well. Which is open free to download you can use. It you can use it, modify it, do whatever you want, it's MIT license.
But then there is Dino Deploy, which is our hosting platform similar to like Cloud for workers for serverless edge functions. And that's like more on the business side that has a premium plan that's completely closed source. Yeah, it builds on top of Dino exactly. And then we have also like sub hosting for like if you want to, but that's part of Deploy. So like you can have your own SAS if you want, running on Dino Deploy sub servers or things like that.
And then we no, that's, that's what we have. And more and more companies are this, they have this open source model which is like their main thing and then they have spin offs which make it easier to deploy, less cost of ownership for customers. And that's where they make, let's say, the business side of it financing. Obviously Dino itself does not make money. No. Open source?
Yeah, someone still pays you. Yeah, but The thing is, if Dino gets more popular, you know, the employee gets more popular. Yeah, so it goes hand in hand. Yeah. So Dino's like popularity is an important factor for getting deployed to be more popular. Yeah. And I love this business model. I think it's, it's very different from licensing because licensing nowadays if I am implementing something and I can pick five options and four have a paywall, then I play around with the free one.
And if the free one fits my use case, then I might even drop the other four because I can continue, I can execute and I can make that decision a pivot if I need to, right. So we're going from this licensing thing where decisions are kind of behind closed doors to everything is open.
You can even see the source code and contribute to something if you're missing a feature And then off the side for ease of use or you want to do more advanced stuff, that's where companies then make it more easy. And that's like their premium model. And I love that concept. I think it's also more sustainable for how you then contribute and you can build a community around the open part of it.
What's that? So with starting, do you know and I don't know how far you are like I think you are quite far in the history of it. Was that already kind of the mindset to start this open source and then branch out in open core or how did it get to the business side of things? I don't know honestly, at the time that Dino became a company that was 21, I believe, I was still just a contributor and was
not part of the company yet. But and like the Dino deploy was being worked on at the time already like this. I got to try like an early, early better of it. And I guess it had they had the idea for a while to have like an actual product behind it because but I'm not too sure honestly, I don't know the details on that. Just I think it was Dino. Then they had the idea for Dino Deploy.
I guess the idea was find some way to make money out of Dino and then the company was made that through that. So yeah, I guess Dino itself was just started with let's make Dino. Yeah, not let's make a company. I think that's still the best way. Yeah. Because I've seen, I've seen two fold, right, where companies start closed source and then they part partially open source, something that is really gaining traction or adoption or they want to build a community around
that. And the ones that start as open source and then they see the opportunity to find kind of a business model at whatever they have open source. Yeah. And companies that succeed in that and companies that also fail in that. Because at the end of the day, you can make a lot easier, but someone still needs to pay for it. And that's the hard part. Yeah.
I mean, the biggest problem with the with this model also is now you have an open source project that you need to pay people to work on. Yeah. So that means that the close project needs to make more money. Absolutely. And that means you need to drive more adoption or to drive more adoption, you need more people working on open source watch. So it's again a chicken and egg problem where how do you get the right adoption? And obviously adoption for any
project is a tricky problem. Absolutely. But I mean, if you say we have 150 PRS open, then something is going the right way in that equation because a lot of people are contributing now. Sure. That's true. And I mean, we, we've closed a lot of those PRS and like merged them, but I think ten of those PRS are mine PRS over a year. No way.
Yeah. Stuff that I still need to finish and like just because I changed like context so many times and like, oh, now I need to work on this and like then I'm six months working on JSR, something like that. I have no time to work on the CLI. I didn't expect that to be that to be the case. How is it then? Because from an engineering side, I wouldn't imagine going through that.
Like I have some PRS open sometimes here and there or at least in past experiences, and those can be open for like months. And then we make a decision, OK, it's still needed or oh. You still want to. We do that as well. Yeah, but from a fulfilment perspective, if it's not merged, I feel kind of unfulfilled in a certain aspect. I agree but I completely forgot what those PRS are. No no I know what those PRS are. Just some some of them. I need to fix them up.
Yes, just I had other priorities then like. I don't want to hold your account. No, at one point we had like internal hackathon to some degree, like issue closing marathon basically like person that gets closest to most issues get some reward. And it was then when it opened like those 10 PRS that are open and like that just remained there sitting there while other stuff actually important happened.
But actually closed one of those PR few days ago I think already landed and then I'm just trying to get through them at some point but. Oh yeah. Yeah, not priority, especially with DLO 2 on the horizon at some point in the future. That is a main focus for us. So like working on stuff that's not important like like high priority is not too viable right now. So it will probably sit there for a while longer.
Yeah, but like those like I think it's the oldest PR is my PR like the oldest open PR that is there is mine at least was mine for a while. I'm not sure if it's still mine. That's hilarious. Like I think if you go on the last page of the Dino PRS, like I think we have demo four of them out mine. Yeah, yeah. I mean it does make sense. Yeah.
With open core, it's also, it allows you to create this, I mean you already because by virtue of being open, it creates kind of a community, right, where people have the option to contribute and businesses then also capitalize on that. How much of the feedback coming from this open source part incorporates and reflects them back on the road map and is actually being prioritized? I mean, it is quite important what people actually want. I mean, that's how you get an
option, yeah. But it can't be the only driver, right? No, obviously there is money moved, money is always involved. So that's what the clients want on the, you know, the employee side. Yeah, so we practiced what's on that side because again the other employee puts on top of Dino CLI. So like changes in Dino CLI need to be made to work then on deploy. So that's like one level of priority. Then there is maybe AVC backed. So obviously investors want more money.
Oh yeah, yeah, yeah, that's show it. That's the live up VC. So obviously there's priorities in what price in getting more money in on that regard. So like there's prioritising like what big businesses want or like corporations want to have in D node then drive instead of and then like then there is what the actual open source community wants. And like finding the balance of that is not easy. No, it's tricky, yeah.
So, yeah, it's not something too easy, but I mean, we tried to incorporate feedback from the community as much as possible. I mean, we have open issues close to a lot of issues. So it's just finding the priorities, finding what we think is important and work on that. Yeah. And you know, as a company you mentioned is about like 25 to 30 people total. Yeah, well, I think. Something like that. How big is the engineering slice?
25, yeah, I think 25 people if we say, if we say 30 people don't know, we're 25 people I think. Gotcha. Yeah. So every five engineers you have one that is non engineering. Yeah, pretty much. Something like that. What are some of the engineering standards within this company and even way of working? Because for me, for bigger organisations everything is kind of Scrum, sometimes Kanban, but I haven't been on the kind of inside at an open source company
or open core company. I mean, we just have like a project board and a Google Docs document with stuff that needs to be done and that's it. And you just do that. Yeah. I mean mainly there is currently especially E skater projects for like dinner 2.0, like targets and stuff we need to do for 2.0 and that's more like just an actual priority board and stuff that needs to be worked on.
So that's more of a traditional, I guess, company style thing to have like priorities on PRS, on issues, etcetera. But for a long time we didn't really do that. Super bare bones. Even what one time we did, we stopped doing it just because it wasn't working for us. I love that. I love that. I mean, it shows that you don't need it at the end if you can be effective. Yeah. What is like the seniority between the engineers that you have? Is there room for like junior
engineers or? Not really. No, right? Well, I mean, we do hire people, but especially engineers right now we have enough from a business perspective apparently. So we're just more looking into non engineer roles. And especially if we do look for engineers, I mean we will hire engineers if that's like some really special person that wants to join a company. But like for a long time, I don't think ever really, we did
really accept junior engineers. I mean, I mean, I was accepted and I definitely call it as a junior engineer at the time. I still consider myself relatively junior. I don't. Fair enough. Yeah. But is it because they're because when junior engineers ask questions, or at least the questions I answer on this podcast, they're more from the angle of what company should I join? How can I get a head start? And usually I make the assumption that smaller organizations, and I mean, Dino
is like very tech focused. You have companies that say we have tech at at the heart, but there's not a lot of examples where it is the same as in Dino. So that's why my assumption was there's probably not a lot of room for junior engineers, right? Because you still have to educate them and guide them and grow them. And at some point I think at Dino you also need execution power more so than anything. Yeah. I mean, I don't think the issue is like having to teach them.
I think the issue is just we see company we need and talented people we need fast work done is speed Yeah, I mean it's not like crunch, but it's a good pace. This one like that. No, it's I would say yeah, it's a good. Pace. It's a good pace that's sustainable rather than crunch. Yeah, crunch. I mean awful. Yeah, yeah. So yeah, it's just, yeah, junior engineers. I mean, every now and then we do get like one or two people that's like really rarely and then see what happens.
But yes, at that score we don't really exception engineer. So just because the too much overhead like too complicated to handle currently, especially again we see, we see wants money. So we do what we need to do. Go back. Yeah. Exactly when it comes to then the engineering standards, how do you or how have you standardized, let's say best engineering practices or how do people think about that or how did you get alignment throughout those 25 engineers? In what sense exactly do you mean?
With regards to, I mean it doesn't even have to be architecture in the code base. At some point your PRS have comments and the less comments are better, and the less comments is probably also the more you are aligned in kind of their train of thought and executing whatever needs to be done. That's I really thought about that too much, honestly. I mean.
It can also happen because you have this level of seniority where everyone already thinks of what can go wrong or what might be missed, and then that's kind of out-of-the-box already in there. Yeah. I mean, we have people like, let's say I say on average we have like two to three people that know a specific area, OK. That's more or less the average of the company. So it's always like one person makes the PR, the other person reviews it, and it happens that people just miss stuff, issues
go through. Yeah, that's bound to happen. Interesting. Especially at our pace, if we go like we rather land stuff and then fix, then I mean we still rather actually fix, like get it right on the first time obviously. Obviously it can be prevented, yeah. Yeah, but sometimes it's just easy actually, even to just land it and then fix it afterwards. Yeah, depending on what it is. But then there's, there's definitely knowledge silos there, no?
And things that come to a standstill of those two or three people are all on holiday. Or do you also find yourself working in those, let's say, areas of specialism? I mean, it depends honestly on the, like, necessity of something. But mostly it actually people stay on the basically on their track of what they know and what they do. Yeah, Like, I do a lot of web
stuff. So there's me and there's Luca, my colleague, and that's like maybe a third person there is as well that does web stuff, but that's basic. But really it's just me and Luke. Yeah. And then like there's on the TypeScript side of things, like TypeScript support, it's basically just nearly one person. I mean, there there's also another person that obviously has to review them like he knows as well. But like that actually does the work on anything TypeScript
related. That's basically one person and like, yeah, that's for other topics as well, like LSP support, like that's a thing we have. That's also one person and then one person that reviews interesting. But yeah, it's mainly actually one more like one that actually has in depth knowledge into the specific field and implements it and so on. It has a bit more higher knowledge, more generalized depth reviews. Yeah, interesting balance.
How much do you share knowledge then of each other's specialism? Or is there also like just because of the speed and the delivery, not a lot of time and attention for it? Yeah, that's not that much shared knowledge base. I mean some there's some things obviously, but many things not like for example for the web, not really because me and Luke and that's basic. It makes sense. There's some other people that know a bit here and there but like they're not in depth into. In it.
So, yeah, I'm asking because in previous projects we always advocated for, we don't want many knowledge silos, right, when it comes to implementations. But then we're not working on such low level things when it comes to, let's say the components of ACLI, which is open source, Yeah. So there's different time and attention towards that. Yeah. I mean, ideally more people would be more sharing the knowledge. And so I mean, we don't want to do that. Of course, like we split the CLI
team into two parts. We have the CLI team and then we have the ecosystem team, which is where I work on, which is the JSR Fresh, which is our like front end framework. LSB related stuff I think falls into that maybe as well our standard library. So basically everything that has to do more with the ecosystem and in that ecosystem, can we do try to share the knowledge a bit more like as people that work on the standard library to look at the stuff related to like
documentation generation? Yes, there's like some overlap between that. The documentation generation for the standard library, I would interest the people of the standard library, but also there's the actual creating of the documentation generation that like that. I need someone to review that. Then I have someone from the standard library being able actually to review the stuff. Interesting. So there's some more sharing of knowledge happening, but it's very, very slow.
Yeah, yeah, yeah. It depends. If like there's a project that's high priority, then there will be more knowledge sharing for that specific project. Yeah, yeah, At the end of the day, I mean, time is finite, right? And I think people underestimate that. I think it would be kumbaya to say there's no knowledge titles and everything knows everything about the whole code base. So you have to make decisions
there. And I think it's very interesting that the focus is on, let's say, creating value and delivering. And therefore there is less knowledge sharing than you would have, let's say, in a in a different type of setting, in a different type of organization. And I think there's a right or wrong. That's just a decision that has to be made or has been made. Yeah, Yeah. Which is very interesting.
As a last train of thought, I was wondering how many times or how often has it happened mainly from the past where people that contributed to Dino from an open source perspective at the end of the day got a career also at Dino? I mean, I would say, OK, no, nowadays not anymore. But at the beginning, of course, basically everyone, yeah, everyone started contributing at Dino and then joined the
company. I mean, we think, I would say it's only like in the recent two years that people actually join not through contribution, but before that it was only through contribution basically. Yeah. Obviously we grew as a company so we had more needs for like, I don't know like Sr. ES and then well, you cannot really contribute to the Dino as an SRE. So like obviously you join directly to the dual deploy team
and work on that. And so that's not through contribution, but we for a long like I would say I could half of the company is through contribution, maybe even a bit more. Yeah. Is that still a good way to go about it? You think when you are looking for a job that that's a possibility or is it kind of a long shot because you landed it? I'm very curious in your take. It depends. It depends on the company. It depends on what the company's focus is. It depends on, well, you as
well. You actually do the job. Well, Yeah, that's always an important factor. But yeah, it's mainly depends on the company. If they need more people, if they see that you are fit for the role, if they see that you do good work and that you output a lot of work. But the problem with outputting a lot of work in an open source project is that you need to invest a lot of time. Oh, yeah. And most people can do that because they're working at something else. Yeah.
So that's it's a tricky issue. It's not an easy path. No, it's not. It's it's quite tricky. I mean, for me it worked out well because I dropped out of high school and then instantly, like half a year later, COVID started. And then then, well, it's COVID. I'm home anyways. Might as well just do something. Yeah, somehow worked out. Yeah. Like was not expecting this. What's up you? Grab hold and never let go. Yeah, yeah, yeah, I get that. I, I really want to thank you, man.
It was really fun kind of picking your brain, seeing how it works behind the scenes that you know, as well as touching on numerous different aspects. Is there anything you still want to share before we round off? No, but I mean try out JSR I guess, Yeah, try it, you know, try it fresh, like try our ecosystem out. Yeah, people think we are not production ready for some reason, but we have one point O already released like since three years. So like it's one point O for a reason.
Yeah, yeah, yeah. Great. Cool. Then I'm going to round it off there. Thank you so much for listening. Let us know in the comments what you thought about this episode. And again, thanks for listening. We'll see you on the next one.