The Open Source Maintenance Fee with Rob Mensching

Open Source Maintainers are burning out or going commercial - how do we solve this? Carl and Richard chat with Rob Mensching about his work to create the open source maintenance fee through GitHub. Rob talks about the common problem of single maintainers getting buried under issues and demands of consumers for a project. Recognizing that most people cannot contribute to the project, a maintenance fee helps support the maintainer in a low friction way for everyone involved. Check out the links to get started!

Episode Transcript

Speaker 1 (00:01):
How'd you like to listen to dot net rocks with
no ads? Easy? Become a patron for just five dollars
a month. You get access to a private RSS feed
where all the shows have no ads. Twenty dollars a month,
we'll get you that and a special dot net Rocks
patron mug. Sign up now at Patreon dot dot NetRocks

(00:21):
dot com. Hey, welcome back to dot net rocks. I'm
Carl Franklin at Amateur Cable, and we're here doing the
thing with the stuff. You know what, we like it.
I think I might make a write a song called

(00:43):
the Thing with this Stuffing with the stuff. It's just
so so useful in everyday conversation because you know, it's
just what it says, is you know that whole context,
the thing we've been talking about lately. Yeah, that's what
I'm doing.

Speaker 2 (00:58):
The thing that's the thing with the stuff and the stuffy.
Definitely need them both. Yeah.

Speaker 1 (01:02):
Now, if you just walk down the stairs in the
morning and say you got to do the thing with
the stuff, now there's a problem because there's no context.

Speaker 2 (01:09):
But if we've been there yet, all right anyway, so
you put just fully in the bit, right fully how
are you man's puppy. You know, she's a chaos monkey.
She's head there and you but uh, you know it's
very good. Yeah, I'm not. You know, I'm not unhappy
to have a dog around. I didn't need to have
a dog around.

Speaker 1 (01:30):
Of course you're not.

Speaker 2 (01:31):
But most people will know that animals adore me, and
this one does too. So yeah, we all get along
just fine. We'll see, you know, with the grandchild coming up.
You know, we got a bit of a hurting dog here.
My goal is that this dog annoys the grandchild so
much because won't let her near the ocean. I want
this kid to say, Grandpa, Joe, Joe won't let me

(01:55):
get near the ocean, And I'll say, that'll do, dog,
that'll do. All right.

Speaker 1 (02:00):
Well, let's roll along right into better no frameworks awesome.
I know we're talking about open source today, but I
found a GitHub repo that is trending and it turns
out this is kind.

Speaker 2 (02:19):
Of a hub who uses get hub.

Speaker 1 (02:21):
Yeah, I know this is actually on GitHub marketplace, so
it's not really an OSS thing, but it is on
GitHub and it is trending. And I noticed this because
when I looked at the list like translation systems seem
to be very much in demand right now.

Speaker 2 (02:39):
Yeah, you know, especially with a on the new LLM
tools are just tokenization of language has led to better
translators without a doubt.

Speaker 1 (02:46):
Yeah, well this one is a little bit different. So
this is PO editor, and it does have a free version,
but then you got to pay for more use, right,
So it's a sort of a try before you buy
kind of thing. But here's here's what it is, and
I'm just reading. It's a PO editor is a highly
scalable translation management system and localization platform. So it's an

(03:10):
online collaboration environment for the entire localization team. But you
don't need a team. So here's how. There's a couple
of options of how you can use this. You can
assign translators to specific languages by adding them as contributors.
You can crowdsource translations from your community using public projects
because it integrates with GitHub. You can order professional human

(03:34):
translation services from one of their partners, or you can
use machine translation or any combination of those things. And
so it supports all sorts of different file formats.

Speaker 2 (03:46):
Which is what you need, right. You want all that
all that text, all that sourcing in centralized formats, so
it can be swapped out.

Speaker 1 (03:53):
Right or even in multiple formats. If you have a
dot net application, you have something that doesn't read Jason,
it needs to read Angular XMB files or something.

Speaker 2 (04:02):
You're making iOS and Android and you want to do
translation as well. Those are different file formats. Man.

Speaker 1 (04:07):
Yeah, yeah, that's right. It even supports any files. Oh boy,
how about that.

Speaker 2 (04:11):
I don't know. That is a good thing. But okay,
I don't know.

Speaker 1 (04:14):
I don't know, Rob, how do you feel about any files?

Speaker 3 (04:18):
I have a custom XMEL format that I remember we
did work when I was in office to make sure
it could ship over to Ireland where we did all
our translation and come back. So I hope that they
have access to or have the ability to support WXL
files because that's what we use for all our stuff.

Speaker 1 (04:34):
I don't let me look down the list. I don't
see WXL files.

Speaker 2 (04:38):
No, I don't see WXL. I means it.

Speaker 1 (04:41):
I see XML files, but I see XML, but it's XML.

Speaker 3 (04:44):
So most people be like, yeah, this parts translated, this parts,
and ID go.

Speaker 2 (04:48):
Yeah, nice.

Speaker 1 (04:48):
Well anyway, so that's where it is, and right on
there you get it for free. You can get three
thousand strings and then medium projects and premium and enterprise.
You can go all the way up to a couple
of files a year. So that's awesome. That's it. It's
just interesting. How you know these two, this one and
the one I showed last week, we're right at the

(05:10):
top of the list of trending GitHub projects.

Speaker 2 (05:14):
Interesting.

Speaker 1 (05:15):
So well, that's what I got. Richard, who's talking to
us today.

Speaker 2 (05:19):
I'm going into the wayback machine here and grabbing.

Speaker 3 (05:22):
Yeah.

Speaker 2 (05:23):
Rob's first show, the one we did back in March
at twenty twelve, episode seven four seven, so only twelve
hundred episodes ago or so. Wow, talking about the Wicks
tool Set, which had a ton of comments on it,
really like sixteen eighteen something like that. Yeah, and one
of them is from Timothy Klink in a mid at
least from thirteen years ago.

Speaker 1 (05:44):
Oh wait a minute. We should differentiate between WIS the
popular web development environment. I know Rob is shaking his
head like, oh my god, these guys ruined my life.

Speaker 2 (05:54):
Yeah, who stole your name? Man?

Speaker 1 (05:56):
And but WIS that Rob did is a set of
tools for building Windows installation packages.

Speaker 3 (06:01):
The Wix tool Set is what we call it to
avoid all the legal problems there, right, Yeah, may or
may not exist that we have never investigated. No never, never,
help don't want to under We call it the Wicks toolset,
and then you could call it Wix and all the
lawyers at Microsoft HILP come toool it that way back when.

Speaker 1 (06:15):
Yeah, there you go, all right, so sorry to interrupt.

Speaker 2 (06:18):
So that's all that problem. So, yeah, it was an installer.
And this is what exactly where Tim clinkwaed where you
said this is a great show. I was doing a
lot of nodding during the discussion. And how still today
many people dismiss how critically important a good installation package is.
It's all about the first impressions. The user's first impression
of your app does not begin when they double click
the desktop short top of the first time begins when

(06:38):
they double click set up XM. I was reminded of
his story a long time ago about an applicant to
Harvard Paper clipping a dollar bill to their application along
with a short note. The note requests of the reviewer
go get a donut, take a break, relax, and get
into their happy place before they read the application.

Speaker 1 (06:56):
That's great.

Speaker 2 (06:57):
A good installation package is like this. It's a dope.
It we'll set the user's mood to frustrated or happy
place prior to them clicking on your applications debtstop icon
for the first time. Legit absolutely and that's an old comment,
too right. It's an old comment. It is so right.
It's still writes today by a mile. It's still true, Tiffyth.

