Mm-hm. So why don’t I start with the history of the program, because I think that’s kind of a good way to understand how MOSS has evolved over time, and why we have kind of structured the program the way that we did.
So the program first started in 2015, and 2015 was kind of a big transitional moment for Mozilla in general, and some of the questions Mozilla as an organization was asking itself was “How do we give back to our roots, which are in the open source community?” So it was kind of this program that came together with a very small team; Mitchell Baker, who is Mozilla’s Executive Chairwoman, was very interested in this question, and she worked very closely with Gervase Markham, who was an engineer among other things at Mozilla, as well as Jane Finette, who was Mitchell’s Chief of Staff. And they just kind of put their heads together and came up with this idea for an awards program.
Mitchell has a certain amount of kind of discretionary funding that’s available to her, as is the case for executives of a lot of organizations, and she decided to use a chunk of that funding to fund awards in the open source space. So something that you hinted at is there’s a lot of foundations out there, there is a good number of them that support open source technology, but the things that they support are not usually technical development; they might support going to a conference, or dissemination of information, or all these kind of tangential activities… But there’s not that kind of core support out there for actually doing the actual development work. That was the kind of gap and Mitchell and Gervase and Jane were seeking to fill - to take a chunk of money, offer it up for folks who needed core support to build and maintain their projects, and to see what kind of impact that would have on the open source ecosystem.
[00:07:52.11] The first iteration of MOSS really began with us looking at and wanting to support the dependencies that we rely on. For Mozilla Technologies, especially a project as big as Firefox, you can imagine there are so many dependencies that we rely on, so many libraries and other pieces of code, ranging from big to small, and any one of those things could be a core dependency for us. So the original vision of MOSS was to kind of take a chunk of money and try to support those kinds of projects, and to be a steward of the ecosystem that [unintelligible 00:08:23.25] supported us in that way.
So that program existed in that kind of way for about a year, and in late 2015, early 2016, the focus shifted a little bit as Gervase and Mitchell and the other folks who were working on the project realized that there are a lot of other people in the ecosystem who are supporting and advancing Mozilla’s mission every single day, but who are maybe not building technologies that are dependencies for us in that same kind of way necessarily. So an additional chunk of funding was put into MOSS under the Track 2 part of the program, which is called Mission Partners. The original part of the program was turned into Track 1, which is what we call Foundational Technology.
Track 1 is for dependencies, tools that we use at Mozilla to get the job done. The idea behind Track 2 was “Let’s offer similar funding to any open source project that aligns broadly with Mozilla’s mission, that we think is kind of advancing the causes that we care about in the world.”
And then the last major track that came online was Track 3 in 2016, and that’s our Secure Open Source (SOS) Track. 2016 - it was shortly after the Heartbleed Bug, and there were some big open source security vulnerabilities that had been revealed that got a lot of folks at Mozilla talking about how we might address those kinds of things. For Mozilla, or for even bigger for-profit companies like Facebook or Google, mechanisms like bug bounties worked pretty well, because if you had the infrastructure to find bugs and to patch bugs, all you really need is somebody to report them, and then you can solve those problems yourselves. But of course, it’s not really the case for a lot of open source projects, especially small ones, especially ones that are kind of maintained by a core group of volunteers… So the idea behind Track 3 was, similarly to how we had provided funding to Track 1 and Track 2, let’s provide the money for audits and remediation for widely-used open source technologies.
Track 3 is a bit more hands-on than the other tracks, in the sense that Mozilla does play a matchmaker role as well. We have a bunch of folks that we like to work with as outside contractors for things like audits and remediation, and so if you know an open source project that is in need of an audit, we will connect them with the right folks to undertake that work. And if they find anything over the course of that audit, we will then also pay for the remediation, to make sure that the bugs are fixed.
One of the cool stories on the SOS Track is shortly after the Track was founded - I think it was in 2016, we gave an award to libjpeg-turbo, and we had funded a security audit for that library. In the course of doing that audit, two bugs were discovered, and then under a closer inspection, it turned out those bugs were not bugs in libjpeg-turbo, they were bugs in the underlying jpeg standard. So if you think about critical infrastructure for basically the entire internet, that’s about as serious as it gets, and those are bugs that maybe would never have been discovered.
So those are the kinds of things that really get us excited. I’m not sure that there are a lot of other programs out there in the world that would fund a security audit in that particular case.