Ep. #58, No Roadmap For Open Source

Paul Biggar: So, in the last episode, you mentioned open source management.

Edith Harbaugh: Yeah, I mentioned-- The original thing is I mentioned, somebody was looking for a book on it and they couldn't find one.

Paul: There's no book on how to manage an open source project?

Edith: That's what they were looking for and they were like, "I can't seem to find that book."

Paul: Yeah, what a surprise that is that there is no book on open source management.

Edith: Why do you think it's a surprise?

Paul: Well, open source management is--

I mean for most projects, and you know, obviously it differs for large and small, but the vast majority of open sources is small projects, and open source management is--

There's no road map, there's no plan, there's no docs, there's no communication. It's just like sometimes a pull request will happen and you might accept it or you might not.

Edith: Well I mean you show up with code right?

Paul: No! No that's not how you run projects! That's a fucking terrible way to run projects.

It's like someone shows up with a code and is like, we have to decide; do we want to go in the direction that this arbitrarily stranger has decided for our project? It's ludicrous!

Edith: We got 30 seconds in before we lost the clean rating.

Paul: Like, open source projects don't have roadmaps. They don't have what we want in our project. What our project is supposed to do. What direction it's going in.

And so sometimes you have people who show up with a PR that's just like, goes in a different direction.

Edith: Well, I mean, open source projects do usually have some sort of statement or purpose.

Paul: Large ones often have a statement or purpose. Small ones rarely have anything.

Like, you're lucky if they have a doc that describes what it does.

And then often once they get to sort of medium sized, where it's like one maintainer but there's 15 or 60 contributors who have, like, passed something in and maybe are hanging around or have started or whatever.

In that world, you will often have like a pretty comprehensive README.

But it won't be, you know, it's very often it doesn't have like documentation about the internal structure of the code base. I've almost never seen a roadmap.

When Mozilla was 300 people there wasn't a roadmap.

Edith: Really?

Paul: Yeah!

Edith: How did you decide what to build?

Paul: Everyone in the company decided what they were going to build.

Edith: Wow!

Paul: Yeah, everyone in the community, which is, I guess, about twice the size of the engineers and company.

Edith: How?

Paul: I mean occasionally some of the people would talk to each other and maybe two or three people together decided what they were going to do. But there was no, like, plan.

Edith: What if two people were trying to check stuff into the same branch?

Paul: The same branch?

Edith: The same area if two people came with conflicting code?

Paul: In Mozilla, I mean, you made all your patches through Bugzilla, so you posted a patch in Bugzilla and once you got all the approvals you could merge it and if it conflicted someone else you would have to rebase it or whatever.

Edith: Mm-hmm.

Paul: I mean, through the history of large open source projects, contributions aren't even pull requests, they're like managing patches that are sent often to like mailing lists.

Edith: Mm-hmm.

Paul: It's bad.

Edith: It's bad.

Paul: But I mean the whole thing is bad, it's like any open source project you use, do you know it's roadmap? Like, do you know where you would go to find out what its roadmap is?

Edith: Some of them are actually pretty good.

Paul: Okay.

Edith: We'll give GitLab a lot of credit.

Paul: Okay, yeah. Yeah, that might be the only like really well run open source project.

Edith: Yeah, I mean, Sid's style and GitLab's style is extremely transparent and extremely well run in some ways.

Paul: Extremely what?

Edith: Well run.

Paul: Well run, yeah. Right, they have a roadmap and they say when things are coming.

Edith: Yeah, like so if you could go and they, to be frankly, they have a LaunchDarkly competitor, and you could go and you could see the roadmap for it.

Paul: Okay.

Edith: Which is great, the company is very up front about these are our projects, this is what we're working on. Here's our deadlines.

Paul: When did they change the roadmap?

Edith: You know, I'm not that tuned in with GitLab.

Paul: Okay, all right. But yeah, I've seen that they have the stuff in public. The company that is a company build around an open source project. It's sort of an unusual situation.

Edith: Well, I appreciate his candor so I'm friendly with Sid. We should maybe have him on the podcast some time.

But like he'll be really up front. Like when we hang out, he's like, "Edith, I have a competitor to you. You can go read about it here." Like thanks!

Paul: Sure you can go read about it here, wonderful.

Edith: And then he's also like, "Edith, that was a great talk. We will compete with you in this area."

Paul: Is there anyone that Sid doesn't compete with?

Edith: Restaurants.

Paul: Restaurants! I mean, they've got like their serverless alternatives, they've got their, have they project management?

Edith: I'm sure somewhere.

Paul:Somewhere deep in the, and here's where you can go to read about that!

Edith: Yeah I mean, they're extremely transparent but they do have a roadmap.

Paul: Do we know any other open source projects? Like at all?

Edith: HashiCorp.

Paul: HashiCorp, okay.

Edith: They're open source, they have a roadmap, they talked about it. They definitely, though, they have enterprise features and non-enterprise features.

But because they have enterprise that pay them, they are very good about--

Paul: About roadmaps.

Edith: Yes.

Paul: Okay. What about open source projects that are not companies?