(07:18):
Thank you so much for your comment. In a copy
of music, Coby. It's on its way to you. And
if you'd like a copy of music go buy. I
write a comment on the website at dot at rocks
dot com or on the facebooks. We publish every show there,
and if I comment there and every reading on the show,
we'll send you copy music to go buy.

Speaker 1 (07:30):
And you can get music to Koby music to code
by dot net and that is a u r L
DNS entry, so don't put hgdps in front of it.
And that brings you to another place where you can
listen to a sample and get track twenty two or
the entire collection rob before we get started here. When
Richard was reading that, I was reminded of Mark Miller's

(07:55):
new invention that he unleashed unveiled on Mondays, which was
called the install Buddy and so the install buddy, when
you're running an installer, it's in the background and it's
just clicking next, next, next, next, next, next, next, next, finish.

Speaker 2 (08:11):
That's awesome.

Speaker 3 (08:12):
That's awesome. So I have a rebuttle to that if
you care.

Speaker 1 (08:17):
But yeah, sure, why not.

Speaker 3 (08:20):
I appreciate the sentiment one hundred percent, And we actually
talk to our customers a lot about minimizing the amount
of input that you have to put in install Again,
first impression, let's get to the product. That's where they
want to be. They want to get past your progress
bar and to the end. So to that point, I
one hundred percent agree. Fortunately, the industry has definitely been
moving that direction. Like app installer now is just one button.

(08:44):
But at the same time, a lot of customers that
I work with are large organizations with very large and
complex software, and you're not going to next, next, next
your way through it. There is complex information you have
to provide up front in order to configure it. So
there are different worlds, and we see all kinds in
the insulation space because we see all software in the
slation space, which makes it interesting for me. So yes,

(09:07):
I totally get it next, next, next, except when you
have some really heavy software.

Speaker 1 (09:11):
Well it was. It was a joke, so it was funny,
a funny joke, but it did hit all right, So
let me introduce Rob.

Speaker 2 (09:17):
Did you want to do nineteen forty eight?

Speaker 1 (09:19):
Yes, I do want to do nineteen forty eight before
I introduced Rob officially. Okay, because this is episode nineteen
forty eight. We have been doing this lately. We go
back in history and see, you know, try to summarize
what happened.

Speaker 2 (09:30):
Pretty much till we once we got in the nineteen hundred's,
the history part came more. Yeah. Yeah.

Speaker 1 (09:36):
So nineteen forty eight was a pivotal year several major events,
including the assassination of Mahatma Gandhi, the declaration of independence
for the State of Israel, and the start of the
Arab Israeli War. It also saw the beginning of the
Berlin Airlift, the US establishing the Marshall planted as I

(09:56):
said last week, to aid post war Europe and the
United States. It's recognizing the state of Israel, which was
it happened at the same you know, in the same year.
Also in the United States, President Truman signed executive Order
in nine to nine to eight one ending racial segregation
in the United States Armed Forces. Do you have anything
to add, Richard.

Speaker 2 (10:18):
The land Camera, the Polaroids and Camera nineteen forty eight,
No kidding. Yeah. For Canadians, the Davelin Beaver, the DHC two.
This is a prop plane float typically float planes, the
ultimate bush plane and I flew on one like a
month ago. It's called the Beaver. Yeah. Wow. Of course
in the dash too. Uh and it's like it's a legend,

(10:41):
just an unbelievable machine. Wow. Only made for until in
nineteen sixties, still flying today. And finally, because it is
a tech show, so let's talk about the men Chester Baby,
which was one of the very they arguably the very
first electronic quote stored program computers coming out of World
War Too. There was a lot of computers being built,

(11:02):
but this was a computer that could actually store a
program within it and execute that program. It added thirty
two words of memory of thirty two bits each for
a total of one twenty four bits.

Speaker 1 (11:14):
Wow.

Speaker 2 (11:15):
Good Lord, and the Baby was the test bed for
the Mark one, which eventually became what they called the
Manchester Ferrante, which was the first commercially available stored program
computer in the world.

Speaker 1 (11:25):
Also the first Canadian land cruiser was called the Moose
Nice and the first Canadian boat was called the Otter
and then the sister submersal submersible. Anyway, I kid, you're
making this stuff all right, So let's now let me
finally introduce Rob Officially. Rob MenShing is the CEO and

(11:46):
co founder of fire Giant, a company that provides commercial
support in tools for the Wicks tool set. He's also
the creator and maintainer of Wicks. Of course, we talked
about the most powerful set of tools for running building
Windows installation packages. The Wicks tool set holds the unique
distinction of being the first open source project released by Microsoft,

(12:07):
and Rob has been deeply involved in open source over
twenty five years. He's passionate about making open source sustainable
and his latest proposal, the open Source Maintenance Fee, is
all about creating a better path toward. It is all
about creating a better path forward for projects and their maintainers.

(12:29):
This ought to be really good, Rob, welcome back.

Speaker 3 (12:32):
Thank you. I'm looking forward to talking to you guys.
It's I didn't realize that twenty twelve that was that
was easy for show. You had some after that, but yeah,
twenty twelve of you were still a Blue badge.

Speaker 2 (12:43):
That's how long ago that was.

Speaker 3 (12:45):
Just barely that's right. I started fire Giant twenty thirteen.

Speaker 2 (12:49):
Wow, yes, there you go. So it's like it's been
twelve years in fire Giant. But yeah, it's a way back, yeah,
way back moment.

Speaker 3 (12:56):
As long as that's kind of throws me off. I
think I've been fire Giant as long as I've been
at Microsoft, as I was at.

Speaker 2 (13:03):
Microsoft, as long as your Microsoft n Yeah, and he
still feels like it's your new thing.

Speaker 3 (13:07):
Yeah, it feels like a startup. It feels like I've
been doing this for about three years. But when I
look back, we've done more than three years of work,
and I just can't reconcile the two together. So when
you say it's been twelve years, I have to and
go really, I guess, man, we have so much more
to do.

Speaker 2 (13:24):
Yeah, it's not like I'm getting the bottom eye to
do list. That's not a thing.

Speaker 1 (13:28):
So when did you go solo again? Thirty thirteen twenty.

Speaker 3 (13:32):
Right at the beginning. I retired from Microsoft in twenty
twelve and started fire Giant. Fire Giant officially launched in June,
But you know, takes six months to put everything together,
but we had the idea, you know, to begin to
my thirteen I was working towards that.

Speaker 1 (13:47):
Yeah, well, when immediately came to mind when I read
your bio. There in the things that you're talking about
for open source, making it sustainable and better, you know,
better prospects for owners of OSS projects. Is that we
is that show that we did at NDC in twenty
twenty two with David Whitney. I was in November twenty

(14:08):
twenty two making open Source Work for Everyone with David Whitney,
and I remember we got into this really cool what
if discussion about what if you know, places like GitHub
would have some sort of pay mechanism built in, so
like write in Visual Studio, you could say, hey, this

(14:29):
is open source, but they would really appreciate your donations
or something like that. Just make it low friction for
people to donate to open source projects. You're nodding your head.

Speaker 3 (14:39):
Yeah, there have been ideas in this space for a
long time, and lots of different ideas floating around this space,
which is fantastic because I don't think we're going to
end up with one solution to what do we do
with open source to make it viable for everybody to
continue working in it. So I do believe there are
many different options that we need to consider because there

(15:01):
are many different kinds of projects. And the idea of
having some way to pay maintainers in GitHub was very
present because now they have sponsors, which turned into very
much that even if it's not deeply in a Grandville studio,
it is exactly in that space. So yeah, there's been
lots of thinking and talking about this, and I decided

(15:24):
I had to formalize some of it. So that's why
I want to talk to you today about.

Speaker 1 (15:28):
So let's get to it. What are your ideas?

Speaker 3 (15:31):
Do you want the history? Do you want the idea first?

