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.
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.