Request For Commits – Episode #16

Open Source History, Foundations, and Sustainability

with Danese Cooper


All Episodes

Danese Cooper joined Nadia and Mikeal to discuss the history of open source, how the term became a thing via Tim O'Reilly, feeling empowered as an open source contributor, companies’ relationship to open source, foundations and their role (or not) in governance and sustainability.



LinodeOur cloud server of choice. Get one of the fastest, most efficient SSD cloud servers for only $5/mo. Use the code changelog2017 to get 4 months free!

Hired – Get hired. It's free — in fact, they pay you to get hired. Our listeners get a double hiring bonus of $600.

Bugsnag – Mission control for software quality! Monitor website or mobile app errors that impact your customers. Our listeners can try all the features free for 60 days ($118 value).

FastlyOur bandwidth partner. Fastly powers fast, secure, and scalable digital experiences. Move beyond your content delivery network to their powerful edge cloud platform.

Notes & Links



Our transcripts are open source on GitHub. Improvements are welcome. 💚

We talk about open source sustainability on this show, it's a really hot topic now... But you've been working on open source sustainability I think maybe before it was called open source, so why don't you give us some of that kind of history and back-story through the lens of sustainability?

Sure. So when I got into open source, it was just kind of the beginning of companies caring about open source, and there was an early vanguard of companies that either they already kind of had open source as part of their history, although maybe it was called 'free software' when that started, or they had some vision about why it was gonna be important to them... So the big players were Sun and IBM, who has been in it since very early. And there were some companies that were really against us, and we had the classical light and dark, if you will... So Microsoft was pitted directly against us, and there were a couple of other big companies that it really was gonna threaten the way that they did business, so they were pretty clearly against us.

And then there were up and coming companies like Red Hat, that were just starting out, and were tiny, but were so deeply based on open source that they cared a great deal, and they were building alliances all the time... So that's sort of the point at which I came in.

It's important to say that there was a good 15-18 years of people developing software in this way, that would be called the modern era... Because we all know that in the early, early, early days of computing everybody shared everything, because it was just a hobby, and they had to share everything because it was the only way you could reasonably get anything done.

[00:03:50.19] The point at which that all changed has been classically tied to the Homebrew Computer Club and Bill Gates' realization that he wanted to charge for essentially access to the sources, although that's not how he framed it. But he wanted to start selling non-source-accessible executables, and he made a very successful business out of that. The modern era of open source wasn't exactly a reaction to that, although it's been characterized that way. I think some of it was just people who it was more convenient for them to work in the old-fashioned way, because their problem space was new enough that they needed that kind of sharing, and I think the BSD community falls pretty evenly into that... And maybe also sendmail and bind and all that stuff but there were other things that were definitely starting to head in the direction of money, and money changes everything... So that's about when I came in the door.

In those days, the corporations wanted in on the marketing lift of the coining of the term 'open source'. Tim had that famous meeting and they came up with that cool term, and then he used his media arm to make that term interesting to people, and almost immediately there were people that just wanted to take advantage of the lift the term was getting.

Some existing projects that had been around a long time and were pretty successful all of a sudden had to deal with that, the hype factor. People were code dumping, for instance, at Apache. Apache had to change its license and also some of its practices to make sure that people got it, that they didn't have access to the Apache brand just because they dumped some code at Apache.

Can we talk a little bit about just the media lift part of it of how he made sure that people were using the term open source? Because I think people don't necessarily know about that.

Well, I don't think he enforced anything. It was sort of the anti-free software movement, if you will, and I don't mean that in the sense that they were pitting themselves against free software; I mean they were using different tactics. Tim and others like him saw amazing software coming out of the free software movement that was being hampered by the political attachment that the authors of the GPL had. Basically, in GPL v.2 the first page and a half of the license is a political manifesto, before you ever get into any legal terms. That made a lot of people uncomfortable in the straight corporate world, and also governments and places like that.

Tim saw an opportunity to reframe the whole thing under a new term that, first of all, didn't have the inherent ambiguity of 'free', because in English 'free' means both liberty and gratis, and that was a problem, because people got them confused. Free as in gratis doesn't necessarily lend value to the endeavor, free as in liberty does. Free as in liberty is very definitely the message that the Free Software Foundation was pushing, free as in gratis was what was driving people's adoption, so there was an ambiguity... Not all people, but certainly corporations were picking things up for that reason. So open source was a little more honest; it wasn't ambiguous, I guess, would be the answer.

So he came up with the term, and then there was a Perl conference that was pretty successful, that he'd been running for a while, and he started it around the time that there was a lot of contention in the Perl community because of the work of ActiveState to creative a Windows-native version of Perl, which felt like crossing the streams, if you will, of loyalty, since Microsoft was a pretty vocal critic of open source (or free software) generally.

[00:08:06.26] He changed that to be the first open source conference, OSCON, and invited everybody, and used the fact that the publishing industry gave him disposable income to push memes to get more people thinking about open source; he wrote extensively about it. His blog was well read -- actually, pre-blog, his writings were well-read, and he had a venue to write. Before blogs, all of that was rare, right?

And almost exactly at the same time we started to see the rise of peer-to-peer computing. It was only maybe a year later that the first peer-to-peer conference happened, which was also one of his... That was both attempting to address some social ills, which is interesting, given the separation or apparent separation between open source and free software. I actually think they're the same thing, just trying to express themselves in a different way, but free software led with social responsibility, but I think most open source people had that bent as well at that point... So in the peer-to-peer movement there was a whole lot of helping political activists, and using the lightweight, importable nature of peer-to-peer networks to do interesting things, starting with sharing music more widely.

Famously, there were early music sharing platforms that the music industry really disliked, and one of the really successful ones was Gnutella. Gnutella was written by a bunch of people who saw the central architecture of the first experiments in music sharing and decided that a massively decentralized architecture was gonna be harder to quash, because there would not be a single point of failure, or a single throat to choke, so they created this endlessly replicating "everybody is a server" or "everybody is a client" architecture for music sharing.