Speaker 2 (15:34):
That tweet thread is really important, Okay, because it's an
encapsulation of so many projects I've seen.

Speaker 3 (15:41):
Yeah, so maintainers. When you're a maintainer of a successful
project for a long term, the world changes a little bit,
the changes for you a little bit. And I have
this theory that I've been developing of there are these
mega projects that people know about, that's the ones they
think of. They usually have corporates running them, and they

(16:04):
have a different way of operating. You have the hobby projects,
I don't have like that term acoungement, but you know,
startup projects, they're just getting off the ground and the
people are still very enthusiastic about what they are, what
they could be, the future is everything ahead of them, right,
and they're just trying to find more users. And that
place is awesome. Then you hit the what I call
the working class projects, where you've usually graduated from being

(16:26):
a hobby project and you've now ended up in a
space where people depend on you, and you take that
responsibility seriously that you have an important piece of the ecosystem.
It's the what is that the Ohio project? You are
that tiny little cog standing up the whole system on
top of you from SKCD, Yeah, you are that little
block and you take it seriously, like this is my project.

(16:50):
And I've been running the Wicks tool set for twenty
plus years longer if you count the stuff I did
in Microsoft, but twenty plus years. And after a while
you kind of get to a place where not everybody's
treating the project particularly well or you particularly well. And
for the last few years I've been very frustrated with

(17:13):
what's been going on around the project. And then the
EXZ UTLS issue hit at the March last year. I
think it was fourth that issue. I saw all these
people talking about the attack vector that almost turned into
a back door on Linux that got into cloud servers
and every Linux like it was crazy, and I knew

(17:36):
people are going to do the analysis of what it
was and how it worked, because that's like the geeky
technical stuff. But for me, I saw the story behind it.

Speaker 2 (17:45):
We better recap what happened last year because not everybody's yeah,
good idea. All right.

Speaker 3 (17:50):
So someone found a way to use and xx udles,
which is this like compression library and tool that was
included in I think every major Linux distribution, and a
we believe an attacker. Now at this point, someone very
dedicated found a way to use the build system to
inject code that did not appear until inside the Linux

(18:14):
build or something in that effect, so that they could
insert a back door into the Linux build system that
they could then connect back in and it would end
up on all Linux machines. And it happened to be
found by a dev working on performance some performance issue
was like Microsoft and Azure and said hey, wait this
is acting a little slow and found the problem.

Speaker 2 (18:35):
It was like a half a second or something, right, Yeah,
it was minuscule.

Speaker 3 (18:39):
It was talked about narrow, narrow, narrow by the slimmest
margins that someone found that that could have been catastrophic,
and then nobody might have even noticed once it's out there,
it could have just been an invisible back door.

Speaker 2 (18:53):
Well, they also bags the question how many we not noticed? Right?

Speaker 3 (18:56):
Yeah it was. It was a very very sophisticated attack,
so obviously fascinating to every developer out there, like, wow,
how did this work? How did you get in there?
How do you slip yourself into s sh or all
the And I'll be honest, I didn't dig into those
details because the part that I saw was the a

(19:16):
thread and someone pointed out a thread, the email thread
archived on you know, set of way pages of their
their their mailing list, and I started at the top
and I found the maintainer of the project talking to
the people that are then believed to have put in
this attack. And in it you have people pushing on
this maintainer saying you're not doing enough for the project.

(19:39):
Why haven't you submitted all these prs, why haven't you
fixed all these bugs? And you can hear the maintainer saying, oh, yeah,
I'm going to get to that. It's just it's been
really hard and I've just been a lot of pressure.
And you can hear like there's other things in their
life going on, right and and he says, oh, and
there's someone that's been helping me on the side. You know,
that's been really helpful. But you know, it's it's really
hard finding people to take over a project or helping

(20:01):
a project. And then you have repeated cases that if people, well,
you should give up on your project because clearly you're
not going to take care of it, and someone else saying, oh,
we understand, it's really hard to maintain your project. You know,
you could be really busy, but you really should do
something because your project will suffer because you're not doing this.
And at the end, the guy's like, well, you know,
this other person's been really helpful, and you know we'll

(20:23):
probably have them helping more. It turns out that that person,
that named person is the person that's tracked back to
it's the attack or inserting the attack vector into make
files and the data files and everything else.

Speaker 1 (20:35):
And they made themselves look like, you know, they were
going to help out like they.

Speaker 2 (20:41):
Well, they be clear. They they had been more helping out,
They had been making contributions, like one person had been helping.

Speaker 1 (20:47):
Right, it's what I'm saying. But all the way along
the goal must have been to at once they gain
their trust to launch this attack, and nobody would ever
suspect them.

Speaker 3 (20:57):
Right, So one person was helping, and then two other
people showed up in this particular thread, and the timing
spread out. It's not like immediately back in back and forth.
It's like a week spread out, two weeks here. I mean,
it's not obvious. And when I originally saw this thread
and I wrote down a tweet about this, that I realized, oh,
and it was like, I don't know, thirty tweets and
I was like, oh, I hate it when people write

(21:18):
tweet thread. So I ran and put in my blog
so you can read it all one big pass much
as you read, and I had more contexts. At that time,
there were theories that this could be a truly coordinated attack,
with multiple people operating what we call sock puppets pretend
to people pretending to be different. I don't characters in
a play trying to manipulate what they wanted I thought

(21:41):
that felt a little far fetched at the time, because
it felt very real. Everything that was being discussed and
treated and the way that people were acting was very
common for what you get on maintainers. You get sets
of people just showing up going why haven't you fed
me yet? I want my fix? Where's my build? I
can't believe you haven't fixed this in ten years. I

(22:03):
just got that comment this morning from somebody. I can't
believe you haven't fixed this in ten years.

Speaker 2 (22:09):
And that's when you offer them the refund of everything
they've paid.

Speaker 3 (22:12):
I actually offered to assign them the issue, which is
my new tactic. In the end, I ended up really mad,
like just stomping mad. And I've been low key mad
for quite a while having seen other maintainers treated the
same way, feeling it myself. And I'm fortunate that I
have Bob who works who's a co maintainer on the

(22:33):
WHIS tool set with me, so I have someone I
can talk to and kind of, you know, walk off
that ledge. No, sorry, step away from the ledge from
the ledge. Yeah, just like this is this is too much?

Speaker 2 (22:45):
You're really a friend, you'll jump off with me? No, No,
that's not the goal here.

Speaker 3 (22:48):
Well, and when you're in a project that is popular
and successful and you have lots of users, you will
hit this space where you went up with a non
trivial number of people showing up making demands of the
project without any thoughts of any contributions. And so the

(23:13):
xc udels that event and then finding out that it
was very possibly Nation State actors. Nobody knows for sure,
but that level of coordination made me just go that
that's it. I'm going to do something. I don't know
what I'm going to do. But at April last year,
you know, about a year ago now, I said, I'm

(23:34):
going to find something and I'm not doing it like
this anymore. We're not just going to have maintainers out
here unprotected from every you know, everything. We need to
change the culture and the way that we treat maintainers.
And so I sat for months just I couldn't put
it down. I had job to do. This is not
my job. But I had this thought process in the

(23:54):
back of my head, going what can we do that
builds a system that works well for maintainers, that is
fair to everybody involved, and can scale. And it was
all based off this tweet of mine that got a
million in some views, which I don't write tweets like that.
I'm not a mean person, right, I write tweets communicate
Moory project, my company and what I do. That thing

(24:16):
went crazy and everybody in the thread agreed that it
was a problem. I have never seen so many people
agree on Twitter.

Speaker 2 (24:24):
The Internet. You're not supposed to get along, that's not
how Ever.