Edith: Then it gets much harder. I admire both of those companies very much, GitLab and Hashi.

If you are ultimately selling B2B, you by necessity have to have some sort of management.

Paul: Right. And so what I'm saying is like, most of open source is not companies. Like and what about the unsustainable open source? The people who have--

Edith: The passion--.

Paul: People who built a library at work, and who open sourced the library it's a Ruby gem or a Python egg, or whatever it is.

Other companies use it, how do those non-companies, individuals, manage open source?

Edith: The way I've seen it done is that they will have some sort of doc where they say what they're interested in doing next.

Paul: I've rarely seen that to be honest.

Edith: So, LaunchDarkly does have competitors that are open source.

Paul: Okay.

Edith: And I do give them credit, I think if you want to use that, great. At least you're feature flagging, that's better than not feature flagging.

So they'll post it and it'll say like, "Hey here's our features, here's what we're interested in building next."

Paul: Yeah, I released a standard library, sort of open source thing a while back called "Tablecloth" and I posted like, in the README, you know, here is 15 ways you can contribute.

Here's like, what we want to be, where we are in that journey and how you can contribute to it.

Edith: Yeah, which is a roadmap.

Paul: It is a roadmap, yeah.

Edith: I mean it reminded of, you know, Y Combinator. They post a list of companies that are interested in funding. They're like, we're interested in the space, we wish there was a company here.

Paul: Right.

Edith: Which I think is good, that's very much like an RFP.

Paul: Yeah. One thing that we started in this when I was at Mozilla, is tagging good first bugs.

So tagging places for people to get involved in the issue tracker.

And I think most open source projects don't have like a well curated set of issues, there's just sort of like, the GitHub issue tracker is sort of like, the common forge in a certain sense.

And people keep it open because the issue the people reported aren't dead or the opposite, they're way overzealous and they'll close anything that like no one is contributing to.

Which honestly, it's probably more sustainable.

Edith: It's nice to give people a nice honorarium.

Paul: It is, and there's so much like free labor that wants to show up and help out. People see a thing and they're like, I want to help with that thing. And so it is nice to enable them to do so in some way.

Edith: Yeah, I mean it's the difference between when you're first learning to drive and you like to, maybe, practice in a parking lot versus getting on the Bay Bridge at rush hour. And like being able to tell people, like, here's a easy way to--

Paul: I mean, I don't think it's just learning. People just they like to help.

Edith: Yeah, oh it's--

Paul: Even very experienced engineers like to, Oh! Yeah this is a cool thing I'd love to add a thing.

Edith: It's an evolutionary thing. Like we have been like evolved to help each other, otherwise like you freeze in the winter.

Paul: Right. So why don't the smaller folks tend to have this on-ramp? Just time.

Edith: It is some amount of work to figure out the easy stuff.

To figure out hey, this is low hanging fruit but I'm not just going to do it, and I will leave it for someone else to do, if that makes sense.

Paul: I have an associated theory, which is that open source is largely engineers.

Edith: By definition, because you have to--

Paul: Well, no! I mean like projects need things that are not just engineering. They need technical writing, and many of them need design.

There's no designers in the open source world and that's why most open source software looks like plain shit. I feel one of the things that open source has done very poorly is make room for people who aren't engineers.

And part of that, I think that would be really useful for an open source project to have, is someone curating the issue tracker, people doing project management and product management, and like writing up specs that other people can contribute to, and that sort of stuff would actually be really useful.

Edith: Paul you're warming my heart. Because like that's the stuff I used to do.

Paul: Yeah.

Edith: I don't do that day-to-day anymore, but like I used to run the ticket scrubs.

Paul: Yeah.

Edith: I used to write up the specs, and there was always those engineers who were like, "This worthless, I just need to code." "Why is this engineering manager shoving her spec in my face?"

Paul: Yeah you just need to write code and you don't even need to know what the code is supposed to do! You just write it.

Edith: And like why do we need Triage? Folks like, I know what's important.

Paul: Yeah, I was thinking of a particular example, oh Rust! Rust does really well.

Like, Rust has governance and it has people who's job it is to like do all these things and much, much more, I mean, I think most of them are coders or coder adjacent because its programming language.

But like, people are, and I think many people are paid, but many volunteers as well, do all the project work, essentially.

Project work is exactly it. It's an open source project that does project work, it doesn't just have code that you can contribute.

Edith: Which gets very disparaged, or put down sometimes. Of like, oh, you're just shuffling around tickets.

Paul: Yeah, well I think Rust has multiple committees, like, in my head eight or nine committees around certain areas who are responsible for certain parts of the project.

And the parts of the project that they're responsible for are not necessarily things, and I think are more often not things, where their contribution is code.

Edith: Yeah.

I think there's a ton of behind the scenes work to make a project go smoothly.

Like I was part of the Lean Startup email list, so I was originally just part of it as a contributor and then I became the moderator. To get an email group running well.

Paul: Oh my!

Edith: Is so much work.

Paul: Why?

Edith: We had people all over the world who would sign up on the email list and you have to review the emails and make sure it's not just blatant spam.

So, is it just like sign up for random nutrient supplement.