Almost immediately, Larry Lessig showed up and started talking about copyright problems, and the confluence of the change in the music industry and the attempted change in copyright law and open source - they all converged at the same moment. So for a really long time there, every open source conference had a huge component about music sharing and media sharing generally, and that gave Tim a much bigger springboard for his message about open source. So some of it was his cleverness, and some of it was just a lucky confluence of time and place.

Interesting. So this is happening around the same time that Linux was also on the rise, so before we kind of leave this era, one question that I have is that -- one of the things that I have to talk about a lot right now is how there are a million reasons why people contribute to open source, and legal obligation is usually not one of them... The kind of legal obligation you have with copyleft. But often, people point to "Well, in this previous era, the only way to get people to contribute at the same time was this legal obligation." How important do you think that was, being that there were these other forces that they got people into open source that weren't tied specifically to the legal obligations?

[00:11:48.04] You know, I don't remember that that's why Linus chose the license. I think Linus chose the GNU license because it was the only one he knew. Richard Stallman did a lot of running around, talking to universities about why freedom was important, and his style is very sympathetic to people of that age and that ilk and a lot of projects from that era are licensed under a GNU license because they had heard Richard speak and they knew it better than any of the other options; they didn't really understand what the other options were.

But the BSD project, which was the permissive licensing that Bill Joy invented, happened almost -- well, now I'm in trouble, because MIT was working at almost the same thing at almost the same time... But permissive licensing dates from almost the same era as the free software licensing, and the projects pre-date the projects that Richard Stallman launched under that new license... So I think there's always been both sides. I have to say that -- I mean, I have a bias, because I've been an Apache member for a long time... I think that in my experiments for Sun with pretty much every licensing model you could possibly imagine, including all the possible hybrids, permissive licensing definitely drives adoption better, if you happen to be a deep pocket, trying to get non-members of your community to join in, right? Which is a bunch of ifs. But there is that situation.

In the early days of corporate involvement in open source, the very first corporate project was Mozilla, and Netscape at the time was considered a big company; not as big as IBM, but they had a pocket and they were worried when they constructed their project. They did it as a Hail Mary, because Microsoft had just destroyed their market by distributing Internet Explorer with every copy of Windows for free, and Windows was 98% of the install base at that point... So this is why that whole lawsuit happened about anti-competitive practices that Microsoft was doing. And they'd been doing various other things, it wasn't just open source were picking on. They were anti-competitive all over town, but this was a really obvious example.

So Mozilla, among other things, did a Hail Mary and put their client software that was competitive with IE as open source, thinking that that would drive adoption and keep them alive. And it worked, right? But they were so worried that people would not feel comfortable as individual contributors, because at that time most open source people were hobbyists and individual contributors. They basically waded everything in their license to reassure the individual contributor that they weren't going to harm them, while still being fairly legalistic about things like copyright jurisdiction, patents and a bunch of other stuff. They were really bending over backwards. As it turned out, they needn't have worried because their initial code push was kind of a mess, it wasn't really set up for anybody to use it.

The next thing that happened was they got a new owner, and the new owner didn't like the way that open source worked - this was AOL - so they were gonna pull the plug, because they couldn't get their own stuff in fast enough, and because the community vetting process was frustrating to them.

We were in the middle of that lawsuit, and Sun decided that it couldn't afford to have that browser go away, and so another Hail Mary thing happened where IBM and Sun's lawyers went and talked to AOL and convinced them to release the IP into a foundation, and then to give a little bit of funding; Sun and IBM each also gave a little funding, and that's how the team was provisioned to write Firefox.


You were talking about copyleft versus permissive licensing, that it started around the same time... How deliberate - when you're saying things like "permissive licensing was useful for driving adoption, and still is today", how deliberate were things like the idea that copyleft could prevent anybody from taking your stuff and running with it?

[00:16:13.10] You know that those licenses, even today, all but the AGPL, are still trigger on distribution of the code. People don't really distribute code so much anymore, because now we have software as a service, so as the pendulum swings back and forth between client server and peer-to-peer - we're kind of in a peer-to-peer place now... And there isn't distribution happening, there's no separation, so most of the requirements that you give back are gone now, except in rare cases, and they're in places where the software is going to meatspace like the automotive industry. There's still lots of GPL violations going on in places like that, because the code is distributed physically in a product; it's not a server-oriented thing.

Back in the day, the free software people really genuinely felt that they had to compel anyone who touched the code to give back changes. When we were explaining licensing to corporations, we used to say "For a free software person, the worst thing that could happen is a piece of code gets used in a non-free way, and for the permissive people, the worst thing that can happen is a piece of code doesn't get used." [laughter] It was really that simple.

The Apache people were like "Look, we would much rather have gifts of code that people wanna give us - they're gonna be higher quality than gifts of code that people have to give us, and they're gonna do the least they must in order to fulfill that obligation", right?

But I think that the free software people were absolutely coming from a place of trying to push the right behaviors, they were just using the stick instead of the carrot.

Yeah. I hear it uses this example now of "Well, if only everybody had been GPL, then you wouldn't have this problem of people using and not contributing back", because that was the point, but nobody wanted to use that license.

But I don't think that's true...

I agree, yes.

...because now we have software as a service and they don't have to anymore. On that model, we would have almost no contributions now, because nobody would be required to do it.

...or adoption.

Right, and if adoption of the software is one of the ways that you attract contributors, then anything that harms the adoption of the software is going to lead to a lack of contributors, especially if this other legal mechanism isn't even there.

Right. I mean, when WebSphere, which was just Apache's web server wrapped by IBM and turned into a product which is legal under permissive licensing - when that happened, the whole free software movement was getting out their popcorn, because they thought that it was gonna fail, or it was gonna show up the permissive model as insufficient. But what actually happened was IBM for a long time had their own version and maintained their own version and did all the extra work things that proprietary companies think they have to do, and then at some point it got to be too painful to have to keep backporting their own version, as the open source version was being improved by people that weren't them. So they finally got it that it made sense to send their own stuff upstream so that they could stop with the backporting and also with the dealing with conflict when the open source community solved it in a different way that they solved it. They got it that the point was the solution at the end of the day, and not necessarily who wrote it, and both of those things were pretty well proven out.