Speaker 3 (24:27):
The only discussion that went sideways where people were disagreeing
was whether we should have universal basic income. And I
was like, Okay, I'm not touching that. You guys, go
have fun on that conversation. That's a bit far. Yeah,
a bit far, And it just was like a side
thread on the whole thing. But everybody agreed.

Speaker 2 (24:44):
So yeah.

Speaker 3 (24:44):
I went from there and my experience with frustration of
where I was at as a maintainer, because like a
year before that, I remember one morning I woke up
and you know, dealt so with me and I just
get my wife said that's it. I'm done. I'm not
going to do this anymore. Like why am I Why
do I even do this? Why am I putting myself
through this? I have a company built on this open
source project. I'll just do it a different way. And

(25:08):
I'm the guy that worked for years inside Microsoft to
make open source happen. So I was like, I'm walking
I my mind was torn. It was I was I
was broken. It was pretty bad in this space. So
to hear other maintainers having these same problems and pains,
I reached out to a number of them. And every
maintainer that has a project that you think of successful,

(25:31):
that you thought was successful, if you know it by
name and you know that maintainer, they are in either
one of two camps. One they don't care about what
happens to the project and they're just distracted from it.
DHH has this famous slide where he's just like, f you, Like,
that's the way he approaches his project. He doesn't care
about you. That's a fine way to go. I know

(25:54):
no maintainer, I personally know no maintainers that operate that
way because they care too much about their project and
being how it work well. All the ones I talked
to all have were like, yep, I totally agree. I've
all thought about quitting every single one of them, all
of the major projects, all of them are all in
the same spot.

Speaker 2 (26:10):
So now you wake up in the morning up, you know,
immediately anxious about I haven't dealt with I haven't got
to like you're dreading going to your office.

Speaker 3 (26:19):
Yeah, And so that was the reality. That's where it's at.

Speaker 2 (26:23):
End.

Speaker 3 (26:23):
I decided I was going to have to create a solution. So,
like I said before, I think there will be many
solutions for many different sized projects, for different kind of
types of projects. I know, my project, it's about half
a million lines of code. There's two of us that
work on it. Often there's only one person that works
on it. And we have you know, millions of downloads,

(26:45):
tens of millions of downloads, ten million downloads, twelve million downs.
Now it's a big project, all that kind of good stuff.
And I said, all right, in this space, what can
I do? And so I sat down for a while
and started going, what if we charge a fee for
people to use the project? And from there I started

(27:06):
putting it together. So should I go jump into the
details of the maintenance.

Speaker 2 (27:09):
Fe then yeah, let's go all right, yeah, let's do it.

Speaker 3 (27:11):
So the maintenance feek idea came as I slowly started
teasing apart the problem and I realized that there's open
source software and that has a license on it that
we all know and love. All of our various license
out there, whether you're like MIT or GPL or my
favorite MSRL, whatever license, we know all of that. And

(27:32):
what I got to was that license applies to the
source code. And if we say that that license will
only apply to the source code and stop there, that's
an open source project. Like that's enough to say that
your software is open source. Right. You don't have to
build the source code for people. You don't have to
have an issue tracker, You don't have to take changes

(27:54):
from other people and apply them to your open source software.
Your open source software is open source. Are done?

Speaker 2 (28:00):
Yeah?

Speaker 3 (28:00):
You you have successfully created an open source project. So
all that other stuff that is generally expected of maintainers.
Build a binary that other people can use. Answer the
discussions that people have, keep a discussion list where people
can ask questions, have an issue tracker, deal with them.
Some people expect you to fix all of them. Do

(28:22):
regular builds, stay up to date with all of the
dependencies that you have, as those keep changing. Dot A
framework I'm looking at you. You know, security vulnerabilities that
pop up, you know all of the you know, spam
shows up. Yeah, go make sure that doesn't show up. Oh,
you have to have signing certificates for your binaries, we'll
keep those up to date, so on and so forth.
So there's all this other stuff that's actually that's the project,

(28:45):
that's the work that the maintainers do regularly, outside of
maybe choosing to write some lines of code as a contributor. Right,
So if we separate those two concepts and we say,
I'm going to make the open source software open source
by this license, but the rest of this stuff that
I have to do to maintain the project to make

(29:07):
it viable as most people expect it to be. What
if I have a fee? And in that tweet thread
that we were talking about, I kept throwing out the
idea of what if you paid ten bucks per month
for a project? Nobody ever said peepe. They're like, yeah,
that seems fine, right, maintainers ten bucks a month, no problem.

(29:28):
So I said, all right, we're going to create the
maintenance fee and for all of the stuff that isn't
the source code itself. You want the bills, you want
issue tracker and discussion lists, and you want signing certificates
and all that stuff maintained. You pay ten bucks a
month if you make money. So if you're a student,
if you don't make money, if you don't want to

(29:49):
play in the money game, no problem, you're in. Hang out.
Let's go right, we're talking source code, we're talking open source.
But if you're making money, if you're a compan or
your employee at a company using a project, you're in
a different world. You're using this and you are getting
some value out of it. So you get to.

Speaker 1 (30:08):
Pay, and you're taking a dependency on it a.

Speaker 3 (30:10):
Fee, right, right, And you depend on it and you
want to presumably want it to be there, so you
pay the fee. Really simple. And then I stacked it
and I said, all right, we have dependencies an open
source project. So if an open source project says I'm
going to start charging a fee for all of the
stuff that isn't the software, than any dependency that you have,
you pay their fee too. Okay, Right, So if I

(30:32):
have a dependency us on some other project, then I
pay them. My project takes a fee, then I pay
them however many fees they have.

Speaker 1 (30:39):
So you basically now are in a money distribution royalty
kind of right system.

Speaker 3 (30:46):
Right, You you taking a fee in your project means
you now have decided to take money, So now you
play as money. If your project doesn't take money, then
you don't have to pay money. At the idea of
being like, look, if you're not making money, you're not
paying people, right, You're not trying to bankrupt people or
anything like that. We're trying to get to a place
where maintainers now can get paid for the work that
they have to do to keep the software going and

(31:07):
viable in an environment where people expect it to be.

Speaker 2 (31:10):
Any you're driving this through GitHub.

Speaker 3 (31:12):
Yeah. What I realized was that with the system, I
ended up with about the tightest feedback loop that I
could create. Consumers pay a maintenance fee for the maintainers
to maintain the project. The maintainers maintain the project, so
that the consumers continue to pay the fee, so that
the consumers pay the fee to maintain the projects, and
the maintainers continue to part and you end up with

(31:34):
this tiny little loop cycle. Nobody else involved. There's nothing
else out there, because so many other proposal I'd seen
required somebody out there to do something to make this possible.
Usually some company is going to come down on high
and say I have now created a system by which

(31:55):
you will get paid, and the maintainers could be like, oh,
thank you, finally good assuming payment what they want. But
you know, a solution from outside here. Maintainer just says
I require a fee and it all works. It's just
between you and the consumer on that fee. You're good
to go.

Speaker 2 (32:10):
All right?

Speaker 1 (32:10):
And I have so many questions, but we got to
take a little break here, so we'll be right back
after these very important messages. Stay tuned. Did you know
that you can work with AWS directly from your ID?
AWS provides toolkits for visual studio, visual studio, code, and
jet brains rider. Learn more at AWS dot Amazon dot com,

(32:31):
slash net slash tools. And we're back. It's dot net rox.
I'm Carl Franklin and that's my friend Richard Campbell and
our friend Rob Menching, and we're talking about making open
source sustainable. I have so many questions, but the first
question I have is do you just work on the

(32:51):
honor system? Do you just say, how do you prove
that you're not making money? How do you prove that
you are? How do you do you go after for
people if they start using it and making money without
it without paying?

