It's, it's been years since I actually created the resume.
Most of the jobs or companies I've now worked for was true.
Folks approached me on get up. I think the bigger problem for
open source is at the moment, it's sort of being killed with
kindness and a lot of slop from people that are trying to
contribute. I look for like active
contributors, Then I look for their pull requests and I feel
they're on the ones that are merged and I just try and sort
of copy their style. It reduces the cognitive load
for a reviewer to understand what you're actually proposed if
you speak their language. I don't want to lose my
identity. True using agents, but I think
you should use them. But just don't let it sort of
steal your identity. Don't outsource your thinking to
it. Yeah, that's how you maintain
ownership. If you've ever thought about
contributing to open source but you haven't actually started,
then this episode is for you. I'm joined by Bruno Scott Sperka
and he is an open source legend. We discuss how open source has
shaped his career, what the impact is of Agentic on open
source, how to make it easy for yourself to start and for the
maintainers to actually merge your pull requests, and much,
much more. So enjoy.
I think open source is one of the coolest things we have
within this industry, specifically in tech and haven't
been in any other industry. So it's easy to say, but I
wonder what role open source has played throughout your career.
Yeah, it's pretty much shaped my career.
It's a form of escapism for me. So usually after my 9 to 5
different customers, I find myself working on projects.
Terraform has been a huge sort of ecosystem as well as the tool
itself that I contributed to which event.
Eventually they ended up me leaving Zbia, where I'm
currently employed at, to work for Hashicorp, which was quite
cool. So part of my career I would say
I thank to to open source. And it's that form of, like I
said, escape escapism. I get to I'm, I'm quite of an
introvert person. I like to put my headphones on,
get some solo time. And instead of reading, like
instead of reading fiction or watching a movie, I quite enjoy
sort of shaping as if you were a chef, shaping the kitchens and
pans and pots you work with. I get these shapes sort of the
tools that many of my colleagues work with.
It's quite rewarding in that sense.
And it has allowed me to build up a lot of confidence in the
pride I take in the work we do and the artifacts that I
produce. As an engineer, I, and when I
mentioned that is I really value the artifacts that I produce.
So the code that I write is is just part of it, but also how I
propose it to a team or a project where and how I write A
blog about it. A lot of people that I work with
or that have seen my contributions will see that
sometimes in GitHub you can see how many times you edited a
message. I sometimes find myself working
on a PR for an hour and I spent about two hours or three hours
on the actual proposal or sort of the PR description and I it's
added it like 15 times because I'm trying to find the right
right works for it. Why is it specifically open
source contributions? Why aren't these just personal
projects? Because I know a lot of people
that do projects and they they really work in their own kind of
sphere. But you continuously work and
you provide, I mean, you Polish tooling is what you mentioned.
Yeah. It's the it's the gift I provide
for the community. Well.
Why is that? If you look at how some
companies approach this open core model is where they get
sort of rapid feedback and free test users.
I like to produce code, share it with colleagues, but also get
feedback on the things I do. I think it has a feedback loop,
yeah. And have you, because typically
what I've heard my colleagues, for example, they want to
contribute to open source, but then their PR gets stale or it
stays open for a long, long time.
And then when they get feedback, it's like maybe nitpicking or
maybe the whole solution direction was just wrong.
So that investment, not just the time investment, but also like
emotional investment, people want to close their PRS, They
want their changes to be merged. That's the feeling of
fulfilment. When it stays open for a long
time, I feel like they'll lose it and they probably won't
contribute any more. How do you accommodate for that?
Yeah. That's a very common problem, I
would say in open source. I had the exact same experience
when I started out as anyone that tries to contribute to a
project for the first time is sort of trying to find its way,
right. Just writing the code is one
thing, but the way how you create your PR, how you, what
kind of title you use, what kind of commit message you use, all
of those are sort of part of your contribution.
And how I at some point navigated that is I just in
GitHub, there's a great way to figure out who contributes the
most to, to the repo. So I look for like active
contributors, then I look for their pull requests and I filter
on the ones that are merged and I just try and sort of copy
their style off of the maintainers that are proposing
those PRS or merging things in. It reduces the cognitive load
for a reviewer to understand what you're actually proposing
if you speak their language, if you do something that's
completely the opposite. Usually when I review PRS on my
projects or projects that contribute to that are not
confirmed to style or the documentation we've published, I
don't want to say that I, I would say I sort of mentally
parked them until I get some, some time to sort of dig into,
into their proposal. Lowering that cognitive load for
maintainers is something I think is, is really important.
It worked for me, and it worked for for those who I advised to
do so. This is really like knowing your
audience, which is for me it's a bit counter intuitive because
sometimes I've had conversations with people and I was also like
this, This is the way I like to structure my commits.
This is the way I like to structure my PRS.
It's very personal, but you are offering something that gets
merged into a greater whole. So your audience is the people
that are going to review this that are like the the gate
between you and the merging. So accommodating for that.
It does make a lot of sense, yes.
I've never thought of that though.
OK, it's really cool. Hereby I would say try it out,
yeah. Yeah, So then that makes the
process a lot easier for me, especially when I think about
contributing to open source. It's open.
I feel like I'm a little bit naked, which also means that
especially early in career, I advise people to do it.
I feel like it's good. I agree with you.
It's really good feedback. It's solid, but there is also
always the sense of imposter syndrome where it's very much
out of your comfort zone if you've never done it.
I feel like if you do that continuously, if you're like
you, you probably have an opinion on how you structure
things and you take pride in that.
You've become good at that. It's easier when you're good and
it's not easy when you're not good.
How do you accommodate for that or what would your advice?
Be so, I would say I read a lot of code, read a lot of open
source code, try to understand how other people do this.
I would say the way I write code nowadays has been shaped by open
source and it has obviously been shaped by the code that read
through my 9:00 to 5:00, but it's somehow different.
I think a lot of people unintentionally or unconsciously
take inspiration from how open source code is is written,
especially those that contribute to those projects.
If you are a beginner that finds yourself in a position where you
either feel this sort of imposter syndrome where like,
oh, am I good enough to contribute or not, I would say
spend time reading code. There's there's tons of amazing
projects out there that keep a really high bar on code quality.
Find something that's within your knees or niche or within
your industry. For me, oh, it's Terraform and
Terraforms ecosystem. Mitchell and Armand and and
Martin Atkins and a lot of folks over at Hashicorp spend a decade
building an amazing ecosystem. And most of the Go code I write
nowadays has been shaped by sort of reading all the code from all
those projects. So read more than you write to
begin with. Gotcha.
Yeah. And this also this, the fact
that you do this, it gives you energy because all the people 9
to 5, they're like, God, this is my tech stuff.
This is my regular day-to-day things and they don't want to do
more tech things outside of work.
It does, it does give me energy it, but it's like I said in the
beginning, it's also a form of escapism for me.
I'm a bit of an introvert person, so you won't see me in,
in clubs or bars or, or or whatever.
So that's definitely a form for me to sort of escape from, from,
from live and personal things and and work on these projects
on the other side. It's being able to I I use for
example Terraform or Kubernetes a lot.
Being able to also contribute to it allows me to better
understand the tools that I work with.
Oh, that's smart like a. Like a chef that gets to design
their own pans and knives. It also allows you to position
yourself in a surgeon. It allows you to position
yourself among your colleagues as someone that can be perceived
as someone having a certain sense of thought leadership on
how these tools should be used as you get to sort of speak
behind the curtains, which I think is is really important.
My first contributions started, funny enough, at Zebia, actually
I was working at Adidas and they wanted to build an machine
learning platform on ABS and a lot of the resources that we
required for services were not in the Terraform ABS provider at
that time. So I figured, you know, maybe
I'll just give it a shot and, and contribute something.
And my first contribution got merged relatively quickly and I
got to bring this to our customers thinking, OK, I, I
sort of unblocked you. We now get to use these, these
new Terraform resources that I added and they were quite
impressed, which positioned me as a consultant in, in a good,
in a good spot. And that was quite satisfying
that feeling. So that's when I started
contributing more and contributing more.
That's how I would say my contributions begin.
Gotcha. Yeah, I, I remember time and I
think this triggered me like 5-6, seven years ago, kind of
early in my career where we also were working with Terraform and
there was something that we needed that was not supported.
So one of my colleagues just built it.
As a guy, you just built the thing.
He's like, yeah, I'm like, man, this is what senior engineers
do. They just build something and
then it's contributing to oversource.
I thought it was really cool, but then I never took the
conscious step to actually start doing it myself.
Would you advise people to start contributing to open source in
any aspect of their career? Does it matter if you're early
in career or more senior or what's your take?
I think and this is something that I would say I plus one with
this opinion. It's something that Mitchell
shared Mitchell Hashimoto. He said some of the best
engineers don't have a great get a profile and don't spend all
their time on social media or or writing code outside of your
9:00 to 5:00 because they are the ones to lease contact
switch. It doesn't really you don't have
to be you don't become a better engineer by forcing yourself to
contribute to open source. But if you generally are
interested in understanding how some of the tooling works.
So we as currently in my position as a as a engineer here
at Xebia, I use a lot of software.
I get to build less. So I get to build on top of
Kubernetes. I get to use Terraform or
ADOSCDK. But they don't get to build
those tools from scratch. And that is something I was
missing. I'm a software engineer by by
heart, but I now end up just using like AP is and writing
configuration files for me to better understand Terraform, I
started contributing to it. But if you find yourself already
writing code from 9:00 to 5:00, I wouldn't say you usually
benefit off of contributing to it.
The the only angle that might be interesting is sort of the
social aspect to it. Nowadays a lot of folks can
contribute to open source using AI.
But part of your contribution is the research you do.
At first understanding the different GitHub issues, even
looking whether there is a GitHub issue or not making one
according to the documentation. Then joining like this community
hour where you present your own research and sort of the patch
you want to create or the fix you want to propose.
I think that is something a lot of engineers could benefit from,
which are sort of the social aspects of it.
Last time I spoke about open source on the podcast in and of
its own, I got a comment that says, oh, the Primogen had this
podcast and he was saying don't contribute to open source.
And they were actually talking about this other video which had
millions of views, I think above 5 million views.
It was about something related to Kubernetes.
And they said, well, you just go here and here to this repository
and change the read me. And that's what people were
doing. They were bombarding this
repository with all read me changes and like, damn, this is
like the dark side. This is the downside of telling
people to contribute to open source.
And they don't necessarily provide value.
They just provide change. And change is not always good.
I feel like it needs to be valuable.
Yeah, there's a high signal to noise ratio at the moment and
there has always been before AI as well.
AI has lowered the contribution barrier for a lot of folks, but
before that people just wanted to get their name into the list
of contributors, which I think there's nothing wrong with.
Changing something in a read me if there's generally A typo or
whatever as your first contribution is a good way to
get familiar with the process. I think the bigger problem for
open source is at the moment, and that's how I feel, it's sort
of being killed with kindness and a lot of slop from people
that are trying to contribute what?
Do you mean with kindness? Well, there's a lot of people
that people don't just randomly target repos and and run an
agent against it. People generally want to
contribute, but they don't want to put in the time and effort.
There's this filter on on open source contributions.
There's a filter on open source in general.
It's consistency and commitment wins over sort of beats
intensity. It's easy to generate APR using
an agent, but making sure it's conform the language of the
maintainers and according to the styling and showing up in that
community hour, that's another thing.
So yeah, there are tons of, I think if you look at, I think
Carl recently closed his Buck Bounty program because it was
sort of bombarded with. With.
Attempts. Yeah, with attempts, most of
them which were making no sense at all, there might be genuine
intention from people because I like to assume that I don't want
to assume the bad and the worse than people.
But it is a burden on maintainers.
And maintainers are sort of now in this stage where if you put
in 5 minutes, then I will put 5 minutes back of my time into
reviewing it, which could mean, oh, it's generated by AI, so I
will close it. Yeah, that's what some
maintainers do, which I think it's it's, it's sort of putting
a burden on maintainers. Yeah, I feel like the the burden
on maintainers was already there and now there's this trend of we
just have so much execution power, we can generate a lot.
I feel like reviewing in and outside of open source is going
to be a problem we need to solve because we are creating so much
code. And then there's not many people
that review as much code. I think as open source
maintainer specifically, especially if it's something
that they've built up from scratch.
It's like something they take a lot of pride in.
They will put in the time and effort to do that.
I genuinely believe that. But I'm also the same.
If I get bombarded with messages that say I want to edit for the
podcast, I'm like, yeah, well, I can only do so much.
So at some point you just see it as noise, which is a shame if
there's people in there that genuinely want to contribute.
But I don't know how to solve this problem yet.
Yeah, it's, it's something I find myself struggling with as
well. It's interesting.
So a lot of maintainers take different approaches to this.
Mitchell, who I, I used to work with at Hashcorp who
unfortunately left now build Ghosty, which is a terminal.
He also deals with a lot of like AI contributions and he's
working or prototyping a system called Vouch where instead of
sort of trust by default, so anyone is a great contributor
and anyone has good intentions, it's now sort of a deny by
default or reject by default as and you have to prove yourself
as a trusted committer first. So that is one approach that
people take. And he just sort of straight up
closes your PR if it's, if it's slop and the next time if you
create APR, it gets auto closed. So that is one approach I
understand and I see his reasoning behind why other, I
think the Flux team. Flux is a very popular
Kubernetes deployment tool. I won't bother with introducing
what the whole project is, but they also have an interesting
approach is they, if you raise like a, a, a bug issued, they
are saying, oh, there's this race condition in, in this and
this code bath. Instead of spending hours as a
maintainer trying to understand and reproduce this, this race
condition, which is a very hard problem, they just throw a bunch
of agents on on this issue who try and replicate what you're
saying. So they are not the ones anymore
that spend the time on it as in the maintainers, but they
outsource, outsource this thinking and reproducing to
agents. Cool.
So there's a various approaches to how many dealers deal with
this. And I don't know what the right
right approach is. Do you, do you yourself use any
agentic tools when you contribute to open source?
Yeah, you already mentioned you have a lot of like passion for
the craft. So do.
You. I do.
I do, yeah. IAI is, in my opinion, like a
it's a revolutionary tool and I would be crazy if I were to say
I'm not not using it or not going to use it.
I use it as sort of a bear programmer.
I love bear programming. It's what I used to do before AI
and I would pick someone else's, someone else's brain.
I let it generate some code. Sometimes even I would say 2 are
in parallel and see what sort of differences are.
I use AMP to do a lot of like researching of of deeper code
bats and understanding larger code bases.
And I use clawed through open code to work on features and
things like that. But I take a lot of pride in
what I eventually propose. So it might be that I work on a
feature in a in on a project for like half a day or two days, and
I spent a whole lot of day polishing up that code, making
sure I understand everything, crafting a proper PR description
because I don't want to lose my identity.
True using agents, but I think you should use them.
But just don't let it sort of steal your identity or don't let
it out. Don't outsource your thinking to
it. Yeah, that's how you maintain
ownership. That's for me is the biggest
risk because now generating code has become easier.
So it's also the E it's, it's a very small step to do a lot of
it basically, but a lot is not always better, which means that
if you do take pride in this and this is kind of what you
perceive your craft, you still need to maintain ownership of
it. And that for me is interesting
because not everyone has the same passion or the same vigor
to actually own this thing. So then you get generated a lot
of things, all the things we call slot nowadays and it.
Was liable for for the things that are being generated right
is it the agent or is it the author of the code I I generally
feel myself as an an author of code when I when I produce
something when I write something whether it's in the read me or
whether it's a comment on a function or whether it's a new
struct I introduce or a whole new functionality, I see myself
as the author, which results in me being the the owner of this
piece I think that is really important yeah a lot of people
just. Push code without assuming that
they'll have to ever fix it or own it, or that they're liable
for it, no. I was talking over lunch with
Nico guest that came on the episode air probably last week.
And he was talking to me about this very Tessium video that
came out. So YouTube channel and they
talked about someone that hacked something in an open source
project and that almost made it into quite a lot of systems,
which gave me a thought because right now I can make AI think
anonymized account on GitHub. I can contribute a whole lot and
someone will never know who I am, which also means there's not
really any personal information within those accounts.
And I'm wondering if it would be better maybe for the industry if
there was a one-on-one. Patrick, is this on GitHub?
Like I am also on LinkedIn. I'm wondering how what your
thoughts are on that. Interesting one.
I think it is important to understand who's contributing to
your project. But if a patch or a proposal or
a piece of code makes sense, I wouldn't be rejecting it, but
proposing as, as when you're contribute to your project or
when you become like sort of a trusted contributor.
There's, there's sort of levels to this, right?
In some projects you sort of graduate to different tiers or
levels or ranks. So on certain projects, like a
Crow cube resource orchestrator, I got certain permissions to do
things go on certain tariff from repos.
I previously before I worked in at Hashi Corp I had the ability
to triage issues or clothes or merge BRS.
And these are earned rights. These are earned rights and
that's I think where you have to be careful with who you grant
this to. Maybe I think for most of the
projects where I ended up with like more permissions than I
would randomly grant any other contributor is I met the repo
sort of owners or the team behind it in person as well.
And that happened to like keep con or AUS reinvent.
But yeah, I I would never reject the PR if it made sense.
But when it comes to handing out permissions, I would like to
know who's who's behind the profile.
Yeah, makes sense. You met these people in person
and you actively going to form that connection with them
because you're also mentioning like you're introvert.
Me, I'm all, I see myself as introvert as well, even though
I'm a little bit more extrovert on the podcast.
I guess see myself as kind of different people in different
circumstances, I guess, but stepping up to someone in a
conference is still something that I find kind of quite
daunting, to be honest. How did you do that?
I tried to approach folks through Slack first.
I have an asynchronous, asynchronous communication
relationship with most most folks in in open source.
We don't, we don't video call or or do those things.
Now we we chat. People know each other by their
get up handle. But at some point I did like the
projects that I consistently contributed to and spent most of
my sort of evenings and nights to at some point when I at some
point you sort of meet each other at a, at a cube con or an
Atos reinvent or Google next. And for me to be able I, I, I
quickly, I think I realized to get more, I don't want to say
authority, but you get more ownership on a particular
project. I had to introduce myself.
It's. Trust.
It's trust. Yeah, this open source is built
on trust. So I, I went ahead and like for
Crow, for example, Cube Resource Orchestrator, I reached out to
the maintainers of that project. There are some folks over at
AWS, Microsoft and Azure. And we met at Cube Con and we
sat down and they talked me through the potential things I
could contribute to. And during the conference, I
went back to my hotel room and started contributing to those,
to those items. And the next day we met up and
he merged them and we spoke about it.
And it's been a huge trust builder for, for the Budfuss for
me as in like, oh, there's, there's good leadership on this
project. And for them, this is an actual
trusted contributor who wants to sort of advance this project
forward. That's really cool.
And there's no other exchange. There's no I don't pay them,
they don't pay me. It's my.
You also don't expect anything. I don't expect anything.
No, no. Funny enough, you sometimes do
get something but. You don't expect.
It you don't expect it, no. And I think that's an
interesting one. DHH David Heinemeyer Hanson once
shared is never run an open source project as a business
because you will then you, you build something.
I like I said before, I give my code to the community.
You don't get the mandate what goes into my project.
You absolutely do not. I, I will consider it, but even
if it gets 100 uploads, I might still reject it for what it's
worth if it's not in line with my vision.
And I think that's an important one.
Some people do do sort of community driven development as
they view that as their road map, whatever the community
says. But a lot of solutions that are
proposed might, all might sometimes not be the best
solution or are not in line with your thinking or vision.
Yeah, I think sort of what what David said was a community, open
source is not a community nor a democracy, which I think is
something that's pretty powerful.
Yeah. Nice.
I am wondering and probably some listeners are thinking, OK, I
understand open source. I've always given the advice of
I do think it's quite valuable both for your skill set, but
potentially for your career and the potentially is quite a big
thing like you mentioned, if you value this craft, you kind of
find this passion for contributing and there is no
expectation that this will have certain outcomes.
It's a belief that you need to have and it's consistency.
I feel like without that consistency part and that
consistency is still vague because it can be in very long
time or it can be in shorter time.
But I do think it's quite valuable especially in the
current market where getting your foot in the door is very
difficult. I saw this post on Reddit person
that said I've hired hundreds of engineers now.
All the profiles I get are custom tailor made based on the
job description that we have and they all look the same.
Which means how do I then filter the resume part already in and
of its own? And if that becomes very hard
then getting your foot in the door you need to think of
alternatives. I think open source is a good
alternative. It is if you look for
alternatives you can consider contributing to vendors she
would like to work for right? And but I wouldn't recommend
starting to contribute to a vendors project with the
assumption that you'll be hired one day.
Similarly, opening opening a business to assume you'll be
become rich is also not a great plan, right?
Find something you love doing and execute on that and be
consistent and then hopefully you will be recognized by those
that benefit from your contributions.
I've been recognized through like get up sponsor programs
where I randomly got money from, from folks like a lot of money,
which I never understood why they would send it.
Send it. That's cool.
There was someone sending like hundreds of of dollars over and
over which I never spoke to. But you do you know for what?
I have no clue. It might be some.
For your legacy, yeah, it might be some random contributions
that I did to one of one of these projects that usually
benefited them. Yeah.
It might also be for something else, I don't know.
But that's not what I do open source for.
It's it's, it's sort of this, this, this craftsmanship and me
trying to position myself as a thought leadership in certain
tools and industries and niches. And I happened to be offered a
job at Hashicorp. True.
All the contributions I did because I positioned myself
within that community and within that ecosystem and in addition
to creating those PRSI attended dozens or more than dozens of of
community hours and road map sessions with those teams.
I attended multiple times Hash Econ for just the Hash Corp
conference where I spoke to the teams directly that I
contributed to and some other folks.
So that is that consistency that can get you somewhere, but it
can also get you nowhere. And you shouldn't be
disappointed if it doesn't get you anywhere.
But it does. Help if you're surrounded by the
right people. That's the part that
contradicts, right? Because the there might be an
outcome, but there might not be. So I don't think it's bad that
you have the intention that there might be an outcome
because that's reality, right? That's a, that's a maybe.
But in the end, the fact that you might get disappointed,
that's the risk. In the end, I feel like you're a
person that is very due diligently doing their work and
their effort and that you also get energy out of this.
Otherwise, you would have never made it work, right?
I feel like I can do a lot of things, and with discipline, I
can do a lot of things for a long, long time.
But the things that I've done for the longest, they also give
me energy back in return. Because otherwise you're just
drained. If nothing counterbalances the
effort that you put in. If you don't get energy out of
the things that you do, that's how you kind of lose passion for
the thing that you do in the first place.
It is. That's with a lot of things.
Actually, it is. And I think something that's
probably, I've never shared that in, in, in public speaking
before, but I'm, I'm a university dropout.
I changed university for my first software engineering gig
as they approached me during my, my, my second year.
And after after leaving uni, I in my view, had a pretty
successful career as a software engineer.
But moving from company to company over and over, you do
have to sort of extra prove yourself somehow.
There's no fancy certificate or diploma that I that I can put on
my resume. So part of my resume is also my
contributions. I it's it's been years since I
actually created the resume. Most of the jobs or companies
I've now worked for was true. Folks approached me on Get up.
That's very cool. That's like the status that
you've built up. It's rewarding, yeah.
It's also sometimes interesting because I've also had recruiters
asking like hey why was there no activity between month X?
And Y it was a holiday. It was a holiday.
Or conference season. Or.
You have to explain yourself. Yeah, that's something a little
little tough and people sometimes do expect something
from you. Currently I'm doing construction
on our house and trying to sort of understand what marriage is
because we're trying to engage and I haven't contributed a
single line of code to open source for the past like few
weeks. And I wasn't sure if I had to
feel guilty about this or people started commenting on PRS like
hey can I just get reviewed or hey what are your thoughts on
this? Some of my draft PRS were even
closed because things just took too long and things move on
right? Open source doesn't wait for you
unless it's your project and you own own everything.
But yeah, I was also trying to consider should I post something
on social media or not? Like, hey, I'm currently dealing
with life. I'm not always on.
People sometimes expect you to be always on.
I spend a good 16 to 20 hours sometimes on on sitting behind
my computer and suddenly going to prioritize things in life.
Is interesting how the community response to that.
Yeah, I like your balanced approach, though.
Like some of my friends have said, building has become so
easy now that if I don't build, it's almost like an addiction
because now is the time. And now tools are still a lot
more affordable than potentially in five years, which means that
this is the adoption phase. And once they have a lot of
users, they can slowly up the prices, which means I want to
get the most out of it. Right now.
It sounds like there is an addiction in there.
Did you ever get to a point where you were like, I, I have
to contribute and I have to do this continuously because now it
sounds like you've kind of let that go.
Yeah, I think there was. There were times where I tried
sort of trying to prove myself. So open source and vendors
notice they do a great job at like having different tiers and
ranks. So you can become a Terraform
core contributor or an AWSCDK distinguished contributor and
you have to do, you have to meet certain metrics which they don't
share with you. So the amount of like PR she's
opened or Commons she's boot or there's a different type of
metrics where they try and measure actual valuable
contributions. That's a metric that they get to
decide. And sometimes it's a little hard
for you to understand. Am I going to miss the boat or
not? This year I was lucky enough to
be 4 years like a recurring core contributor, but I never
understood where that threshold was.
So yeah, sometimes I did feel like I have to contribute and
that was sort of to meet those, those levels which don't really
mean anything besides a badge and AT shirt.
I guess that's what we that's what I do open source for.
But there's also been times where I, you know, life was a
little harder. And again, this sort of escapism
was a worked well for me to sit behind the computer and just
contribute, put my headset on. No meetings, just pure me
writing code and and solving problems.
That's something you have to enjoy.
So the same as some folks would turn on the PlayStation, which
could be an addiction or or a form of escapism.
I happen to enjoy doing this, Yeah.
I like that a lot. And I think the sort of the
network you build up true, like LinkedIn and people reaching out
to you, that is it's rewarding. It's a great community to be
part of. That's great.
Yeah. For me, the I really admire
people that have really called acquired skills and for me the
acquired skills that you can do kind of building in public or in
this manner are just very cool. Like it's not something that
I've done in my career, but it is something that I admire.
If I would go back, I don't think I would change a lot of my
own career because I like where I ended up.
But that doesn't mean that for someone else it's not a good
choice. I feel like it's a very solid
way of working and way of acquiring skills, which is just,
it's very cool and very unique I would say and.
I think another thing that could be really interesting to folks
that are new to open source is something that was very valuable
to me is you know, you don't get to easily pick where you work,
right? I would love to work on certain
Google service teams or like ABS service teams so they just don't
happen to hire in the Netherlands or in Europe.
A lot of like interesting service teams are over in the
US, but still there are certain projects.
And the reason why I'm saying it is like, I would like to work
with some of the people that work there to be able to pick
their brain and understand how they think.
I started contributing to Crow, which is a joint effort by
Google, Microsoft and Azure. Google, Microsoft and ABS.
And when you join those community hours and when you
speak those maintainers, you get a chance to pick their brain.
I I get a chance to talk to the one of the principal engineers
that works on Amazon ETS who also happens to be a Co founder
of K surf. So you get to really learn from
these these people, and I think that is very valuable.
I feel like there's quite a close way of building a
connection rather than, I mean, they are overseas, they are in
different companies and I've never thought about this
perspective, right? Where communities come together
is where you can find people like that, which is very neat.
And just be able to learn from them sort of for free is, I
think awesome. We've covered a lot with regards
to open source, also your career path and what it is meant
throughout there. Is there anything that we still
haven't discussed which you want to slice open before you leave
off? Free money spot?
Interesting one? Not necessarily, no.
I wonder because right now the bar for entry is quite easy to
open source. Do you think it's going to get
harder because the the thing that you mentioned it wasn't Val
or it was the other V vouch? Yeah, vouch.
That that will in the end, if the vision of Vouch holds true,
then some projects might just say, well you have to have X
amount of. I see it as a point system, a
ranking system. You have to have a certain rank
which makes the open source not that open for contributors.
Yeah. I think something I would like
to share with folks is like, I think a genetic tool learning to
generate code is, is amazing and it gets you to contribute to
some of these projects. But don't outsource your
thinking to it and don't let it sort of take away your
personality and your craftsmanship when you
contribute to these projects. We as a maintainers and other
maintainers of different projects love to guide people,
especially beginners through their first contributions.
But it is also true, and I think I think it holds true that we
also expect a a certain form of effort.
And if you put one minute into something without APR
description, it's fair to say that I'm I'm allowed to spend
like an another 5 minutes or 10 minutes on this as well.
If you shape your contributions, don't.
Don't outsource your thinking. Yeah, and your personality?
Perfect. Brion, thank you so much for
coming on. This was great.
Thank you, Patrick. If you're still with us, let me
know in the comments section what you thought of this episode
and we'll see you in the next one.