It seems like there is a concern on the free software side of people using the software and not contributing back, and there's definitely the view now, too -- I think you've described it before as like people worried about freeloaders, or whatever... [laughs] How has that changed over time, because the language that people use around it now is very different than I've heard in the past.

[00:20:12.08] Right. Well, I think that a lot of the enforcement activities that the Free Software Foundation engages in are around people who use the software and extend it, and don't give back their interesting extensions. That's because they have curiosity about how people are using it, and they want everybody to be able to take advantage of those changes.

I don't know if you guys are old enough to remember the Nordstrom chocolate chip cookie, but...

There was a recipe that running around on the web for a while, and there was a story that went with it, which I think got debunked... But the story basically said "Somebody at Nordstrom started to charge me $14 for a cookie - and it was a really good cookie - and I got the recipe and I'm gonna share it with all of you because $14 is too much for a cookie" was basically how the story went, right? That's an interesting story because Richard Stallman used to use a cooking metaphor when he was explaining free software. He would say, "You know, that time you added pecans to the cookie recipe and they came out a lot better, and all your friends really liked them, and you were able to give them that recipe because there isn't a copyright protection on the cookie recipe - that's what we're trying to do with software, right?"

So what they were trying to make sure was that if anybody came up with a clever hack like pecans, everybody got to have the pecans and not just the -- people couldn't make money off the pecans, and adding them to a recipe that everybody else contributed to... So it was a sharing thing, and kind of a fairness thing, and it probably still is, in their world.

But the freeloader problem is where people aren't contributing both code and support, right? There's different ways to get involved in open source. One of them is if you've done something clever with the code, you give that back, but that's not even always all that desirable, because what you did with it might be esoteric and not all that applicable to the general public. What you did with it might be your secret sauce; Google has never given back the bulk of their special changes that they've made to Linux to make it work for their scale, because it's tied to the way they do their business. They think that it would be giving up a competitive advantage. They're not required to, because their services are offered as a service, so they've gotten around the distribution problem... But they came up with the Summer of Code, and they open-sourced a lot of other good stuff, and they try to mitigate the fact that they're unlikely to give up those changes to Linux; they do give some of them up, for the same upstream reason, because it's a pain in the ass to backport, but they don't give up the ones that comprise their secret sauce.

So are they a freeloader? They're not giving up those changes. Maybe those changes would be super useful to everybody else and maybe if they would give them up, the commoditization of search engine technology would mean that we didn't have to deal with that AdSense quite so much. On the other hand, they're trying to balance the scales through some of their other activities, so are they a freeloader or aren't they?

I hear from younger open source people a concern about the flow of money, and I think that's a really interesting question. Some of the modern foundations are really designed to attract a lot of money, and that attraction of money is then gonna be spent on things that are last mile projects, or things that the group of people that were doing it before the money came in weren't finding time or resources to do.

[00:24:11.22] That problem of "well, the group that have attracted this can't get through all the work that we'd like to do" problem isn't a new problem, right? But some of older foundations are designed to run on almost no money, and I think that that was a conscious decision. The Apache Software Foundation runs on almost no money, and the reason that they do that is conscious, because they first of all didn't wanna be a deep pocket that was gonna attract patent trolls and things like that.

Originally, when Brian Behlendorf first talked to me about the desire to create a foundation - it was obviously before the foundation happened - as he's explaining it to me, one of the design concerns was a concern about patent trolling, and they had looked at Mitchell Baker's work on the patent piece license part of the Mozilla license and they wanted to add that to the Apache license, and they wanted to do it in a way that made it a nice idea for Apache to become a patent pool, because they thought that they needed to have a patent pool in order to protect the different entities that were coming into Apache, and as it turned out, that didn't really happen... It was sort of an idea that never got off the ground. Even more recently, the Open Innovation Network is trying to do that now, and it's been kind of a hard sell, and that has to do with the way patent law works.

But the idea that patents could make it in as part of a give was an interesting idea for a while. IBM opened 500 patents at one point. Scott McNealy famously told everybody that the patent situation with the Solaris was -- basically, he was indemnifying all the members of the community against any kind of patent action because he owned all the patents on Solaris, and they were gonna be unenforceable after he open-sourced the code.

I think this is a really good lead-in to foundations, and...

Well, especially that Mozilla story is probably the best lead-in I gave you to that topic.

That's a pretty good story.

Yeah. There's a piece of that, by the way, Nadia, that I always wanted to tell you.

Oh, great.

So the piece I left out of that story has to do with Mitchell Baker... Have you ever met her?

You know who she is though, right?

She runs Mozilla. She has run Mozilla since the beginning of time... So she started as a lawyer and she wrote the license, and then she got intrigued by the project. She had actually worked at Sun before she went to work for Netscape, so they knew her as a lawyer. And she got intrigued... She got a job as the general manager of that division, and her title was made Lizard Wrangler almost immediately. So she was doing her job, and then one day AOL buys the company, and they wanna get their changes into the browser, so they're trying to push her to get them in faster, and she's sticking with the process that the community has agreed to, and vetting everything, and they decide that she's the problem, so they fire her.

She had a pretty good severance package, she had a golden parachute of some kind, so she wasn't worried about money. She went home, she dusted herself off and she logged on and she kept running the project, and all of the engineers kept deferring to her, more importantly, right...? [laughter] And to be fair, they didn't all work for AOL by then; a lot of them worked in other people's companies, and they were just contributing. But everybody in that community was still deferring to her, so AOL said "Oh, I see. Yeah, okay, we get it. We didn't understand, but we still don't like this, so we're gonna pull the plug."

So she called me up one day and she was just panicked. She was like, "They're gonna pull the plug", and that's when we got it together to strong-arm them to create a foundation, basically. But [unintelligible 00:28:07.18] That's open source.