Speaker 3 (33:04):
This is this is a fantastic question. And I sat
here for a long time going how do we do enforcement?
And every maintainer as I presented this idea to them
always kind of got to this point, like I really
love this idea. I never thought of it that way.
How do you make it happen?

Speaker 2 (33:19):
Right?

Speaker 3 (33:19):
So, in the new gut world, we produce nugat package. Sorry,
in the dot net world mostly about nugat packages. That's
how a lot of things are attributed. Even my own
system is now msbilled, SDKs and dot net tools and
a whole bunch of NEWGAT packages. So we're all in
on nugat. I kind of sat and got all right,
So what do I want? I want to declare a

(33:40):
I have a license, an open source license that applies
to source code. I need a YULA, an end user
license agreement to apply to the binaries and the rest
of the project. Okay, oh, I can have a license
for this source code. I can write AYULA that does
not impinge on your rights that the license gives you.
I can put that ULA in the nugat package, and

(34:03):
then lo and behold. Nugat has a way to say
require acceptance when you accept a Nugat package. So you
have to say I accept the terms of the ULA
AKAI will pay the maintenance fee because I am making money,
and you have to check that box. And now you
have legally said that you are complying with the maintenance

(34:26):
fee for any project that you want.

Speaker 1 (34:27):
And that amounts to Diddley Squad, however, because we've all
agreed to ULA's because otherwise we can't use the software.

Speaker 3 (34:33):
Yeah.

Speaker 1 (34:33):
Yeah, So nobody's ever knocked on my door and said, hey,
did you read that ULA?

Speaker 3 (34:38):
Yeah. But if you remember, lawyers had a huge, huge
challenge when they first started trying to pick up open source,
and they held up everything saying no, no, no, we
can't pull source code into the company that open source
license until we understand what those licenses will do to
us and our company. The maintenance fee puts a legal
document in there that if a lawyer sees it and

(35:00):
you've accepted it, you're on the hook for it. I
believe it's written correctly. I've had another lawyer write it.
You're now on the hook. So any lawyer that saw
it inside the company be like, we're on the hook
for this.

Speaker 2 (35:12):
Yeah, okay.

Speaker 3 (35:12):
And this is actually important because there are many maintainers
out there that I've come out and said, oh, you know,
I would I would pay I you know, get how
sponsors is great. I would pay it, and my company,
you know, should pay it. But you know, the procurement team,
I just they they won't do anything. They're so hard
to get work through, and I believe them. Procurement teams
are very challenging with my own company. You know, we

(35:34):
can spend six months with the company and their procurement
team just trying to get them to pay us for
the legal agreement they already signed up for and the
services they're paying for. It's a challenge, I get it.
So let's create a system by which the curement team
has to pay it because the legal team will show
up and say, hey, you know this open source thing,
we already went through our time and figured out how
to deal with open source. Now you, as a procurement team,

(35:55):
you now need to figure out how to deal with
open source projects that require this maintenance because you have
to pay them because the license says that you have to.

Speaker 1 (36:03):
And for big businesses with lawyers, I think that's probably
a valid thing. What about all the small businesses.

Speaker 2 (36:10):
But that's that's who we want to pay.

Speaker 1 (36:12):
But what about a small business that's making a million
dollars a year and it's Joe and his wife and
they don't have lawyers. You know, maybe they do, but
they're going to take the chance. How are you going
to enforce? How are you going to enforce it?

Speaker 3 (36:23):
So I've been slow walking the enforcement past the legal
requirements that will hopefully build the structure that everything else
stands on. Okay, I've had people ask, hey, what do
you do with the issues in the Wicks tool set.
We've called out that you check a box if you're
using money and you go through our templates, it says

(36:44):
you're using this for monetary value. Check the box it
says you are sponsoring the project. So we're getting the
education and awareness out there.

Speaker 2 (36:52):
Now.

Speaker 3 (36:54):
There are some projects that I saw that lock their
issue tracker unless you sponsor.

Speaker 2 (37:01):
So you can't submit an issue.

Speaker 3 (37:03):
Enter that, you can't submit the issues, you can't get
the issues unless you sponsor the projects. That's doable through
GitHub sponsors. Straight up, that's.

Speaker 1 (37:11):
Only if you're making money, right What about the student who.

Speaker 3 (37:15):
Isn't Again, So that's the challenge of the enforcement on
that front for people that aren't making money. We have
to find a place in there. After I made this announcement,
the GitHub sponsors lead reached out to me and we
had some conversations about what could be done. So there,
what I'm saying is right now, we're in the beginning,
and I want to start the enforcement by assuming that

(37:38):
the developers that said I want to be able to
help you and maintain your project, but I can't get
through procurement now have the tool they need to go
to their legal team and say, I now need to
pay this project because it has a legal requirement. Please
help me solve this issue with the procurement team.

Speaker 2 (37:57):
And people have told me, but also coming to them
with the documents to say here's how it solved exactly.

Speaker 3 (38:04):
Yeah, it's not. Before it was like, you know, let's
say as an individual contributed company and you're using this
project that you want to support it, and you're like, yes,
I want to help them, and you go to your
boss and your boss says, no, dude, too much work.
Let's not bother. Just just go do it and be done.
Now you're able to go to the boss and boss say, hey, boss,
there's now this legal requirement. We have to do this.

(38:26):
Boss will be like, well, if we're going to continue
this project, we have to go do with legal, we
have to go do with procurement. They now have that tool,
will they maybe say, you know what, forget it. Let's
just go use a different project that's free, that doesn't
have this open source maintenance fee. Absolutely, that may absolutely happen.

Speaker 1 (38:41):
So I have ideas. I have some ideas, which always
happens when I have these great conversations with guys like you.
But one idea is to have a sort of an
outside agency that does enforcement. And I don't because I think,
you know, software developers, they don't want to be in
that position. You know, nobody wants to be the bad

(39:03):
guy and have to on top of having to write
good code. Now you got to wake up every morning
and wonder who's not paying me that needs to be
paying me. So an outside agency is not like a
union or something, but just somebody that works on behalf
of contributors to enforce this. The other thing that I
was thinking of was is gone from my head. It's

(39:24):
just gone.

Speaker 3 (39:25):
These ideas are great. I want the ideas, and honestly,
if someone comes up with an idea and is inspired
by the open Source Maintenance Fee and says, ah, this
is a good idea, but it is fatally flawed this way.
But I can create a system that works better. I
hope that happens. Or people say, hey, here are different
ways that you can do enforcement with the structure that

(39:47):
the open Source Maintenance fee happens, I'm going to write
them down. I have a discussion list on the open
Source Maintenance Fee dot org. It says, hey, if you
have more facts that your more ideas, you want to add,
more questions that need to be answered, let's put them
up there. There is a place to have the conversation
to say, here's what we need to do. And I
want to be really clear. The Wix tool set is

(40:09):
the first project to apply the open Source Maintenance Fee,
and we did so on the seventh, so a week
ago today.

Speaker 2 (40:15):
The seventh of April, of April of.

Speaker 3 (40:18):
Twenty twenty five, the seventh of April twenty twenty five,
so a week ago today. That has put all the
pieces in place, and I've been then using that experience
to update the step by step list for maintainers on
the open Source Maintenance Fee dot org site. So if
you want to go through it. It just lays out
all the five or seventh steps you have to do
to work your way through.

Speaker 1 (40:38):
It's really cool, right, so I found I remembered the
second idea. Okay, the second idea was to require by
law companies to publish as software bill of materials. So
on every website in there about page or whatever, there
should be a link to a s bomb page and
then every dependency that they've taken must be listed there.
And that way would it be easier for an auditor,

(40:59):
even if the auditor was GitHub?

Speaker 2 (41:02):
Right yep, you know.

Speaker 1 (41:03):
GitHub seems like the logical place where this kind of
thing would happen for getthub repost. But maybe in another place.
I don't know.