Then there's all sorts of nuances of like, is it drive-by postings? Is it somebody being mean to somebody else? Is it somebody being off-topic?

You know, it's actually a lot of work.

Paul: Right.

Edith: How do you stop the flame war?

Paul: People are so hard.

Edith: And because it was email it was harder, I think Reddit is actually done really well because it's a bulletin board and you could pull down posts.

Paul: You mean they can be upvoted and downvoted.

Edith: And the moderators can delete stuff.

Paul: Oh, yeah, yeah, yeah.

Edith: If it's an email list--

Paul: You either let it through or then you struggle.

Edith: Or, like we had a rule that if you had posted more than two times we wouldn't review it because otherwise it just became too much work for us.

So these long flame wars would happen, and then we would wake up and would be like, "Oh my god!"

And then how to we stop people from responding, and you can't.

Paul: Right, right, right, oh yeah.

Communities are challenging. I think that the vast majority of open source projects are one person. There are one person and then there are some how other people involved.

So like, most Ruby gems I'm thinking of, one person owns it. Or NPM packages is like, something like 700,000 NPM packages.

Edith: Wow!

Paul: Like it is increasing at a ginormous rate, up and to the right. And, yeah, most of them are one person.

They occasionally get a company behind them or a company who's business is the package, which isn't that common. But, for the most part there's like one person and occasional contributors.

Edith: Well, what patterns have you seen work well then in open source?

So you said you thought Rust was well run because they had different committees, they actually invested in management.

Paul: But that's also a thing of a certain size, you know that wouldn't have been appropriate in the first few years of Rust when it wasn't that big.

Also, they have a sponsoring organization behind it.

Edith: Yeah, I still remember Armon telling me about HashiCorp and how one year they got 100 downloads.

Paul: Yeah, yeah.

Edith: Not 100 downloads a day but 100 downloads for the year.

Paul: Yeah. You know, we're just starting this with Dark, we're now letting people into our community and in the near future we are working on things like package managers to allow of people to contribute to the community.

And there's a lot of this stuff to be like, there's sort of two angles, there's how do we make it possible for people to take part in the community?

And then, how do we stop them when they're taking part in the wrong way?

Or how do we point them in the right direction, or like how do we make it inclusive and welcoming and just a nice place to be?

Edith: Yeah, I mean how do you harness for good?

Paul: Yeah.

Edith: Not let people be terrible but not be not welcoming.

Paul: Yeah.

Edith: Any other lessons learned?

Paul: The thing that I really enjoyed when I was at Mozilla, I was working a lot on contributor engagement stuff, and like, you need a doc that someone can learn.

Like, what can they even do? And now that they have decided to do it, how can they help with this?

And so like, here's a couple of bugs that like, you know, we have a lot of bugs that look like this.

Here's seven of them, here's three that have been solved, you can take the pattern to do it.

Then provide ways for them to ask questions, provide ways for them to get the help that they need and to make sure that their work isn't wasted and also providing guarantees that if you make a pull request, I will respond to it within three days, within six hours, within a week, whatever your thing is.

Edith: Service level.

Paul: Yeah, right. I mean, these are essentially customers in a certain way, and they are paying you through time for your time and you need to provide some sort of service level agreement and if you don't, then they'll stop doing that, and other people will see that it's desolate over here and they don't want to contribute.

Edith: Or vice versa, they'll assume your service level is instantaneous.

Paul: Is instantaneous?

Edith: They're like, well I just checked this in, why haven't you root it? It's like no, our service levels will get back to you in three days if it's something I'm volunteering on.

Paul: Yeah, and so when I make open source and people contribute, and that doesn't happen that often, but I try to get back to them, I try to get back to them quickly and then tell them whether the thing they have contributed is directionally the right thing.

And if it's not, then I will work on docs to make it so that people can know it's not directionally the right thing.

Edith: Yeah, the more you talk the more I think about open source does not necessarily train you to be a good manager.

Paul: No of course not, its the exact opposite of how you should run an actual project.

Edith: Tell me more.

Paul: Or a team, like, I've argued a bunch of times about how the flat structure is like terrible for companies.

But it's essentially the open source structure, right? It's a meritocracy, code walks and, what is the thing that people say?

Edith: Code talks, bullshit walks.

Paul: There we go! There we go, okay, right. And it's complete crap.

Edith: It's bullshit!

Paul: It's right, it's the worst way to organize humans is "code talks and bullshit walks."

Edith: Well it assumes that you already know how to code and that you're already slotted in to this is the right way to do it.

Paul: Right, it assumes that you know all the political machinations of what you're trying to contribute to and that somehow if you just show up with the right code that then that's the--

And that's just not how organizations work, organizations are groups of people who are striving to work together and are doing the work to make dealing with other humans possible.

Edith: Well, anything else to add?

Paul: I don't know why you always ask this.

Edith: Well, I just want to make sure that you--

Paul: It's just, we've come to the end of an episode and it's coming to a nice conclusion and then you just open it up.

Edith: Maybe I'm trying to make sure that you have a space!

Paul: Oh, don't worry. Don't worry, if I have a thing to say I'll make sure that I find a time to say it.