[00:28:15.20] When I give the talk now to people about standing in their power as open source developers -- because honestly, the influx of new people that have come into open source, the most troubling this for me hearing them talk is a lack of understanding about where they can push back, and that they're gonna lose the whole game if they don't continue to push back on the things that will kill open source, so that's why I do that talk now... My brief sustainability talk that's got the seven points that I think you really have to focus on when you're thinking about standing up and saying "You know, this isn't right", which people have to be willing to do, just like Mitchell did.



Having that history is so important because what I've seen is a lot of people feeling isolated and not having that sort of long historical lens of seeing examples of where the other people have been able to push back and really understanding that, and I think almost some of that comes from open source being so default right now that people don't think of it as "Oh, I have this unusual power." They think "This is just sort of what everyone is doing, and I'm just gonna sort of accept things the way they are and be miserable", which is not great... But it's stories like that that make you think "Oh wait, there's something really powerful about the way we work now, and we have a way to leverage that."

Yeah, if you were an engineer before we did all of this work to change things -- I mean, it would be a lot like being an engineer now in a lot of places like [unintelligible 00:31:18.24] Think of yourself as a cog in a wheel for a minute; the problem is that engineers are artists. A good engineer is attached to the creation of the thing that they're building just exactly like an artist is. Paul Graham wrote about this a long time ago, but we all kind of knew it before that. And not all engineers are that, and not all need to be.

I mean, one of the reasons that Microsoft was so opposed to open source I think was their developer base -- when Steve Balmer ran around, screaming about developers with the sweaty armpits and all that, he wasn't talking about people that were gonna get to invent Microsoft products, he was talking about consumers of Microsoft products, and Visual Studio and Visual Basic were basically designed to make the job of programming easier, so that non-artists could still do it. It was kind of like paint by the numbers, in a way. Visual Basic is very much just stringing together other people's work, like beads, right?

[00:32:26.14] So there's two kinds of programmers - there's people who invent stuff, and there's people who work with Microsoft's tools, and that's why it was so dangerous to them. And that was a gross generalization; of course, there are people who invent stuff with Microsoft's tools, but there's a really large percentage of the kind of programmers that just show up every day, and they're not bad people... They're working, but they're not motivated or trained up enough to really be inventors, and open source was founded by inventors.

I think that's a big distinction that's growing now, especially as programming is becoming easier for a lot of people... And that's sort of the point, right? You have these tools that you don't have to go deep into the weeds and figure out how to build things.

Well, that's what abstraction does, right? We're working on five and six GL languages now, and those abstractions save you from having to pay attention to pointer math, or any of the things that you used to have to really have got, like, powers to learn how to use the language well. But along with that comes the free style of working that we have; there's a lot of other things that come from us being the one irreducible quotient, right...? We are the thing you have to have in order to make software.

That's how I felt coming into it as an outsider... Like, "Wait a minute, all these people are forming the foundation of software for everyone else, but they seem to not have the leverage that they should", and I think that that's the part where even for an open source developer today who's pushing things forward and innovating, I think even they still don't recognize their own influence and power sometimes.

Yeah, which is why I do that talk... [laughs]

Yeah, which is really important.

...which we're gonna call the superpower talk. It has a superhero in it, and everything; he happens to be a little boy, but... Yeah, I think it's really important for people to realize that you've gotta be uppity, because you know, it's kind of like democracy, right? If you wanna talk about the real freeloader problem, the real freeloader problem is people not showing up at all, and just expecting somebody else to do whatever it is.

When we started out, people were just so excited to have an opportunity to work together and get stuff done so much faster and so much more efficiently than it was happening in their day job. People used to say things like, "Look, if my employer ever tells me I can't do this, I will quit, because this is the only thing that keeps me going." And they didn't mean their day job, they meant the evenings and weekends they were spending on their open source projects.

Wow... That's such a difference from now, where people just flow in and out of contributing to open source in their jobs, a lot of the time... Whereas back then it was like, "Oh no, this is what I do to stay sane on my [unintelligible 00:35:29.24]"

Yeah, very much so. It very much was that way. And part of why I've been pushing inner source so hard is because I think we'll see a time - as with democracy - where it's so much an accepted fact that we start to lose ground on what we want for ourselves... Because we want a lot of autonomy and a lot of choice, and a lot of... I mean, we're seeing it now - IBM is making everybody come back to work in the office, right? One of the things we kind of fought for was the right to work wherever the hell we happened to be, and also WHENever the hell we happened to be, right? Because as you know, Mikeal, programmers work better at night, they do. They just do. And not all, but a really large percentage. So dragging everybody in the office from 9 to 5 and asking them to code is a ridiculous request...

[00:36:21.25] Well, also a lot of projects are global; it's always night somewhere, so...

Exactly. Before the internet, we didn't have good enough communications to do global projects. That was baked into open source, that assumption that somebody was always awake.

Yeah. So moving on through this a little bit...

Yeah, you're trying to get to foundations... I apologize.

Well, it's okay. This is all great, so it doesn't matter. You've been involved in more foundations than I can count... I mean, just for the audience to be aware - you mentioned Mozilla and Apache, the Node.js Foundation you've been a part of since we started...

Yeah, the Open Hardware Association - I helped them get off the ground, the Drupal Association... I've had conversations with Ushahidi, I've spent a fair amount of time -- I've done a lot of "Let me just help you with this one little problem" with lots and lots of different foundations.