Speaker 3 (41:09):
I actually had someone ask me if we would try
to get an SPDX identifier for the OSMF.

Speaker 2 (41:16):
So.

Speaker 3 (41:17):
SPDX is the software what identity system They have a
way of saying s bombs. Basically, they're one of the
standards for specifying s bombs and one of the big
features they've provided are the standard list for all the
various open source licenses out there.

Speaker 1 (41:34):
Because it's advantageous for every software company to have an
s bomb, right Yes, it's absolutely advantageous to them. Yes,
because of security problems, right, and so you know when
there's a problem, oh, we're using.

Speaker 3 (41:47):
That, right. And if the maintenance fee was in SPDX,
then you would just use the identifier and then you'd know, hey,
they're already doing this, and they would they'd all roll
down the direction that you're saying. Now. Yeah, there's only
one project using the open source maintenance fee right now,
and we are slowly working our way through the experience
of what does it mean to do so? And enforcement

(42:09):
is an area where I'm trying to be extremely respectful
to the challenges that I know individual developers will have
inside their companies. I worked in Microsoft, I know big
company challenges. I spent a lot of time with lawyers
when I was first trying to get the WISK tools
set released as an open source I think part of

(42:29):
that training helped me design the open source maintenance fee
is learn how to use lawyers to help you get
a problem solved. Where we go through enforcement is a question.
I think getting the first foundation and then normalizing the
idea that maintainers should be paid to maintain the projects,

(42:50):
and that if you don't want to use the project,
and you don't want to pay a maintainer money for
them maintaining the project, then you can go take the
source code because it's still available, it's still a source.
You can go take the source code and maintain it yourself,
which is the alternative.

Speaker 1 (43:07):
You know, in the interest of security. This is the
same reason that that bill got pass that requires everybody
to allow cookies, yes or no. Right that is required
by law right in GDPR. Yeah, the GDPR. And so
just like that the way that got passed, this could
be you know, you you must have an s bomb

(43:28):
and you must be able to well.

Speaker 2 (43:29):
I would point out that that is not enforced. No
one has ever been charged for not doing that. Yeah, so,
and yet lots of people have done it. Like enforcement
is a separate issue here, yea, And I would argue
long before you get to anywhere near that, you can
have nudges from within GitHub. Like the main thing we're

(43:50):
hoping for is a get hub. Here is poke at
obvious large organizations that are utilizing these resources to write, Hey,
you know you should be making a contry.

Speaker 3 (44:00):
Here is the path and to basically put a system
in place that starts allowing people to do the right thing.

Speaker 2 (44:07):
Yeah, make it reduced to friction doing the right thing.

Speaker 3 (44:10):
He says, Look, you have to do this. So now
the people that want to do the right thing are
now empowered to go take care of the larger systems
that naturally would not change or continue to run the
way they do. And we will continue to have large
companies with their procurement systems which are designed not to
spend money to you know, not spend money on maintainers

(44:33):
for these projects. I mean. One of the interesting comments
I got very recently was someone left a comment saying, hey,
I will need some extra verification of to give you money.
I will need some extra verification to know that you're
not a terrorist organization, right right, because my procurement team
can't fund terrorist organizations. And I was like, sure, whatever

(44:53):
you need, let me know, we'll answer those questions. But
then I stopped and said, it is harder for the
the procurement team. The procurement team has higher standards than
the developers do for taking the code, like you already
took the code the binary code usually and are using it,
and I don't remember a background check or anything like
that to take the bus. I heard terror because I

(45:17):
use my code. What we have done is create some
artificially high bar on the procurement and the sustaining the
project if projects want to be sustained by money, and
the way that you can take the code into the
sources world. And we've also created a culture where I
just take it and I don't have to do anything
else after that.

Speaker 2 (45:36):
Well, and there's an advantage to that too, because you
want to take it out for a spin. You want
to prove that it's valuable to the organization, Like you
need to get to a place before you even have
the conversation about you know, do I want to spend
money on this or not? I mean, I do appreciate
and I've included the link to how wix tool sets
maintenance fee is set up where it's based on the

(45:56):
size of the organization with the size of the contribution.
Is because this now roll the other way where a
CFO should be able to go to gethub and say, hey,
what libraries is my company using? What is the total
fee I should be paying. My experience with CFOs is
they'll kind of check once a year, but don't make

(46:17):
it more complicated than that.

Speaker 3 (46:19):
And so we fell upon I fell upon GitHub sponsors
because it was very straightforward for a lot of maintainers
to be able to access that directly without having to
do a whole lot of extra work. And also because
gethub sponsors has may have relationships has larritionships a lot
of companies through their enterprise system, and through that enterprise system,

(46:40):
you can say pay for sponsorships by invoice. It doesn't
have to be a credit card. So you can walk up
with an invoice to get Hub and say here, I
want you know, give me. I think the minimum invoice
is like five thousand dollars. It's a pretty large number.
But you can pay an invoice in bulk and know
I will pay my maintenance fees, you know, in bulk
for this amount of time for all projects.

Speaker 2 (47:01):
Yeah, so GitHub will disperse it.

Speaker 3 (47:03):
There's a process.

Speaker 2 (47:04):
Well that's important, right, Like that's the important part of it.

Speaker 3 (47:06):
And it can also wire straight into your enterprise buss.
So if you're already paying for repose and you know
actions and all time, and you know space inside GitHub
with they already have that, then your sponsors just end
up as line items inside that nice payment system.

Speaker 2 (47:22):
Already.

Speaker 1 (47:22):
I'll tell you what we don't want. We don't want
the Spotify model. Like imagine GitHub. In order for you
to access any of this open store of source stuff,
you'd have to pay GitHub, you know, ten dollars a
month or thirty dollars a month or whatever, and then
you can use whatever you want for free, and then
that gets dispersed among all of the projects. Like that

(47:44):
model is horrible. It's horrible for the music business, and
it would be even more horrible for the software business.
I'm just the anti patterns are community.

Speaker 3 (47:53):
I've seen proposals for doing that through like Newgate, like
nugat would get a bulk upload and then send out
whoever has most downloads.

Speaker 2 (48:00):
I don't like that at all.

Speaker 3 (48:01):
I don't like any of those systems either, because they
all can be gamed. With the numbers. With the open
source maintenance fee, you basically say, here are the projects
I use. Whatever you know in your package reference or
your package cafig. If you're still using that, you look
at your packages you depend on. You chose them. They
didn't get in there because someone out of them. You
chose them. You go to each others project, you go, oh,

(48:21):
there's the fee for that one. There's a feed for
that win there's a feed for that, and there's a fee,
but there all of the things that I use and
the people that I depend on, I've now paid the fee.
You're done. You don't have to go down some crazy train,
you know, tree.

Speaker 2 (48:32):
And ultimately the maintainers are setting the fear for their projects.

Speaker 3 (48:36):
Correct.

Speaker 2 (48:37):
And if you don't like that fee, don't use that project.

Speaker 3 (48:40):
Right, if a fee is like ten thousand dollars per month,
you might go, hmm, I think I can have an
engineer use that source FEDE and maintain it myself and
all the overhead that goes with staying on top of
the source code, being awarable, security vulnerabilities, that whole list
I brought back. You're like, yeah, that makes sense. But
for a small company, ten dollars And I've had many

(49:01):
business people tell me ten dollars is too low, just flat.

Speaker 1 (49:05):
That depends on depends on the value right that you're providing, correct.

Speaker 3 (49:09):
And so the Wix toolset I use as a tiered model.
So we're going to try to also show that where
if you're a small company less than twenty people, it's ten,
if you're twenty to one hundred people, it's forty. And
if you're over that at sixty. That tiered model basic
to say that you're getting more value out of it
as a bigger company, that those tiering systems will see
how all that works. But the goal is basically, look,

