Next speaker, I'm very happy to have him because he called him only last week and asked, could
you speak at the Go Devron please?
Because we had a cancelled talk, apparently immigration out to the UK is a problem post
Brexit.
And he said yes.
And why did I call him?
Because last year he also had to say no to me.
And he promised me to give a talk.
And he's going to give the same talk he promised to me last year, which is basically I could
develop a page at Google and here's why.
A round of applause for Filippo.
Thank you.
The good news is that this is a much better talk than I would have given a year ago.
Because a year ago I had no idea if this was going to work.
I have good news.
Anyway, first a bit about me.
I'm Filippo Valzorda.
I've been the maintainer of the Go Cryptography Standard Library since 2018.
And that's a job I've shared over the years with Katie Hawkman, Roland Schumacher, Damien
Neal, Nicola Moreno and many others, to be clear.
I was doing that at Google until 2022.
So I was on the Go team.
The title I had was the leader of the Go security team.
And that's the team that did things, including the fuzzing support that we were talking about
earlier.
Until 2022.
Because in 2022 I left pretty much to prove a point about proving that something was possible.
And the something was, actually, let me tell you a story first.
Stop me if you heard it.
You're maintaining an open source project and that open source project has two kinds
of maintainers.
Some are volunteers.
So you don't really feel like you can ask any hard commitment of them.
You can tell them, well, Alice, you really told me that you were going to fix CI.
Why isn't it fixed?
Well, Alice will respond because you don't pay me.
And what do you say to that?
Nothing.
Yes, exactly.
Thank you for your help.
And the alternative is you are employed full time at a company.
And that company is a reality of capitalist society, which I say with no value judgment
there.
And that company has an interest in making money.
And has an interest in not spending money that will not make money because that's what
a company is and does.
And that company will maybe start a project because it has a bunch of value for recruitment
and for internal infrastructure.
And it will fund some maintainers because it goes like, yeah, yeah, this is a good project
and we should make it into existence.
And that's great.
That's the company contributing something to the world and we should appreciate that.
Then the project grows.
Now does the value of that project to that company grow?
Not really.
So the number of users double and then double and then double and then double.
And they start filling rooms and conferences and that's great.
And do you think the number of people working on that project fully paid by a company grow?
They do not.
And some people get angry at the company and they think that's misplaced because why should
a company say, oh yes, this is more useful to the world so we should sink a lot more
money into it.
I mean, hey, if it was my money, sure.
But you're a manager at a company, it's not your money, it's the shareholders' money,
it's not really even a thing you can do.
So now you have a problem because success of the project puts the project in a difficult
position.
And I said, stop me if you know this one because this is not around about go.
This is not about Google.
This is not about any specific case.
If I had seen this only once, I wouldn't have said, well, this kind of needs a fix.
This is something I've heard over and over and over again, all over the industry, all
over the past 10 years, all over different companies.
Because this is fundamentally an issue in alignment of incentives.
So the problem is that critical open source projects that we don't have a sustainable
way to maintain them.
And I'm not talking about contributing back, I'm not talking about integrating a new feature
or anything like that.
I'm talking about the grant work of going through the issue tracker every morning and
say no, no, no, no, no.
Which I guess is tinged by what I do, which is cryptography, which most of the times I
want to tell you know about.
And if I said no to anybody in this room on the issue tracker, I'm sorry, you can find
me later.
But the point is that that work is really hard to fund both in the volunteerism model
and in the full-time employment model.
So what did I do?
Well, I had this hypothesis that there was a way to fund open source maintenance like
a profession.
And the model goes a bit like this, going to companies and offering them retainers.
Making the core focus maintenance.
So not going to companies and say you'll get 100 hours of support this year.
That doesn't scale.
I'm not talking about, hey, do you really want that feature?
I'll implement it for XK.
That's actually kind of, I'm super uncomfortable with that because that means that to make
money you need to add features.
If you add features, you increase maintenance burden.
If you increase maintenance burden, you need more money.
So what do you do?
You add more features.
And yeah, that's a bad spiral.
You don't want to be in that spiral.
And there's also applying for grants, which is a totally valid way to go about it, but
then you become an expert in applying for grants.
And hey, I made a lot of questionable life choices.
I just didn't make that one question of life choice.
So that is the part where people tell me, yeah, but companies really don't want to pay for
this.
So really no way to go about it.
That was the part that I was convinced was not true.
I was convinced that companies can get something out of this because some companies even have
an internal go team whose only job is being experts in go.
Now that costs so much money.
A fully loaded software engineer is like a giant expense.
So my theory was that I could go to these companies and say, hey, do you want a resident
go expert that you can ask advice to and who can liaison your issues with the team and
can help you guide through the contribution process and so on.
And to be clear, this is not offering governance.
This is not offering support hours.
This is just, would you like expertise that you don't currently have access to?
And a lot of people told me, no, that's not going to work.
I was kind of convinced it would work.
So I quit and tried.
And here I want to make a small parenthesis.
This is an incredibly privileged thing to do.
I was able to do this because I had the money from having worked at Google because I live
in a country with a sane healthcare system.
And yes, and because of my personal position and because I knew that I could actually call
up a number of people and say, hey, would you give me a half an hour of your time?
I want to pitch you something.
And we'll get to that.
Anyway, this is almost exactly a year ago, which I did not realize until I made the slides.
I'm pretty happy about that.
So exactly a year ago, I announced that this is what I was going to do.
At this time, I had one, I think one client.
So it'll take until you make it.
If you want to read more about the model, and this was the 10-minute version, but if
you want to know more, that's an article you can find, search engines sort of still work.
So I'm sure you can find it.
Now a year has passed.
So this is an update talk.
A lot of people ask me, OK, so how is it going?
And to be fair, I haven't published much because there's a lot of work involved in doing this
thing.
Now, first of the good news.
It's working.
I have a healthy portfolio of clients.
So far, only one client has turned, and not because they were unhappy about the service,
but for their side reasons.
And I am fairly happy with this.
And this is funding me at the same level as Google was funding me, which I'm not saying
as a humble brat.
I'm saying it because I think it's important that we offer an alternative for maintainers
that is competitive with the jobs they could get on the market.
Because another thing that doesn't work is saying, well, you're an open source maintainer,
so you consume, what, three boxes of ramen a day?
I guess you should go to the cinema a couple of times a month.
So you're going to be fine with like 10K a year, right?
15 maybe, and you can keep maintaining this?
Great, yeah, sounds good.
And then something happens in their life, and they go like, well, maybe I would like
to make more money than that.
And let's see how much money they offer me down the street to a person who can manage
a large technical project with a number of stakeholders and who can coordinate contributors
and who then qualifies as a senior software engineer.
The answer is a lot more money.
And so they stop maintaining the open source project.
And so again, we don't have a sustainable model.
So I think it's important to stress that what I'm going for is something that's competitive
with senior software engineer salaries.
And that's a part of that.
Everybody usually would just kick me out of the room when I would get to because they
would say, there's no way to make it a match.
So it turns out, yeah.
Now, lessons learned.
What got me here?
So a lot of it is sales.
This is the bad news part of the talk.
None of us wants to be doing sales.
We want to be doing software maintenance.
But what I usually tell maintainers on this is, so do you know dentists?
Do you have a dentist friend, a dentist relative?
Do you think they ever stopped for a moment and went like, you know, I really like teeth,
but the whole invoicing people running a clinic, hiring somebody, paying taxes, marketing
my services, nah, that's not my core skill.
You know what?
I'll just do it for free.
Know anybody?
Okay.
And anybody who went like, yeah, so you know, really I'm probably not cut for being a dentist.
I guess I'll just change careers.
Probably somebody, but most of the dentists we do go to just do the parts of the job that
are not core skills.
We'll also get to the advantages dentists have over professional maintainers, but we'll
get to that in a second.
But a core point here is that there's a lot of sales.
So it's enterprise sales.
There are books about it.
We usually like learning stuff, right, when it's technical.
First off, this stuff is also extremely learnable.
And what worked for me is funding champions inside companies and going to them and saying,
hey, so this is the thing I'm doing.
And those champions are usually engineering and they'll tell me, oh, that's great.
Like I want that to work partially because I could see myself maybe at some point doing
that.
But to be clear, they don't let me spend money around here.
And then you tell me, yeah, I know, but you know, the people who do and you can introduce
me.
And so if you can do that, I would appreciate it.
And then when those people go to you, you go back to engineering like, hey, how's everything?
And they ask, oh, so how's the conversation with John going?
You know, he seems busy, but if you could just think it in turn, that would be great.
And then you do this over and over and over and over and over again.
And is it great?
No.
Does it work?
Yeah.
Yeah.
Like every startup in the world just goes like this.
The closings, however, the closings that did work did not take forever, did not take
a year.
They either closed in a month or two, or I am still trying to close them.
Right now.
I am thinking about one person in particular who is a friend and who I am still chasing.
He got, anyway.
The point is, the ones where it will happen soon or otherwise.
What I am offering companies has refined a bit.
Most companies want the whole thing.
I started with tiers and you can get the advisory part and joining, I will join your
Slack and nobody bought the lower ones.
Which hey, okay, great, more money.
At the same time, I feel like I am leaving something on the table by not knowing how
to sell the lower tiers, but whatever.
Fine.
Maybe the answer is that the thing that does sell is that advisor part I was telling you
about earlier.
When you compare it to, look, you could hire an engineer and have them become an expert
in this and have them get involved with the project so that you can go and ask them for
support when you need to, or I cost a fraction of that because I have multiple clients.
Also, there is not as much risk that I will just move on, you know, quit and you will
have to retrain from scratch.
I can't pre-train in the box.
So that's the part that really sells.
And finally, the ongoing, I was a little worried that am I over-comitting, I started slow because
I didn't want to sell time I didn't have.
Turns out my main problem is that some clients don't use enough of my time.
So I'm worried that in a year they will be like, what do you do for us again?
Which is not a great conversation to have.
So I try to keep them engaged and remind them that hey, you can ask me questions.
When I remind them, they come back with questions and then I answer them and they are happy
and that's great but sometimes you have to remind them.
On that something useful I do is that every time there is a release I will send a PDF
being like, hey, this release happened, you should probably patch, here is my opinion
on what you should patch.
A lot of this is sending PDFs.
If you are hoping for the new platform where you register and you get microtransactions
directly to your wallet or something, no, I'm here to suggest getting very good at
Microsoft Word.
It doesn't have to be Microsoft Word.
But yeah.
And finally it's a multi-stakeholder job.
What does that mean?
Sometimes your client will be like, oh, it would be very nice if there was support for
Foo and Cooks and Blacks and all of that in the standard library and I'm like, no, absolutely
not.
And that's a little throat because, and for that it's important to spread out enough that
a single client is not so critical that your palms are sweating when you tell them no on
something.
And it's important to communicate with the rest of the team so that they know your concept
of interest and I try to recuse myself from all of the proposals, for example, that I
help the client's brain.
So if a client really wants to propose something, I'll tell them, look, what I can do for you
is help you present it in a way that makes your case.
I'll help you craft the proposal.
I'll tell you what you should fix.
And then I'll just step back and let the proposal committee decide.
That works.
Anyway, a few words on where this is going next because this is what would work so far.
But really I'm not in this to fund myself because if I wanted to do that I could have
stayed at Google.
They have great insurance plans.
It's a job.
It's fine.
I could have stayed.
So I left because I wanted to make this into a model that can be replicated.
So there's two ways really to grow it.
One is vertically.
I can hire more people and then get them funded and that's a few more people that do this.
And that's kind of unsatisfactory.
Unsatisfactory, sure, might make me more money but it can't grow that much as just the Lippos
thing.
Which, by the way, this is happening.
I've hired the maintainer of SFTP Go to maintain XCrypt SSH which didn't have a maintainer
for years.
And that's only possible because clients pay enough and they're interested in the SSH
package and so I can go back to clients and say, hey, look at that package that you had
the fork.
You don't need a fork anymore.
That's because you were paying me money.
All right.
Don't cancel, please.
But the thing I'm really interested in is growing this horizontally.
So getting other people to start it.
And I'm not talking about starting a platform.
No, no, no, I'm talking about getting other people to say, all right, maybe I can do that
and try their own version of that.
And here's where we get to the disclaimer part.
This worked because I have a network.
This worked because I had already a public profile.
I want to fix that slowly and over time.
What I want to do is to speak about this to enough people and to do this with enough companies
that companies get a little more comfortable with it so that the sale is not anymore.
So here's a whole new thing.
Let me convince you it's not silly.
And then let me convince you to pay me for it.
You can skip the first part and get to a company who's like, oh, yeah, right, we do
that with a couple of people.
Maybe, yeah, that your project is also useful.
Another disclaimer.
This is for critical open source projects.
I am targeting a very specific kind of open source project.
So if this sounds like it wouldn't work for your project, there are two options.
It either you might be surprised that it's actually easier than it looks, or you might
be correct because it's not the right shape of project.
The right shape of project is something that's critical to at least a few companies.
And that doesn't mean something gigantic like go.
Critical just means that how I pitch it is how long would it take to replace this if
you had to?
And then you let them think about it for a moment and they will go like, two, three
engineer years and that's a lot of money.
And then you go like, great, so you would like this to stay maintained.
Excellent.
Then that's the kind of project that I think you can pitch this model for.
And so that's the lowering the bar to access.
I like to think that I started because I have more of a public profile and more willingness
to wear a button down shirt and talk fast, which is very useful for sales.
But I would like this to become something that more and more people can do as it expands.
So maybe the next cohort of people who do this already have a bit of network, but will
have something to start from, et cetera, et cetera.
Then I want to build together the tools to make this easier because I am sort of yoloing
stuff like contracts and what works and what doesn't.
I'm hoping to build training and contract closers that are easy to pass to Liga and say, yeah,
so no, you can't put a complete IP assignment close in that contract because I don't work
only for you, so no, I can't give you the rights to everything I write.
We will have to have a conversation about that.
So stuff like that.
And maybe one day making a professional association around it so that we can even tackle things
like how do you get healthcare in the U.S., which some freelancer unions give you access
to.
Anyway, this is how it started, how it's been going for the past year, and where I'm
trying to take it from now.
The goal is to give the option to maintainers to follow it as a profession, just like dentists
starting at junior and ramping their way up using resources for learning and support
from technical tools.
Because that's the main thing that I think makes it easier for dentists to run clinics
than open source maintainers to run businesses.
It's that you can buy so much support as a dentist.
You can buy books and trainings and CRM software and software to run the clinic that prints
the invoice already with the little teeth drawn on them.
And all of that is actually extremely useful.
We are starting from scratch here because for some beautiful reason, which is why we're
all here, really, open source didn't start as a profession.
It started as hacking.
It started as something we wanted to give to the world.
But it's now critical infrastructure and we need some people to make a living and a profession
out of it.
To be clear, this is not the only way to do things.
I'm not here to tell you every single one of you has to get a button down and a 24-hour
briefcase and start going out there and closing some deals.
No.
But I want that to be an option for the projects that need it and for the people that want it.
Questions please.
Thank you.
Hi, Filippo.
I know you've been sharing this path for at least half a year or more.
So how many people have followed your advice?
Do you know about and how many of them you would say succeeded, which share of the followers
have succeeded?
So I've been actually extremely skittish to ask people to start trying this until very
recently, partially because until I knew that it worked for me, I was very uncomfortable
with telling anybody go for it because...
So really, I've started trying to form a community around this in the last two, three months.
And there are maybe half a dozen people who are aiming for this or angling for this.
Some of them already were going for something similar.
I had at least one conversation where I was like, ah, that, yes, ah-ha.
We kept saying things and just matching notes and it was great.
I think it's too soon to say how many of those are successful.
I'm barely comfortable saying that I'm being successful because it's been a year and after
a year, I'm a little more...
People are not canceling after the third year.
Great.
But it's a little too soon to say how many are successful, I think.
If anybody wants to try, now is the time to email me because I want to set up a bit of
community.
I don't know if it's going to be, I don't know, matrix rooms, a Slack, mailing with
something to compare notes, share tools.
So now's the time.
Hi, thanks for the talk.
How do you see this interaction?
I imagine it being a little bit of a potential problem with open source projects that are
grown from or that already have companies crystallized around them.
So there's a bit of a tension there with this kind of freelance model that you're pitching.
So governance in open source is complicated and it's a people's job and I think every
maintainer is actually very expert in negotiation already because some of it is figuring out
diverging incentives.
I think this would probably be in contrast with open source projects that have a company
built around offering support contracts.
But that company probably already scales with the success of the project so it's not probably
suffering the same way I was describing.
If the users double, the potential support contracts double.
Support contracts have their own problems which is why I'm not going for that but maybe
I can start by cannibalizing a project that has already a scalable funding model.
Projects that instead have mostly companies that are footing the bill but are not reselling
support hours, they're not built around, we are the open source project X and you can
pay us for the open source project X.
I don't think this is actually in contrast.
Case in point, I don't think anybody at Google resents me for doing this.
Actually they are happy that now there's two maintainers on top of the headcount they
have maintaining go.
So far there's been no issue with that kind of company involvement.
Thank you for your inspiring talk.
Do you have any suggestions or advice for people who already went to the dark side and
actually don't have means to get back to the Raman level of money for a couple of years
to just get back to being a critical maintainer to start pitching projects?
I am sorry I did not catch that part, there was some noise.
Yeah, so if you are already at the dark side and you already cannot get back to the open
source Raman level of income to get back into the critical maintainer path because you
are not going to like it, your bank is your house and you are not going to like it.
So what do we do now?
We are already in a company somewhere, we are not doing the maintenance because we had
to get out of this pass a long time ago and we would like to get it back now.
Do we have any way to pitch it really?
I was saying that okay you know what, ten years ago I was maintaining this thing and
maybe you could hire me again though ten years I was not doing anything, it doesn't sound
like something convincing.
Okay so the question was if I understand it correctly how do you get back into the maintenance
track if you are doing other ways of doing software development as a professional?
Yes?
Okay, so I think that gets to the general question of what is the ramp up to what I am describing
because I just skipped, right?
I went like well great, five thousand people of my newsletter, here is a new thing and
great, that's not an on-ramp.
So the on-ramps will be part of what we need to figure out as this matures because I think
they can look like getting involved with a maintainer who is already doing this.
For example if I am already doing this with Go and somebody is skilling Go and something
that my clients specifically need I can hire them, they can start doing that through my
contracts so they don't need their own cash and then they can use that to maybe spin off
into their own thing which is really how firms work, how lawyers get started, how security
consultancies got started in the 90s and early olds.
If you look at that history you will see that they started as individual realities pretty
much like mine based on the popularity of the individual then they grew and then they
spun off pieces and then it became an industry and now you can just be a junior security
analyst, right?
I am hoping one on-ramp will be just starting as a junior maintainer on a team and then
spinning off and that I think is one on-ramp we should definitely figure out different
ones and ways to pre-invest so that you don't have to jump and say I will not make no money
for six months and then hopefully I will start making a little money.
We need to figure out ways to get investment up front for some projects and I think the
more companies get comfortable with this and with the fact that they want this because
they do.
The real thing that surprised me is that companies are often like yeah, yeah, okay, yeah, great.
We are uncomfortable about our open source supply chain so as companies get there hopefully
we will get to a place where you can get a pre-commitment letter which is often how
products on-ramp and then once you have three letters you go like okay I am ready to make
the jump.
If anyone needs a freelancer go maintainer for the deaf rooms I am available call me.
Thank you, Roy Lebrouz.