Before there was the Linux Foundation, there was something called The Open Source Developer Labs (I think that's what it was called), and I helped them out, although they were really set up so that Linus would always have an employer, because Linus took a job with a chip manufacturer at one point, and announced that he was gonna put Linux on the chip, and Intel lost their mind... So when that folded, they never ever, ever wanted to go through that nightmare again, so they and IBM funded OSDL so that Linus would always have a job...

Yeah, that's a word of warning for future BDFL projects. When you have a BDFL and a bunch of companies depend on your project, you need to be terrified that one of your competitors will eventually hire that person. It's one of the old things that LF (Linux Foundation) still does - they make sure that Linus is at an independent entity and not at one of the competitors.

Well, and to circle back on companies, I always say that there are no open source companies, there are only companies that are good to their open source employees, and if you look at Guido van Rossum, for instance, who invented Python, or Rasmus Lerdorf, who invented PHP - both of them had really, really good relationships with their employers for years and years, where they were allowed to still run their project for the best outcome for the project, and they got air cover from the company that employed them, and the company employed them because they used that project, but no one could say "Wow, Google has really had an undue influence on Python..."

Yeah... So getting back to what I actually wanted to do... So a lot of these foundations have very different contexts that they came out of. When does a project need to start a foundation or they need to go into a foundation? What are the constraints that it's under where it needs that kind of institutional support, versus the majority, the 99% of other projects that are happening in open source that just aren't at the point where they've had to get that?

They're just on GitHub somewhere, yeah. So in the early days, the foundations were another way to convince people that you were serious about open-sourcing, and you weren't gonna try to control it over much. There were a lot of attempts in the early days to leverage open source by big companies that failed, like Apple, when they came out with OS 10, that was based on the Mach kernel, which is a variant of BSD, and they made a commitment to the Mach community that they were going to continue to run an open source project that took advantage of all of the R&D that they were doing to make the Apple OS work better and better... And they did hire Jordan Hubbard and set up a really nice little playground for them outside the firewall of Apple, but they never made the step of actually doing their development, which would have been unimaginable for them, over that wall.

[00:40:25.27] They kept throwing tarballs over the wall everytime they did something clever, but unfortunately that completely [unintelligible 00:40:32.09] the people that were working on the public project and trying to solve some of the same problems... Because it'd be like, you know, I'm building a snowman - I've done the body, I've done the chest, I just did the head and I'm about to put the facial features on it... Oh, crap! Here comes in a bigger snowman from over the wall, that's gonna kill my snowman, because it's another way to solve that same problem... And Apple's tarballs are always gonna win, right? So there is a way to not do it, right?

If Apple had created a foundation and made a commitment to working within that foundation to build their product in addition to everything else, that would have been unimaginable for them, but there were a lot of projects that went "Okay, let's make it a foundation, that way anybody that wants to can come in and work hard and gain reputation in this thing and become a leader", and several of the umbrella foundations, like Apache, were set up explicitly to be transparent scrum (scrummage) grounds for new implementations of emerging standards.

After the web server was a done thing and Apache was wondering about how to be relevant, Brian was really big on "Well, let's do Java. Java is the newest thing since sliced bread; they're gonna need to do some open source, let's make it the home for Java." Sun ended up not wanting to use that home, but at the same time XML was happening, and IBM and Sun were kind of fighting over who was gonna lead the XML implementation. There was SOAP and there was something called WSDL. You don't know about WSDL anymore, because nobody uses it; everybody used SOAP. Not that SOAP was great, but at the time it was better than what there was before.

But that argument, that battle happened transparently at Apache. Anybody that cared about that cared about that could watch it happen, which is different than standards bodies, where everything happens behind closed doors by design, because none of the companies want anybody to see the political machinations they're going through to get what they want. So it was a democratization, if you will, of the de facto standards process. That could only happen at a foundation. You had to create a neutral ground where the dinosaurs could come for water, as one of my slides generally shows. But these days it's a lot different. The reasons that you might come under a foundation are different, as well.

Well, let's see... We might as well talk about Node, since both Mikeal and I work on Node. Node ended up at a foundation because we were trying to heal a fork. The community was rebelling against the trademark holder, because it was set up as a BDFL organization, and the thing that people don't understand about BDFLs is they're called "For Life" for a reason - you can't pass that baton; there's a lot of attempts to try to pass those batons, but functionally, people are at least partially organized around the personality of that individual, or at least to his creation, and they can't make the transference... So you don't get to just nominate another BDFL, and then another one when that one doesn't work out, and that had kind of happened at Node.

[00:44:13.22] There were a lot of disagreements, there was a lot of desire on the part of the community to move forward, and the trademark holder couldn't keep up with the pace of interest in change, because they hadn't resourced it to deal with the growth that was happening... Because it wasn't part of their direct line of business, it was just something they happened to own. So getting into a foundation felt like the only way that the fork could be healed and the trademark holder could feel comfortable that anarchy wasn't going to reign fundamentally, because they were wedded to a certain amount of control, so giving up the control - they felt like they needed some structure, and that's how it ended up there.

It's interesting, I feel like I'm hearing a lot about... Foundations are - and especially historically - meant to be a governance mechanism, right? And I think there's sort of a misinterpretation of foundations sometimes as the way to raise money in itself or pay a maintainer to work on a project, but it sounds like historically open source foundations as you had said earlier, are often designed to run without money, or are really meant to bring transparency or the governance aspect to a project.

Yeah, the deal about the money... I have to say, I've spoken out against pay-to-play boards, which upsets Jim Zemlin. I think everytime I say it, Jim Zemlin thinks that another kitten has died in heaven, right? Because he is genuinely trying to do the right thing; he's not a bad guy, and his conceptions of what's wrong in open source are just as valid as anybody else's.

One of the things he really saw was the inability to attract top talent because they just couldn't get paid at the same scale to work on foundation work, because the foundations didn't have that kind of budget. Now, Apache really kind of only spends money on sysadmins, and I think they do pay them pretty close to scale.

Mozilla had the same problem, actually, that Jim identified. They were losing their top talent to, say, fellow travelers - not so much competitors, just fellow travelers - like Google, because Google was the new hotness and they were sucking up all the talent in town... But Mozilla really felt like they needed to make a change in order to be able to support industry competitive salaries, and it wasn't because they didn't have enough money - because of their deal with Google they had lots of money, by most standards, and even today they have a pretty solid endowment. But nevertheless, they went through all of the work to create a tax-baring entity,, that was completely owner by

This was kind of new thinking on their part, because it was challenging the way that the tax authorities like to see things done. But they were trying to do the right thing; they were saying "No, we'll pay taxes on our profits, and we'll generate profits and that will allow us to hire people and pay them what will keep them involved with us." And it was challenged eventually by the service, and they won in that examination, so I guess that's a viable model now, although there's a whole lot of moving parts if you wanted to replicate it.

But Jim's idea was "Let me streamline fundraising" -- and he inherited OSDL, which the buy-in cost to be part of OSDL was pretty high, and it wasn't clear what you were getting for that money, so a lot of his funders were really balking at the high price. So he reimagined all of that, and part of it was "I'm gonna hire the very best people that I can to share services, and I'm going to charge discounted rates to projects that come in and need those services, but the people are gonna get paid industry standard rates because I'm gonna raise money on each of these little foundations that I spin up."

[00:48:34.26] He was aided in this quest by the fact that the whole idea of an open source foundation became controversial to the government... Because when they started out, we looked like raggle-taggle bands of hippies, right? And 10-15 years on, all of a sudden there's huge value being created in these foundations, and it's not clear who's getting taxed on that, and they're wondering if there should be some taxation on that. They're trying to figure out if they made a mistake allowing open source foundations to happen, so they stopped making new ones. And there weren't any fewer projects that wanted to get there, so all of a sudden it became very difficult... Where before it was like a two-week process (maybe four at the most) to become a non-profit in open source, all of a sudden it was taking years... And Jim was able to streamline that for people, because he and his lawyers figured out how to spin up new foundations under their umbrella.

Apache went the other way - there's only one Apache Foundation, but you can be a project under that foundation. And there are a couple of others we should probably mention. There's one that came out of the free software movement called The Software Conservancy, and there are a lot of projects that are there, and... God, Mikeal, I've just lost the fourth one. Do you remember?

There's a bunch of other ones... There's the FSF, there's the Software Freedom Law Center, there's the Eclipse maybe...

Yeah, exactly... I clearly forgot about them. Well, yes, but no... Eclipse was built for a different reason. It was originally organized around a project that IBM created, a development environment for Java, and it was an anti-competitive move, or a competitive move against Sun, because Sun had an open source project that was an IDE, and it was important to own the IDE market, I guess... So IBM came up with this other idea, and that was what Eclipse Foundation was about.

Now, you're right that Mike Milinkovich has moved it into a space where there are a lot more than just that there, and not all of it is Java anymore either, so yeah, I guess maybe they are... But it's almost like neighborhoods - a certain kind of person is a tenant at the Eclipse Foundation, versus the Software Conservancy.

Software Freedom Law Center is not actually a home for software, it's a home for legal advice...

Right, right.

...but the FSF has been, and maybe was the first foundation that accepted other people's projects. Their way or running things is very particular. You're basically trusting the Free Software Foundation to run your project forever forward. In fact, they made an assumption early on that if you put your code there, you're gonna accept whatever changes to their licensing scheme that they created, and that's a big ask, right? You're really giving up control completely. You're giving up your copyrights to the Free Software Foundation. Most of the corporates-started foundations had to split hairs there, and came up with some exotic ways to say "We want to act like the copyright holder, but you wrote this stuff, so you're also gonna have some copyrights."



So I'm trying to pull this back a little bit from the history and get it more into what these foundations actually offer to projects, so why you would wanna spin one up or join one. I think there are some huge disparities in just what these foundations do, for instance. You mentioned that Apache runs on basically no money, which is great if your project doesn't need money, but one of the reasons why people like these member organizations is because what they do with the money is they don't hire developers - you still want individual contributors to help the project, but they offer a bunch of other support, like marketing and PR that you get when you're trying to go up against other proprietary entities. That's just something that Apache doesn't offer, and if some of the projects inside of Apache have interest behind them that are sort of competing over those spaces, right?

So with the member organization, you definitely need to have a wall between the project and the board, because the board is the corporate interest, right? Like the pay-to-play board, and you can't have them just sticking their thumb in the project...

That's how Jim has it set up. There are other possible setups, right?

Yeah, well there are infinite possible setups.

He's using board membership to drive fundraising.

Right, but also there is not a connection between board membership and, for lack of a better term, project ownership. So you have this wall between the project governance and the board governance, and the board governance is mainly dealing with the institutional aspect... Whereas I think in Apache because developers come up through the process, because they're not doing all this other stuff, the board is staffed essentially by developers, and they do make certain executive decisions about the projects, right?

Well, only in extreme cases, actually. 99% of the time as appeals come to them to deal with issues, they turn it back to the project committee.

Yes, but the projects also operate under a process that is pretty strict, and the interpretation and how that process is written is owned by the board, right?

Yes, that's true, but getting them to take the kind of action that you're talking about... Like, troublesome member of my project - this person on my project is really creating a lot of problems for the whole project, and everybody's mad at them and we can't figure out how to get rid of them; the board answer would be "That's your problem."

They only get involved in really the most extreme cases, or if that person is actually on the board, they would deal with it because they are the project, right? But yeah, it can be vexing actually, the extent to which they wanna turn it back to the project, and a lot of the -- it's been very successful for projects that are focused on technology and have few political vectors, but the minute that politics enters the picture, it becomes kind of ugly.

They have a couple of times stepped in and restructured a project that they thought was otherwise healthy (had a lot of contributors), but there was some kind of poisonous aspect to the project brewing. They have put in almost like a special master, who is nominated by the board to get the project back on track... Less than 1% of their projects have had that problem, so it's definitely a last resort thing; they really don't wanna get in and do that, partly because they're all volunteers and they all have day jobs, too.

Right, right. I wanna get into the future of open source a little bit, and I think that I know how to bring us there. In the io.js days, in the fork, when we were considering where we could go, like "Could we put this into a different foundation? Could we go into Apache?" were we going to need a new, unique foundation for the healed fork, or just for io.js before the offer was kind of on the table to come back together? When we started evaluating all these places, one of the troubles that we had was that -- we were a very modern project, we were really built in this kind of GitHub era. We had all these new people coming in, and we had a very new governance process.

It was less than six months old, and we had been iterating on it a lot, and we were wildly successful, but we were not confident enough that what we had written down at that time was not going to need to evolve and change, and it definitely has had to evolve and change over the last few years... And one of the constraints that basically every other umbrella that we would consider had was that we wouldn't really own that process; we would have to change a lot of the parts of that process and the governance rules around that for the entire institution. So we weren't really able to take on the kinds of experiments that ended up kind of making this very new governance model that we have at Node.js now.

[01:00:06.25] So if we're looking at like where new projects go -- I think just in the last few months Apache said that you can even have your project on GitHub, so... If you wanna use new tools, if you wanna use new governance structures, there are constraints with some of these other foundations. And then moving away from there, if you have all of this tooling happening in the ecosystem, if you have all this new governance going on in the ecosystem, do you need to join a foundation anymore, or do we need umbrella foundations that are even less involved in the project than they are today?

Well, it's an interesting question. The Drupal Association was having some problems last year - not the problem that recently happened, but more funding problems the association was having, because they make their money from a conference, so they're subject to the vagaries of the conference business... So Jim was helping us think through how to fix that, and one of the things he was saying was "Why are you hosting your own development environment when there's GitHub?" So for him it's a decision of cost, right?

It's a liability, it's not an asset, right?

But he was unwilling to take a project on that didn't host itself on GitHub, so he's made a tooling trace as well.

There have been projects that were brought on in that time, that use non-GitHub tooling. I think that the distinction though is that they don't have tooling that they entirely have to own the maintenance and hosting of, right?

Right. Well, everybody had to do that back in the day, because SourceForge, although it existed, you couldn't really run a project on it. I think going forward, there's a general consensus that spinning up a thousand foundations is probably not gonna keep scaling, partly because it's so hard to do now, and even though that has eased a little bit, it still comes up as an issue, because it looks like value that's not being taxed; it's not the last time we're gonna have that conversation, probably.

It depends on how you define umbrella. Apache thinks it's an umbrella, the Linux Foundation also thinks it's an umbrella... Each of the Linux Foundation foundations are technically separate - they have separate by-laws and separate articles of incorporation - but they're under the Linux Foundation family, if you will.

Also, some of those individual foundations are their own umbrellas, as well. It's complicated...

Right. Jim is point out that those foundations can leave the nest anytime; they lose some things, but they might also gain some things by doing that. I think if too many of them do that and he becomes known as a foundation mill, then he may have trouble, if it turns out that the tax authorities are not wanting more foundations.

And then there's the whole question of the locus of the foundation. The vast majority of open source foundations exist in the U.S., and that's because most of the really deep pocket funders also exist in the U.S. and they get tax breaks if it's a non-profit. And also, it's relatively easy to start a non-profit in Europe, but there are different rules, like in some countries you have to be very careful with your accounting and basically spend most of the money that you earn every year.

So there's the question of whether to spin up your own foundation or not, and I think we've talked about that. Then there's also the question of "Why join an umbrella foundation now at all, especially (I think) if you're not, let's say, a Node-sized project?" What does Apache or Linux or any of the existing umbrella foundations have to offer smallish scope projects on GitHub with maybe one or two maintainers that just kind of wants to find a way to keep it going?

[01:04:09.12] Right. Well, a smaller scope project probably wouldn't do well in Apache, because there's an assumption of ongoing contributorship that isn't just you. If you are looking for additional contributors and it was sufficiently interesting, then it might make sense. The tiny projects that Jim has been raising funds to help, like the one that caused Heartbleed a couple years ago - that's an example of one and two and four-person projects that were wildly successful and became the underpinnings of the internet, but never grew to additional contributorship, and the people that started it are aging or otherwise unable to continue, and it's problematic now because the internet rests on some of these things. So should they have joined in a foundation? Maybe so...

Now there's a foundation trying to retroactively help them without them actually being part of the foundation, and it's a little bit "cat herd-ey".

I think that a middling sized project can totally just live on GitHub. I think that companies need to not create foundations to hold their IP. Microsoft did that at one point about five years ago, maybe four years ago, and there were some other companies that did it because it looks attractive, because you can create a safe harbor and put all of your liability in that foundation... But you're not fooling anybody about what you're trying to do there. Basically, what you're trying to do is have your cake and eat it too, and nobody's gonna love you for that.

When PayPal asked me if they should create a holding foundation for their open source assets, I said "Oh, hell no!" I think that's been proven as a bad answer.

But for an individual project, I think you start on GitHub, you see how much traction you can gain... If you get to the size where big, deep pockets are starting to come calling, you're probably gonna find yourself pushed into a foundation, if only because they're more comfortable that the legal procedures are somewhat regularized that way.

A lot of the way that we do things in open source comes down to Sun legal and IBM legal coming up with things that made them comfortable. Most of these licenses rest on copyright law, and copyright law is a good choice because they're almost immediate remedies if you can find infringement; you can stop software from shipping if you find that, where a patent-based complaint can go on for months or years, and the remedy might just be "I'm gonna make you show your patents to these people." It's just not the same as "You can't sell it anymore."

So copyright law is what they rest on, but U.S. copyright law, if you have to go to court, you have to assemble all of the people who have any claim to copyright and get them to - at least the majority of them - agree to your line of defense, and that's not gonna be easy if you haven't already aggregated the copyrights. That's why Apache does copyright aggregation, because IBM wanted to play there; they paid for all the legal work to set up Apache, and of course, they set it up to meet their needs.

Modern projects are asking whether things like a contributor agreement, which creates the copyright aggregation, is too much of a barrier to entry, because they're optimizing for contribution instead of optimizing for long-term legal viability. But you've gotta remember that IBM famously stuck through a lawsuit that they really probably were the only house at the time that had the resources to get through it... There was a challenge to Linux - and actually kind of to UNIX, but mostly to Linux - called the SCO lawsuit, where a single company was claiming that they owned a bunch of stuff and they were gonna sue everybody else for using their ideas.

[01:08:21.07] If you know about the UNIX wars, establishing who owned UNIX is a pretty tricky thing to do, but IBM, instead of settling that suit, instead of doing anything else, actually saw it all the way to its bitter end - at least we think it's done - and it was proven that SCO didn't have a claim, and that Linux is safe to use. That kind of legal work is only possible if you can actually pay to have the provenance checked, or you've already aggregated the copyrights.

So they actually spent an enormous amount of money on figuring out exactly who owned all the parts of UNIX and Linux and all the other IX's and making it clear that SCO's claim was spurious, right?

To bring us back in push towards wrapping up a little bit - we talked a bit about why it's now just more important than ever to increase adoption and then get contributors, right? And I think one of the things that you're seeing in these news communities as pushback is that what they are feeling and what they really understand is that they need to retain contributors, and any barrier to that really has to meet a pretty high bar of scrutiny.

Well, we don't know yet what the legal challenges to all of that are gonna be; it's gonna be interesting to see.

Right, but that's such a hundredth-order problem from the problems that they're dealing with, right? And in particular if you're talking about establishing who wrote the work with these utilities, who would need them from day one. And in reality, we have them with zero of day one software, right? Nobody starts with the CLA anymore. So it's really hard for a lot of these communities to get their head around that this is such an -- not that this isn't a real legal argument or that this isn't going to be a real challenge, but that it's important enough to sacrifice their short-term sustainability... For if they succeed and they become a legal problem for IBM, then why do they care, right?

Well, there are a couple of really famous projects that are not aggregated, and one of them was a challenge to J2EE (Java Enterprise Edition), and that software -- the guy (Marc Fleury was his name) was an ex-Sun employee, and he was very concerned that he was gonna get sued personally, and his lawyer told him not to aggregate copyrights, because it was the only strategy that would confound a lawsuit because there was no target.

This was the Linux model for a long time too, right?

Well, they didn't do it intentionally; they did it because they thought it was gonna be a barrier to contribution, I think... Or they just didn't think of it. I think initially it wasn't a high-order issue. The whole contribution question didn't really come into being until about the time that Mozilla pushed out their project or Apache was started. They were started within a couple of years of each other and it was very much on everybody's mind at that point. And it might have just been as simple as IBM, the largest IP holder in the world for software going "Wow, this is a whole new model. We've gotta get our hands on this..." - I don't know. But I do know that it has been the case that it's been useful to have some of that information on projects as the legal challenges come in.

[01:12:00.12] I mean, I'm immensely encouraged because there's now gonna be (it seems) a formal legal challenge to the GPL. We just found out that GPL was a good enough contract that they were willing to let it be tried in court in the U.S., which is -- every other time in the U.S. that that's happened, it's been settled out of court, so that's kind of exciting.

So we're thinking about this from the point of view of these open source projects on a somewhat individual basis, and I think that we have an assumption that over time it gets more adopted and it becomes more of a target and so on, but if you actually take a modern application and work through it and look at all of the different software that created this project and what its legal standing is, the idea that you would be able to enforce any of these mechanisms for even half of the stack is impossible, right? We moved to this model of all of these different small projects making such a huge small network of dependencies that it's very hard for a lot of individual project maintainers to see what use is it actually going to be to a person with an application being threatened with a legal challenge that "I did this thing" that it's going to put off a lot of my contributors, right?

Well, but then you see people who are getting sued for stealing trade secrets and stuff between industries, right? That stuff expresses itself in open source, too, so... It's a thornier problem than you think, but I understand the reordering of the issues based on what feels like the most important thing is probably appropriate, but it may be a bit painful down the line, that's all I'm saying. We just don't know yet. Is it gonna be a fair tradeoff? Well, there's so many projects; certainly they're not all going to simultaneously come under any kind of legal action, at least hopefully not... So it probably is worth the risk, but it is a calculated risk, that's all I'm saying.

I think that contributors to projects like Node realize that, but again, when I said at the beginning "Money changes everything" - most of this stuff came up around the money, not around the contribution, right? So I think as with everything, if you follow the money, you can understand the motivations for things, so...

Yeah. I think that people tend to think of money as being directly flown into the project, but money is flying around all the time, and if you don't think about how it's influencing stuff, it'll just sneak up on you, right?

Yeah, and it takes a lot of vigilance to keep that from happening. Keeping the same people involved -- so the BDFL model I think is pretty difficult to sustain for any length of time, because people get old, and you can't pass on that right... I mean, you really can't; we've seen it tried many times and it just doesn't work.

They get bored quicker than they get old, but yeah...

Right. Well, there's been some hacks on it. The Debian people vote in a leader every year, which is kind of an interesting thought... Because there was a BDFL, but then there's also a Debian leader. The BDFL is gone, but he's also not been involved for a really long time.

So the consensus model seems like it's winning just because there's no way to live long enough to keep the BDFL thing going... Although some of the most powerful software is still BDFL software.

All of these -- you notice that there's two ways to go always in open source, or in this whole conversation? There's free software and open, there's permissive and inherited, there's BDFL and consensus, there's foundation and not foundation... It's really interesting how there's always two choices, and just like seeds in a forest, both ways work for somebody some percentage of the time. Growth happens out of all of those possible avenues.

[01:16:08.10] And we've gotta remember - 20 years seems like a long time; it seems like a long time to me, but really, it's just a blip. There's gonna be a lot more time that people try on these different structures.

There's a bunch of people who think that open source is doomed because software will change in a way that means that it isn't created this way anymore and it doesn't matter, but I still think that the moment in history that we took advantage of to create it and bring it this far - it ws worth doing, because... I think it describes the ideal conditions for creating the best possible software. It's pretty clear that the ideal conditions -- Apple is like the exception that proves the rule. What it costs them to do things the way they do them is kind of crazy, and I think the reason that they still exist... I mean, Microsoft is having to change the way they do things now to become more open. Apple continues to buck that trend, but I think the only reason that they can do that is that they've got the monopoly of the hardware and the software going for them, and a fandom following that will eventually erode. It has to. That's what happens.

I'm so happy to have spent the time that I've spent supporting this work, and trying to connect the dots where it looked like a dot needed connecting, and I've really had a good time talking to you guys about it, too. I don't know if it's unintelligible still, or if it helps to hear these stories...

No, it's been perfect. And that was kind of a perfect wrap-up as well.

Okay, I do what I can.

This has been great, Danese. Thanks for coming on.

Yeah, thanks for chatting with us.

Of course, of course.


Our transcripts are open source on GitHub. Improvements are welcome. 💚

0:00 / 0:00