(49:30):
nobody's arguing that ten dollars is too much.

Speaker 2 (49:32):
Yeah, right, like it just if it is.

Speaker 3 (49:35):
It's like a dev at one hundred thousand dollars a year,
it's like two hours of their time for the year.
So if you can take the source code, build it,
maintain it, keep up the date on all those things
for less than two dollars per year, then that your
procurement team's right. You should copy the code and maintain
it yourself, right, right, But two hours is not a
lot of time to keep up even build a project

(49:56):
and keep tracking. Come on, it doesn't work, and that's
why we want maintainers. Do you see the reactions when
other projects say, hey, we're gonna not be open source anymore.
You can see people being upset. She's like, look, you
have the source code, you can build it, and they're like, oh,
that takes work. I'm like, wait, so.

Speaker 2 (50:11):
You know it takes work. You know enough to know
why I'm where I am.

Speaker 3 (50:15):
You're complaining that it takes work, but we're not doing
anything to support the people doing that work. And I
want to be really, really really clear, because I don't
think I've said this yet. These are not support contracts.
These are not I if you're going to get fixed
my bugs, you're going to fix my features, you're going
to write the code. It's not that, it's essentially the
work it takes to keep a project running that people

(50:36):
don't see. I know a lot of people don't even
know that's there, but just sucks up so much time
of a Maintainer's so much energy out of a maintainer.

Speaker 1 (50:44):
Have you published the documents and the mechanisms to go
ahead and do this in your own projects? Like if
somebody's listening and they say, yeah, I want to implement
this in my project, do you have a little zip
file they can download and with instructions and everything.

Speaker 2 (50:57):
Yeah.

Speaker 3 (50:57):
So if you go to open Source Maintenance Fee dot org,
you will get presented with two options at the top.
If you're a consumer. It explains why the open source
maintenance fee is there. And I have a six minute
video where I tell pieces of this story in one
unified video, and then it breaks it down with the
fact and things like that. There's a separate route you

(51:17):
go through as a maintainer, and that essentially lays out
the Hey, you're a maintainer. Here's why you should consider
taking a maintenance fee all the work you're doing. Because
when I talk to maintainers, a lot of them had
never thought about all the work they'd been doing. But
as I was talking to them, when I was first
vetting this idea, a lot of them would like get
to that point. They all start nodding, going, oh, yeah,
I do a lot of wow, And I thought, oh,
that's a lot of work, isn't it. So there's that,

(51:40):
and then there's next one is this five step process.
I think of the steps to do, and the first
step is communicate the change. Tell your community that you're
going to introduce a maintenance fee at some point in
time in the future, with the date whatever that date
is for your product. And then it says here's how
you can set up with GIOB sponsors. And then here's
what you do and you read me, and then here's

(52:01):
the EULA. By the way, here's a EULA already man
verified by the fire Giant lawyers. So if you want it,
you can have it. It should work for you, no problem.
I can't guarantee that. My lawyer won't let me tell
you that. We guarantee that because lawyers won't ever do that.

Speaker 2 (52:16):
You're a lawyer.

Speaker 3 (52:18):
But it's good and because we got feedback on the
first draft that I had up there that was not good.
It had problems, and I got plenty of feedback from
the internet that it was bad. But we fixed those bugs.
No problem. And then it goes through on how to
add the EULA to your package. And I have steps
for both MPM, for for MPM and for new gits

(52:38):
because those are the ones that I understand enough of
to do that. But if people come along and say, hey,
here's how I could do it for other types, I'd
love to get that information on the website. But it's
it's like a five step process. And the big one
up front is copy this blank you know this message,
replace the date, and send it to the place where
your people are. Create an issue, pin the top, put

(53:00):
a discussion, put at the top, say we're doing this,
and then you do the rest of the steps and
it will take you a day, I mean or two
to do it. It's not hard to step up. Just
had to get the I mean the hardest part was
getting the yula put together that passed all the rules.
Now you just copy and paste it and replace your
license inside your your nigga peck and had.

Speaker 1 (53:23):
I can't believe we haven't asked you this question, but
how did it work out for you so far? And
how long has it been in place?

Speaker 3 (53:28):
It's been seven days?

Speaker 1 (53:31):
Wow, Okay.

Speaker 3 (53:32):
At the point of recording, it's been in force in
seven days. It has been announced for a month and
a half ish, because I announced it four weeks right
after the maintenance fee was announced, which was the end
of February, okay. And I got a lot of feedback
and various questions up front, not a lot of pushback

(53:53):
on doing it, not a lot of pushback on why
or none of that real negativity of that. It could
be that they're not saying it. I'm sure they're just
not saying out loud they're playing people. I'm sure they're
very upset that we're making.

Speaker 2 (54:06):
Do this work.

Speaker 3 (54:07):
I have got the feedback from some people say, hey,
this is a lot of work to go through our
legal team and our procurement team, and I'm like yep, yep,
we would pay you money, but the procurement team's really
a problem. I'm like, yeah, I know, like, well what
do I do. I'm like, dude, it's your procurement team.
Like you're going to have to educate them, and every
company's procurement team needs to be educated so.

Speaker 2 (54:28):
Well, and you're going to build up more language around
how to talk to your procurrement team as this goes by,
because part of this is what's the cost of us
moving off of this project or maintaining itself and like
showing larger dollar signs to the CFO, then get this
through procurement so we can keep working.

Speaker 3 (54:45):
So one of the feedback I got from people was
our one idea I got out there was hey, be
cool if you had a list of companies that had
already adopted this as yeah, we're doing this, so I'll
try to go there. We're early in this, and that's
why I was really happy you got had me on
because I just.

Speaker 2 (55:01):
Wanted super early stages. I think the main thing you
READNACT right now, Rob, more than anything is more projects
to set up like this.

Speaker 3 (55:09):
Yeah, So that's my feeling is that I was That's
why I'm really glad you guys had me here is
because we can get the message out to maintainers so
the day can start going, Yeah, you know what I am.
I know exactly what he's saying. I know exactly how
he feels. And when I first announced this at the
end of February, I got so many dms from maintainers

(55:31):
and you know them, you know who they are. They
DM me saying this is brilliant. I was like, great,
but I didn't have the ule at that time, and
there's a leap of faith that you have to do it.
We've seen a couple so I want to talk about
the commercialization that projects has been going through, because that's
that's what we're kind of I'm hoping we can counter here.

(55:51):
But the idea that maintainers will be like, you know what,
my time is worth something, sure, and I should be
paid for this set of work that I am doing.
That actually is taking a lot of energy out of me.
And if I could put this into my project, I'm
not going to retire. I might not have enough users
to make a business, but one developer I talked to
said he probably has fifty ten to fifty companies using

(56:16):
his software. I was like, so that's like, you know,
one hundred to five hundred bucks a month. He's like, yeah,
that's about a weekend. Okay. Oh if I had five
hundred bucks a month that I could do something fun
on a weekend, then I could spend the other weekend
maintaining my project. Because he's just like, why am I bothering? Yeah,
he's and he'll walk. Those companies will be out of luck.

Speaker 2 (56:36):
But you hit on the key point, which is the
alternative is they head towards commercialization, which is going to
make it even more expensive for a bunch of people
who want to use this. It's going to make ask
a developer to do thing I maintainer, do things they
don't want to do, like operating a business like that.
That is a weaker choice. Then here's the low friction

(56:57):
way that lets everybody keep doing what they're good.

Speaker 3 (56:59):
At, and it walks away from open source, which I
don't want. I don't want that to be the way.

Speaker 2 (57:05):
The alternative open source starts to implode.

Speaker 3 (57:07):
Yeah right, It basically says, you know what open source failed,
and that requires me to say, yeah, no, that idea
that I had well in nineteen ninety nine, and then
finally made a reality in two thousand and four that
you know, companies should do open source and it should
be a thing, and people and developer should do open source.
You should be able to go out there and create

(57:27):
communities around your source code. Wow, that should be possible.
It just says no, don't or don't be successful because
you will end up in a space.

Speaker 2 (57:34):
Yeah, you can do it, you just won't be successful.

Speaker 3 (57:36):
Where you hate it. Yeah, just don't be successful. Don't
don't have your project work out because you will end
up in a space that you want, or if you do,
you have to enter that space where I don't care
about any of you, which is a completely different way
of interacting with your project and the community. It's not
a community. It pains me and I'm I'm very conflicted
in this whole space still because I'm seeing people commercializing

(57:57):
their projects. At the same time, I couldn't reach out.
I couldn't reach out to everybody. So I'm hoping here,
at least take a little maintenance fee and go you
know what, I will follow that because there's a list
or no, no, I'm going to go route like that,
but a different way or a different spin on it great.
I want to see where people go. I just want
maintainers to have an option that they don't have to
give up and commercialize or just walk away, and they

(58:19):
can have a space that you know what, I could
fund a bit of my world here and feel good
about this space and if you know, and they'll have
other maintainers with them. I'm out here, right. So people
told me I was gonna get fired at Microsoft when
I said I was going to try to open source
my little project. It didn't. I was there for eight

(58:41):
more years until I decided to retire. I'm doing this now.
I was afraid I was going to get lambasted off
the internet. I haven't been, and I hope so we
could do something to change the ecosystem, because that's where
I want us.

Speaker 1 (58:53):
Well, I have a few open source projects that are
popular that then I think I might visit this with
So yeah, I'm going to be looking through my repos
and it.

Speaker 2 (59:03):
Looks like a weekend's worth of work. Yeah. To learn
the pattern, yeah, and put it into your project.

Speaker 3 (59:09):
Yeah. Yah, Yeah, you follow pattern and if there's issues,
you know, send them to me and will revise the
document and make it better.

Speaker 2 (59:16):
Yeah. And the more we can refine the material the better.

Speaker 3 (59:18):
Yeah, yeah, exactly, it's good stuff. Yeah, that's that's the
I hope we can get to a better space.

Speaker 1 (59:26):
I'm sure we will at some point.

Speaker 3 (59:28):
Can I add a couple of gripes at the end here? Yeah,
go ahead, you could try to stick where you want,
all right. So one people will say it's a rug pull.
You're going to get that the whole open source maintenance fee,
any charging for anything turns into rug poole. I don't
have a good answer that, because they're not entirely wrong.
It is a bit of a rug pull. It is
we're changing the rules on you.

Speaker 2 (59:46):
The ultimate rug pool is a project you're depending on
no longer being dependent and being maintained. Right, which rug
pole would you like? Yeah?

Speaker 3 (59:53):
Yeah, the alternative is exactly. The alternative is they just
go away. And my hope is that we can get
out get to a place where it's no longer a
rug pole. Because everybody expects it that companies walk up
to a project, go man, this one doesn't take a
maintenance fee or anything. How do we know that the
companies the project is going to stick around for us?

(01:00:13):
So I'd love for us to get to the other
side where it's not a rug pull, it's a you
need to do this so that we can, like, we
would like to have some interaction here, so we know
that you'll continue to maintain this project for us. So
I'd love for the to turn around. Maintainers may still
say I don't want money, because I don't want money,
that's fine. I'd love for it to be turned around,
so it's not a rug pull. The second right is

(01:00:34):
that I've been seeing this a lot as the commercialization
has started happening, or as this whole all these issues
have popped up. I see people saying they shouldn't have
made an open source in the first place if they
didn't want to give it away for free, and it
just it. It makes me so mad.

Speaker 2 (01:00:54):
Is an awesome piece of ignorance there.

Speaker 3 (01:00:57):
Because I didn't make it open source to make it free.
I made it open source so that people could join
and we could build something right right, But that's not
what happened. The fact that the source code is available
for you to do as you wish with it, as
in freedom to go forth, is what this is about.

(01:01:19):
It was never about me giving my time away for
twenty five years for free and having people not appreciate it.
That was never the goal. And it also is never
the goal that we'd get to the end twenty five
years later and say, haha, I'm now going to charge
you for this thing that you become dependent on.

Speaker 2 (01:01:39):
That was the goal. That's what I wanted all along.

Speaker 1 (01:01:42):
Like, come on, well, and the fact is right, you're
not paying.

Speaker 3 (01:01:45):
No maintainer's doing that.

Speaker 1 (01:01:47):
You're not paying if you're not making money on it.
If you are making money on it, it should be
less of an issue exactly.

Speaker 3 (01:01:52):
But this whole attitude I see about. They never should
have made it free in the first place.

Speaker 1 (01:01:57):
Say just I get so torq staggering bullshit.

Speaker 2 (01:02:01):
That never made it free. I expected contributions. They never came.
Now I'm buried either pay me or contribute. Well, not anymore.

Speaker 3 (01:02:11):
You know, I don't even expect contributions, like like, let's
be like, even as a maintainer, I didn't expect contributions.
I wanted people talking about it, helping people participating, working together.
I would have my project suffered significantly in documentation because
I'd hope that people would contribute what they learned is
a great contribution and just write it down and give

(01:02:31):
it back to us. Nobody did that. They wrote it
on their own blogs in their own places, and they
spread it all about the internet. They never came back
to a project. That's probably partly a failure on my
maintenance of my project and my doctition and my community.
But the goal was that people would work together and
we could all be set up ninjas together.

Speaker 2 (01:02:48):
Yep.

Speaker 3 (01:02:49):
Right, those sixteen people you talked about the beginning, Yeah,
those my people, right, that's why we're out here, right,
we're making these things happen, and we are not alone.
And then there's way, way, way too many people are
out here. Well, it's free, so I'm just going to
use it. And I can't believe that you didn't take
care of I issue ten years ago when someone else
opened it.

Speaker 2 (01:03:09):
Yeah. The original mantra of the open source community was
this small group of peers building stuff and helping each
other to make it better. Right, And that's I think
one tenth of one percent of the audience is actually
out there. And I'm not saying anything bad about that.
It's like, but recognize where you're sitting. Yeah, there's a
whole other show here to talk about. How do we

(01:03:31):
work with contributors to just recognize their value. But we
can do that today. Let's work on the reality of
where we are right now, which is that most of
these open source projects have a maintainer and that person
needs help. Rob.

Speaker 1 (01:03:44):
We got to pull the clock here and say thank
you very much. This is great. It's a great idea,
it's great stuff. I hope that I can get involved
in it, and I hope other people listening will evaluate
their open source projects and see whether this makes sense
to you.

Speaker 3 (01:04:03):
It's the beginning of a conversation that we need to have.
I'm hoping it can unlock more ideas so that we
get to a place that is sustainable for all these maintainers.
Thanks Rob, Thanks guys.

Speaker 1 (01:04:14):
And thank you for listening, and we'll see you next
time on dot net rocks. Dot dot net Rocks is

(01:04:39):
brought to you by Franklin's Net and produced by Pop Studios,
a full service audio, video and post production facility located
physically in New London, Connecticut, and of course in the
cloud online at pwop dot com. Visit our website at
d O T N E t R O c k
S dot com for RSS feeds, downloads, mobile apps, comments,

(01:05:02):
and access to the full archives going back to show
number one, recorded in September two thousand and two. And
make sure you check out our sponsors. They keep us
in business. Now go write some code. See you next time.

Speaker 3 (01:05:16):
You got JAD middle vans. Then I