06 Open Source Licenses
[Nehemiah Dacres](https://twitter.com/dacresni), Open Source advocate and Captain of the OpenSTL Code for America joins us for a chat about Open Source licenses. We'll learn about their varying types as well as why they can be useful for your projects.<br><br>### Resources and Shoutouts:<br>- [OpenSTL](http://openstl.org/)<br>- [Data.gov](https://www.data.gov/)<br>- [Code.gov](https://code.gov/)<br>- [Technology Review Algorithms are actually making inequality worse](https://www.technologyreview.com/s/610026/algorithms-are-making-american-inequality-worse/)<br>- [Open Source Initiative](https://opensource.org/licenses/category)<br>- [The Cathedral and the Bazaar](http://www.catb.org/esr/writings/cathedral-bazaar/)<br><br>##### Music Credit: [Tumbleweeds by Monkey Warhol](http://freemusicarchive.org/music/Monkey_Warhol/Lonely_Hearts_Challenge/Monkey_Warhol_-_Tumbleweeds)
Top Keywords
- source 0.016
- open source 0.015
- license 0.014
- software 0.014
- open 0.013
- code 0.011
- project 0.010
- brigade 0.009
- government 0.007
- licenses 0.006
- model 0.006
- firefox 0.004
Transcript
Hello. I'm Ryan Cook, and this is Civic Tech Chat, a podcast about the civic technology movement. We seek to harness the power technology has to improve the delivery of public services to people everywhere. Today, we'll be talking with Nehemiah Dacris, brigade captain of OpenSTL, the Code for America brigade in Saint Louis. Nehemiah is also a passionate advocate for open source code and the licenses that go along with it. So let's go ahead and join him for the conversation. Nehemiah, thank you so much for joining us on the program today to talk a bit about open source licensing. Could you introduce yourself to our listeners and tell us a bit about your background?
Sure. So my name is Nehemiah Dekris. I am the co captain for the St. Louis Brigade, the OpenSTL, we call we call ourselves. And I got involved with, first open source software, you know, fell in love with Linux and and the concept of building your own box and in all the all the, the whole community aspect of open source software. And I thought that it was a great idea to have that applied to government software. So I found out about, Code for America for a podcast. That escapes me. I don't know what we can do with the change log or plus weekly. And, they told they told me about the National Day of Civic Hacking. And so I I found I joined that hack night, the hackathon, and then I discovered we had a brigade here for a while now. So I joined the brigade. Then after a couple of years, I got elected captain.
Nice. It it sounds like you've gone through quite a journey there in first getting acquainted through a a hackathon event to then getting an understanding of that brigade there and now becoming a leader yourself. Could you tell us a bit about what it's like to be a brigade captain of a, Good for America brigade?
Well, it depends on what your goals are for the brigade, and that you have to understand that that's what you want the brigade to do, and then that's what the brigade wants to do. I had to understand how to draw people in and a bit of that for Saint Louis was a location. So I know you're from, what, Chi Hapneid. Right?
Oh, what? Open Uptown.
Open Uptown. Right. Right. Right. Part of my task has been expanding and and getting more people involved in the brigade, but also getting more consistently involved. And so I've, I've learned those are two separate tasks, and, I've had to do different things to get them both done. Getting a project, a solid project that we could all believe in was one thing to get people, I guess, more regularly involved in the brigade. And then I think maybe the location and better publication helped with getting more people into the brigade to know about it and end time.
That makes a lot of sense. I think it's valuable that you have that sort of insight and experience, and no doubt your brigade is able to benefit from that. Now let's go ahead and hop into our main topic for this episode, which is licensing and open source. Could you open us up with, I guess, your your initial thoughts on the topic?
So, I mean, the reason why I am particularly interested in the the issue of licensing is because the license you choose actually will sort of affect how your project is perceived in some case and how your project is adopted because the the level of permissiveness of your license will actually affect that. And, different licenses lend themselves different kinds of projects. And so that it also leads into, like, how you monetize it, how you make it more sustainable, all these things, how you keep it from dying on the vine. And so that's that's why I found this subject important to be discussed.
Absolutely. And for the the sake of the listeners out there that maybe aren't, familiar with the term open source, oftentimes, what is meant by that term is the idea of releasing product code to where it's accessible and available, generally under some sort of license, which we'll cover the specific types as we go along here. But perhaps the important part about that is that transparency, especially if you're working on a civic technology project. Could you talk to us a bit about your your thoughts on the importance of transparency with, these open source projects?
So I think that that government projects particularly lend themselves to being open source because they were government funded taxpayer dollars, and they are meant to serve public. So, I mean, it's one thing to be a project that, like, the five or 10 people in a government office are going to use, but it's a whole another thing to be a project that's going to serve citizens and then be developed by remote contractors that don't necessarily have any contact with that citizenry. Right? Mhmm. So, I mean, you can have an agile project set up and a product owner that is in contact with them. But, you know, the whole concept of the they call civic user testing, I think you talked about that in your last podcast. Yeah? In your last episode. So. And, that whole thing just it's just just an engagement of users by your developers, a a direct engagement engagement of users by the the, by the community of people who are writing the software in the first place. And so, it actually lends itself to just having the software in part be developed by the community. See, now you can get instead of just being the test the user acceptance testers or or, you know, having a a focus group kind of thing, you have people from all over your community suggesting not just features, but also, development goals. Right? Mhmm. And then, you know, you need this particular part to be abstracted out to be an API, or, this part here could use a particular library that is open source and maintained so that you're not completely responsible for the development of that particular feature. Right? So this is why an open source so this is why, government projects in particular lend themselves to being open source.
That makes a lot of sense. What I'm hearing from you there is there seems to be a democratic element to this model to where you're empowering folks that maybe would've been locked out of the process in a proprietary setup where you had, say, a contractor coming in and building some software and giving you a the government a black box or a nonprofit a black box. Whereas with what you're describing, with it being open like that, folks from the community, folks perhaps even that the software is for, can have a say and can have input into what the end product turns into.
Am I hearing you correctly in in restating it that way? Well, yes. It's, that's exactly right. Government project almost necessitates transparency. Right? Because it's government funded, and that's basically part of the whole government two .0 movement in the first place. Right? Mhmm. I mean, there was gov, there was a data.gov, right, so that we could, you know, share the data that we have. We could democratize data that we've funded the collection of. Right? But then there's now there's code.gov, and that democratizes and and makes available code that the government tends to write and sometimes, rewrite. Right? It would it would encourage reuse of it. It encourages, auditing of it by, citizens. Government is very often government projects are just underfunded, and you can get you know, with the Code for America project is in part to get more qualified people into working for government, right, and and to to sacrifice I guess, to take on a government salary for the purposes of making the world of a you know, their their city or their their own local government a better place. Right? Mhmm. But we could also get some of that insight from just better auditors and more eyes. Or as as, as ESR once said, all bugs are shallow with a under a thousand eyes. Under enough eyes, someone someone's bound to catch the really glaring errors.
I I think you raise a a very good point mentioning that many eyes gives a level of scrutiny that is, ends up being positive for a software project like that. Also, it occurs to me that our prolific use of algorithms in society is something where transparency would have a a lot of impact or consequences for. For example, I recall seeing a piece in the New York Times a while back that was really looking into the use of algorithms to try to assess risk in sentencing as well as things like setting bail. Do you have any thoughts on kind of algorithms and how they go into our society and the role that you feel transparency should play?
Oh, yeah. Oh, yeah. So for one, I I just found that quote. It it was Linus, actually, which must be Linus Turbulb, saying, you know, given enough eyeballs, all bugs are shallow. Right? Absolutely. That that leads right into my answer here that, like, the really the right eyeballs. Right? So so for example, this this particular, article is probably specifically talking about the sentencing, the sentencing software where where, judge is given the guidance on sentencing by this algorithm that's taking all these risk accounts, these recidivist risks, I think, was were the metrics. Right? Yes. You know, sure. Machines are, have a better well, an algorithm would have a better sense of predicting oh, sorry. Assessing risk than a human. Right? Because humans are notoriously awful at this. I think there's an entire book about it, of how awful humans are at assessing risk. But then the data and the metrics that the algorithms are based on, that they they take into account aren't always transparent. And in that particular case, they weren't transparent. And, well, under the right scrutiny, we got someone to to realize that the govern that the, that the algorithm was flawed in a particularly egregious way. There's an entire book about how algorithms can sometimes, actually because of the data that they're based on and the assumptions that the developers made would actually compound the inequality that they were actually meant to reduce. There's an entire, you know, article in the technology review called, algorithms are actually making inequality worse. Right? Mhmm. And so in which we are actually they ought to maintain and accelerating the, societal inequalities that we you're getting because we're not actually engineering for the right outcomes. You know, they say garbage in, garbage out. Yeah. If the data that you're basing it on is bad, then you're gonna get a bad outcome. That's why we need transparency to get the right eyeballs or diversity of eyeballs all coming from different, you know, disciplines and backgrounds so that we get a more equitable outcome in the first place.
Indeed. Especially I mean, ultimately, the algorithms themselves are crafted by humans even if the machine is what runs them. So if the process for creating those algorithms isn't open and isn't up to scrutiny, that is, I think, as you pointed out, how you end up in situations where the algorithm itself can exacerbate the problem that perhaps it was attempting to solve. And I think this gives us a good opportunity to hop into some more specific information about open source licenses as opposed to our discussion so far about openness in general. Right. And there are several types of open source licenses. Some of them are more permissive. Some of them are friendly for patents. Some of them are kind of copy left where they have some additional requirements. Could you give us, I guess, like, the brief
overview of of some of that space as you see it? The actual open source initiative web site has a breakdown of the various open source licenses and their values and their differences. Right? So Right. There is there are permissive licenses, and these are sort of the the older the the eldest licenses. Right? So early in the days in the early days of of computing, there were just communities that developed software productization of software development like there is now. Right? And the productization of of computers, as a matter of fact. Right? There were just people tinkering with things, and they thought, oh, this is cool. It's like it was like cooking. Right? You didn't patent your recipe or you didn't copyright your recipe. You just kind of this tastes good. You gotta come try this. Right? And so that so when software development became more commercial, they realized they had to create a license for this in the academic space. And so that's why the first license is probably be the MIT license. Right? And that's almost like the unlicensed. You know, when when they first came up with I I guess, DEC actually had some of the first source of open source policies. DEC, the, man, Digital Equipment Corporation. Wow. That was old. That takes me back. The DEC Corporation and their their employees had some of the first open source policies around sharing code. But the first, like, license that was ratified into, in response to, well, licensing code would be MIT or Massachusetts Institute of Technology. Mhmm. And they came up with this license. It was very simple. Three clauses. You just gotta give us credit for, the the code you gotta have. You have to just the the the release of liability. Right? This code is provided as is, and you gotta have a line in your in your source, in your license. Any derivation of this code would have this line in it saying the same thing, that this came from us, from whoever it came from. And so that was one of the first ones. And then later on, you'd get BSD, the Berkeley Systems distribution of what was UNIX at the time would give or come up with this other license that that was they called it the three the BSD three cloth license. Similar concept. Right? Mostly just, this code is free, so you, you know, we're not charging you for this code. You can't sue us for this code, and, oh, yeah. Please, you know, pass it on. But it it's not a requirement. Right? Right. So I I forget who the authors of that license was or those licenses were, but later on, we would get a fellow by the name of Richard m Stallman. Mhmm. He wrote a license called the GNU, the general public license, so GNU public license. And it was a part of his GNU project to which to ensure that this that the projects that were written under this license weren't just given free of charge, but also required developers to release the license sorry, to release the source code with the product. So as to encourage sharing, to encourage reuse, and to discourage, basically, this defensiveness. It it was basically, he had this ultimate goal of making all software open source. So it would you would have to be that open source software was the best way to develop it, in which that was the argument. Right? Open source is the best way to develop software, period. And so the more people developing onto this license, the more people would try to develop open source software. And that that's and that's the inception of this so called copy left license. So, I mean, while RMS wrote the first, you know, GNU public license, there were other licenses that would fit this category, what we would call copy left. And so, thus, the open source initiative was founded by a guy named Bruce Perins, and that was this very simple notion of alright. If if you're gonna have a license, let's call itself open source. It's gotta have these things. The code has to be released and readily available for any upon request for anyone who consumes the software and which was, of course, only enabled by the World Wide Web. Right? And you gotta have this requirement in the license itself that any derivations from the software also be under the same license so that it would spread. And and people don't like this characterization, but they called it like a virus, which sounds a little too much like the way Microsoft characterized open source as a cancer. You know? Look who's
look who's writing their own Linux distro now. Right? Oh, yeah. That's fair. I I guess what they really mean by that is, I guess, the vector of how it spreads. Like, it spreads quickly. Yeah. And and and as you mentioned, like, the the key components to that is indeed that any works that derive from it must also share that license and means that they they also need to share their source code, which is a pretty key difference between that and say the other licenses you mentioned, like the MIT license, which while they facilitate the sharing of source code, they don't require a project coming in that are using those libraries necessarily to use the exact same license. Exactly. I feel like that's a very important distinction.
Yes.
Now I if I understand also, as I was kind of looking into this topic, these licenses do not necessarily prevent someone from taking commercial interest while they're also releasing their code under these licenses. Is is that true?
Yes. So, Richard Stallman was very much adamant that we not disable someone from using the software license, and monetizing it. He wants people to actually do it. He's like, okay. We don't want you to charge for the software, but it doesn't mean you can't make money off the software. Right? He's he's not a he wasn't a socialist. Right? We're not we're not we're not comments here. Okay? Come on. We want you to be able to survive writing software. Right? In addition, we don't want people who use the software to then require to be required to, like, release the what they make with the software under the same license too. That wasn't that was not a goal. Right? So, like, there's a open source, like, game development project called Blender sorry, an open source three d editor rather. Right? And you can make movies in it, and you can extend it, but, like, we it's sent to GPL. If you make any if you make any plugins for it, those would be under the GPL. But if you make a movie or a video game off of it, that game would not have to be under the GPL. It would not. Right? That movie, you could charge for that movie. Right? And, thus, we have movies like Tears of Steel and Elephant's Dream.
Right. I guess, what's happening there is in the case of the plug in, it is a work that derives using the source code itself to create other code. Whereas a creative work that isn't a programming project that's associated with the Blender project is more of, like, a creation that is possible because of Blender. It am I finding the right distinction there as to why that happens?
Exactly. So that's where, you know, there's a whole discussion about Linux, drivers and whether or not they can be closed source. And and I think they violate they I don't think that they violate the GPL when you, like, run your, when your Android tablet is running NVIDIA drivers. Right? Your, your NVIDIA shield is running a version of Linux, but that's not violating the GPL. But that's because there's a stable API that it's looking at. It's not looking directly at the code. But, really, open source is the best way to do that because now you're not the only person developing that software.
To, I guess, kind of summarize where where we're at so far as far as the types of licenses, it seems to me if you're about to start a project, you really have a couple of concerns you're looking at. If you're just wanting to share some code out there so that it can be used in a very simple easy way, you would probably go after something that's more permissive like the MIT license or the unlicensed. There's not a lot of overhead. It's very straightforward. It gives a lot of freedom to whoever is using your code at that point. If you're someone who's worried about a patent kind of thing with the project, where they wanna maybe share the source code, but they have some sort of design or methodology that they have a patent pending for or a patent that exists for, It seems to me that then you would go after something like the, Apache style license. Whereas, if you're interested in kind of sharing your code, but also ensuring that it's used in a way that allows for further sharing, that's where you would go into that kind of GPL or other copy left, licensing. Very nice. Am I hearing that correctly?
Yes. Yes. And then I I'd like to actually point this out. So but I've noticed in working for government, the government kinda loves the Apache two license. So if you really if you really want your project to be adopted by the government, If you go to code.gov, I bet you'll notice, like, just about everything is under the Apache two.
That's really interesting. Is is there something Apache two that draws them to it, or is it just, I guess, a behavior that it organically occurred over
time? I think it's a combination. Like, at one point, like, the Apache two license was, I bet it was actually the Apache project itself, the web server. Right? I think that was the first thing that the government ever adopted. And then it was like, woah. In addition to that, it has these provisions about patents. I mean, the government can't patent anything if I'm not mistaken. But the corporations who that the government contracts with might, but they're not gonna let those patents leak into the sub the source code.
So Oh, that makes a lot of sense. I I would imagine the government wouldn't want to risk putting the requirements that might come with something like GPL on a on a contractor that's coming in. That that might make it considerably more difficult to get responses to their request for proposals.
That's really how I feel. That's really what I feel about it. I mean, look at some of the things that have come out of the government that have gone open source. There's, you know, keyhole markup language. A lot of with Google a lot of Google Maps is based on government code.
That's a good point. Came out. You know? Looking at it from this a similar perspective, is it safe to say that in your in your experience with the Brigadier, the majority of your products take up that license, or is there another kind of countervailing movement within that space with the volunteers that you've interacted with?
So, I mean, a lot of my volunteers aren't really concerned about the license. That's more of, you know, what I am concerned about. So when I have hackathons, I just tell them you know, I give them this sort of rundown of of oh, the similar rundown that you gave. Right? You might wanna put it if you want other people to use this and monetize this code, they might have a better time doing it with the the BSD license. And then if you if they really don't care, then put it under MIT MIT because public domain is is gonna scare people away. If you don't care, but you think that your users might, then, yeah, the public domain is not a license. And then finally, yeah, if you do care and if you want it to be shared like you said, then, yeah, GPO will probably work best.
So I think this is a a great time for us to go ahead and pivot into the next, part of our discussion about these licenses. And that's a discussion about how one monetizes an open source project within these frameworks. There's a number of different models that exist, to that end, of course. You have companies like Red Hat, which do support services. There's widget frosting, there's creating software as a service offerings, there's advertising partnerships, and even paid features. So let's go ahead and start with, I guess, the top, and that's the the the idea of selling support services, which is the Red Hat model. What's your opinion, of that model as a way to monetize open source?
So I think this is probably the best way to keep project sustainable independent from, say, infinite grants. Right? I mean, if if you can you can get a a dev and a product and a, maintenance team to, like, adopt this code just beyond the government staff. But that really happens in something like a local government. It's unfortunate, but those are typically underfunded. And so these tech budgets have cut to the bone. So it it it's almost advantageous for a community to to maintain a project and then, like, yeah, get grants for just the hardware alone or, like, the hosting alone and then have people maintaining it. And so you could sell software services as sort of a a very transparent, way to monetize a project. If you're not talking about GovTech, then if you're selling it to the government, like, if all of a sudden you're the vendor now, then you can maintain the transparency of your code without that interfering with your profit model. So, yeah, now you're not just selling to one government. You're selling to multiple governments, and you're supporting it. And governments like not having to support the code themselves. Right? Now they're not on the on the hook for it, and the code and the project remains open source, and the product remains transparent. Mhmm. Now the profit model isn't interfering with your, the quality of the project. I mean, one thing that that makes me suspicious of profit motive is, like, anytime someone has an opportunity to choose profit over quality, they're gonna choose profit, like, 99% of the time.
Sure. Although, I suppose with the support model, your profit motive is a little different. Exactly. It it's not it it actually the quality of your code reduces your cost of delivery at that point since what your focus is on is providing that support, which with an enterprise environment like a government, I would imagine is something that's incredibly important. In fact Yeah. There may even be situations where it's required in order for that piece of software to be built for them or for them to purchase it, however that goes down. And it's definitely not an area that isn't without success. We we've brought up Red Hat up a couple of times. Their success is kind of interesting. They're a a billion dollar company and have managed to, take over about 70% of Linux spending as of February. Wow. And it seems to me that a lot of that has to do with reach and that exposure and then backing it up in those enterprise environments with that blanket of, hey. We're here to support you. I I guess it it sounds to me like you're kind of advocating for a similar approach with those that want to kind of step into government contracting from that civic tech angle.
Yep. They're like the granddaddy of open open source companies. And and I agree. Yeah. That's, that's seems to be my favorite model. I mean, the other example is I can think of what would be like well, okay. My next favorite model, I think you mentioned, is a a software as a service offering. Right? So WordPress and GitHub sorry. GitLab. Excuse me. GitLab is actually an open source project. WordPress, you know, they they what they do is they host it as a soft as a service. Right? And you can spin up your own instance of it if you really want to. Like, you have the requirements that you're behind a firewall, right, which is definitely the GitLab case. Right? Or, you just want to to have the software like, you want to be able to install your own plugins without having to pay wordpress.com quite as much money. Right? Then then you want WordPress, or you want the word I call it the WordPress model. I'm not sure what these models are called. Oh, software as a service. Right. That's that model.
I I I think that's a really good point. The software as a service or or SaaS model would definitely provide the ability to get really regular revenue, something that is dependable. As, you know, in in these situations, what you would have is, like, a subscription based business model. And that seems to be a thing that's desired in software these days. I've, myself worked at a a private enterprise that spent a great deal of time, effort, and resources to shift over from that one time purchase idea to this SaaS model themselves. But the idea of being able to take transparent software and profit from it by making it so that you're the provider that takes away time and effort from someone implementing it, seems like a pretty positive way to go about it. Oh, yeah. Oh, yeah. It's pretty awesome. And, another, model that we mentioned as we were going through there was the, widget frosting. Could you describe that for us on a little detail?
So that the phrase, witch frosting, actually comes from, Eric S. Raymond's The Cathedral and the Bazaar. You sell a piece of hardware and then just make the software that runs on that hardware open source. Andrew is one example. Technically, macOS would be another if they ever if they were good community managers. CUPS is actually a better example from Apple. As CUPS common Unix printer service is running on many printers. Like, Cuyp's and and Samba, those are running on, like, just about every printer. And, like, the only possible downside is when you're just a bad, bad maintainer and you don't keep your you don't have a pathway to get your devices up to date. And this is the only flaw, I think, in this model because, well, Android has this problem, actually, and so do printers. Like, HP tends to keep up with it, but I I you'll hear occasionally, that there is a news update. All the printers are are vulnerable to this exploit. And then, you know, Android, you know, the all Android phones by this manufacturer are vulnerable to this update. Because now you've put the power of sorry, the responsibility of of maintaining software updates and then software security and the testing and stability. Well, the the testing responsibility, now that's on the hardware manufacturer.
Okay. That that makes a lot of sense. Is this a fairly so you mentioned the the Android example. Is this a fairly common practice outside of Android, or is it pretty unique to that ecosystem?
The webOS is one that comes to mind, and and ships actually on several TVs and several hardware manufacturers decided. And this is where it this is where it shines. Right? Why am I spending all this effort just failing miserably at writing software for my widget when I could just use this? And so, like, Sony is just, like, notoriously bad at shipping at, shipping software. The software on your televisions, just television OSs. Like, just what we listen to The Verge at CES, the the the like, most of the time they spend is just dumping on TV OSs and their interfaces and how bad they are. And they were just, like, happy last year because most of them either went with Google TV or WebOS. LG went with WebOS, and it's on their watches. And and it's it's open source software, and they just they just stop failing at it. It's like, oh, we'll just use this. It's actually really good. And then you probably if you have a Sony TV, if it's of a certain age, it's probably a Bravia TV. And that's that's that's Sony's own homespun thing. If I'm not mistaken, it's based on a bit of open source technology, but no one else but Sony used it. So now they're running Google TV, or was it Android TV? I forget.
Yeah. I I forget which one that is. But from how you're describing this, I can certainly see the appeal of trying to wrap up open soft open source software
into what are fundamentally hardware products like that. We can kinda step forward here into
most end users perhaps aren't aware of of as much. There's a little bit more invisible to your user experience. For example, like, one thing that pops out that uses this to me would be Mozilla Firefox. They make deals with search engines, as far as how they'll be featured and collect some money that way. And that allows them to to fund what they're doing in a way that isn't super intrusive. Another example of this might be the plug in Adblock Plus, which, even I myself use with with Firefox. But the idea is that, you know, it blocks ads for you. But what many probably don't know is that there's a white list feature. So, like, really what their point is not so much to block all the ads, but to make it so that the ads you get are tolerable. You know, they meet a certain level of standards. Right. And large entities can pay a fee to help get you know, become on that white list, while other smaller entities can apply for it for free. I I think in my research, like, 90% of the interactions for getting on that white list are done for free. But to circle back back around, like, ultimately, like, what these things are doing is they're they're open source projects that are using some attachment to advertising in order to fund what they're doing. It what what is your opinion on that practice?
Well, then, I think the only problem the only potential flaw or fault in that one in that model would be transparency. See, my, Mozilla Firefox is a very popular project, and everyone knows its name. But they're not necessarily transparent about your relationship with that company. I mean, they're not straight up Facebook. Right? The which was actually kind of opaque if you if you don't realize that you had a product. But, like, that's the problem with when you're when you're actually monetizing attention is, you know, the more people use Firefox, I think all of the various search engines have a Firefox plug in, and then they have to pay Firefox to for for every per every time someone uses a search bar and the search bar has been set to them. So Firefox doesn't just get money money
from Amazon money from Amazon. I think they even have a plug in for that to search their products and whatnot.
Right. Sometimes Firefox has not been the most transparent about their relationship with their their vendors. So or sorry. They would their sponsors, I should call it. So that's that's the only problem. It it so if you're going to do this, just do a good job at being transparent about what your relationship what the customer's relationship with your company is.
That that's a good point. And there have been controversies to this end. In fact, I vaguely recall a problem that Canonical had with Ubuntu to this end that was, particularly egregious where I believe they turned on the Amazon integration by default. So there was, like, some telemetry data I think they shared with Amazon Yes. Like the like, what you were searching. And, yeah, there there was a considerable anger in the community from what I could see just reading about it along the way.
Yeah. That piss people off a lot. It's it's one thing to have it on it's like it's almost like they were using one of those dark patterns where it's actually hard to turn off. Right? Because it's not easy, to to find out where it is to turn it off, and then it's not clear that they're doing it in the first place. Right.
I believe they have since backed off from this practice if
is that correct? Yes. The canonical corporation backed off. Well, they they made it off by default. And in a sense, then they've, like, sort of kiboshed Unity. But, like, it was actually useful. Like, if if you if they added a lenses function back to, to Gnome, I think people would use that.
Oh, and real quick, could you clarify, what you mean by lenses function? No. That was the name of the actual function
that people were annoyed at. Right? Lens, it was a it was an advertising, what they call the lens, right, that, you know, you just search arbitrarily just push the search bar sort of with the Cortana button on your on your, Windows machine or the, the spotlight button on your Mac, and you search something, and it would also search the web. And it was on by default that annoyed the canonical users because they're just not used to that. Whereas, like, your Windows users and your Mac users are kind of just it's just a machine in front of them, and they don't really care or they might care. They've, been Microsoft and and Mac and Apple are not exactly completely transparent with how, with with your relationship is to their companies. So that's just that's just part of the open source issue. Right? Like, that's why you choose open source software because you are suddenly made aware of how that company views you. You're not a product to the company. You're a user. You're a member of their community. And so that's why Canonical knocked it off. And to Microsoft and to Apple, you're kind of another you're a customer, but you're also part of the product.
I I hear what you're saying. It definitely sounds like the that the canonical thing is perhaps a a cautionary tale of what not to do if you're going to, partake in one of these types of partnerships in order to help fund what you're doing. And I think this leads us pretty well into our our last monetization type, which is paid features. And what I think is probably the best example to look at as far as an open source project that uses this is perhaps, MySQL or MySQL, if you pronounce it that way. In that there is an open like, the original open source project still exists. As many out there might know, it existed as open source before, Oracle, took on the project. And what Oracle did to attempt to monetize it was they started to release software tools that you could get access to if you got different tiers. So there's, like, a standard edition that gives you some things. There's an enterprise edition. And what it'll give you is tools that do things like backup and monitoring, so you don't have to do it yourself. Or managing clusters, which would be like having data across multiple database servers and and doing those things for you. So the idea that the premium product reduces your effort, if if that's what you're into. Is is this something that that, you would see as a as a favorable way to go to go about things?
That model is called the open core model. Right? Where the core of the software is open source and free, but then there's, like, pieces you can add on to it, attachments, if you will. It's actually really similar to the WordPress model in that you can pay for additional features from WordPress, and then you can pay others for additional features management system management system. You can you can set up stand up for Drupal for free. You can get open source Drupal plugins, but you can also pay for Drupal plugins as well. And then you can get Drupal plug ins from the Drupal company. So this is the open core model. Or some people will monetize their, software by making it so that any project well, you as an individual developer can use this project for free. But anytime they may want to make a a feature that's best used for groups or for enterprise, they will charge for that feature. The problem being, if someone else develops a feature like that and contributes it, now they're either obliged to accept that and reduce their own monetization, or they have a right to not accept that as a core feature or a core addition that you can use.
Oh, so it sounds like the example you're using, what they're doing is saying, hey. Here's this piece of software that we're gonna have open source. You know, you can either host it with us or host it with yourself, do as you will with the source code. But we're gonna create a marketplace where folks that want to do a creative endeavor, extending the capabilities of it beyond the scope that we saw for this project can do so and fund their efforts or or make a bit of profit that way in a convenient fashion. Am I hearing you correctly?
Yes.
Great. I'd also like to since we've gone through these different types of monetization, I would be curious to get a bit more about your perspective coming from, you know, the civic tech leadership direction as far as, like, do you observe projects out there that are attempting to fund themselves using any of these models? And and if so, is there one that's more common than another?
I heard I hear of projects that have spun up from, brigades. Right? A brigade had started a project serving its city, and then they wanted to support that project and then monetize that project so that it can sustain itself so it's not a burden to the city. I believe hold on a sec. It's called, Councilmatic. Yes. This is such an example. Right? So this is like the dream of a brigade is to to spin off project that it's created so that other cities can use it. Right? It encourages the the code reuse use of brigade products across brigades. Right? And that's, like, that's that's the dream. And then they can sell services to that product. Right? So I've met at, I think, yeah, most of them, they stay maintain contact and and, with the brigades that that spun them off.
If if someone in your brigade were to come to you for advice on on a way to fund their project using one of these methods, what would you suggest to them as the one that's or multiple that are most friendly to the civic tech way of doing things?
So one thing I would advise maybe against is advertising model. It one thing that, one of the the tracks of civic tech is safety and justice. Right? I've noticed that there's a lot of projects in this this in this, area, and many of the projects that Saint Louis have been, involved within the past have been around, civic justice. For example, our, our your STL courts project, which is similar to the court project in in Atlanta. And the idea is that a user would be someone who's involved with the courts or the the justice system. And one thing I don't want to see there and they don't want to see there is an advertisement. That seems really wrong. You've come this person has come to you at a time of need and vulnerability, and you're showing them a ad, it's like a middle finger. It's just a really bad look. Right? So take that into account when considering how to monetize this. So Matic, that actually seems like a yeah. You could put an ad on that site, I think, you know, but not, like, a time when a person is you you have to keep that into mind. The user and the state of mind that the user is in. And that's kind of again, again, the thing that pretty much only a brigade could do, right, is is have this sort of direct contact with the citizens and and keep the humanity of the users in mind. Right? Keep that in mind and and don't discount your contact with your citizenry. Just really, you should you should value that highly. You you divide energy from your community. It is, like, your primary source of energy and motivation.
So what I'm hearing is that the big thing that you want to avoid is causing damage to that relationship to those that you're building with and not for. You know? You gotta get that line in there. But you don't wanna cause harm to that relationship by presenting them something that could maybe inadvertently do harm because that person's in a vulnerable place. Yes. Am I am I on the right track?
Yes. It's just something someone asked me. They were one of these very hardcore few market people, and and they and I just didn't have an answer for them at the time. But, yeah, I just thought about the the feel of sitting down to that site, and I am trying to figure out if I've got a ticket out for me. And, you know, I'm not you're not advertising to me. This is a government site. That just really looks bad.
I I agree. That that would not be a good practice in that instance. I I think that would just be a a negative all around both for whoever put the site together as well as for the experience of the user. Right. So I I feel like this is a good opportunity for us to shift to something I like to do on these podcast episodes, which is to give the guests the the chance to have the the last word here. So are there any concluding thoughts that you would like to ensure the audience is left with about this topic and what we talked about today?
That point I just mentioned about you deriving energy from your community. I mean, there's a there's a point at which we had to remind ourselves in in software development and even just, you know, in a company that in a big corporation, you might whatever your software development model is or whatever your project management model is, sometimes you do lose sight of your users. And and that's, like, the main thing that an open source project is really good at. Right? That's why open source is so core to the to the Code for America model. Right? Is that it's it's code as civic action. It's code as civic, as as participation in the government. Right? And then and then you get people like, this discovery process of actually going in and discovering what it's like to to interface and interact with the government entity, now all of a sudden, the government jobs are more attractive to, like, the digital natives, the people who like, if you if you've we started off talking about the people interrogating Mark Zuckerberg. Zuckerberg. And Zuckerberg, like, I've I've some some developers feel bad for him, but because, like, he's in this position he had no idea he would wind up in. Right? I think Ta Nehisi Coates said you're prepared for no one to read your book, and you're not necessarily prepared for everyone reading your book. This is a guy who's not prepared for everyone in the world using his software, even though that was the goal. Now those senators interrogating so many of them don't completely understand the implications of the software they're using every day or the the implications of of the network, the World Wide Web. Right? This is I think some people were talking about, like, chemists were saying, we haven't had a Manhattan Project issue. And they're saying this is close. I guess. But now that more people are becoming aware of the hazard of software and computers and their ubiquity, now we can get more a more literate electorate on this subject. I'd like to see a more literate leadership on this subject, like, more computer literate people running for government office so we can get a more literate representation. I think that's what I wanted to leave
with. Those are some really great thoughts, and thank you so much for taking the time to be on with us today. I have no doubt that our listeners will really value your perspective and the opportunity to learn a bit about open source, which is maybe for some not a topic that's come up in their daily lives, and now they can be acquainted with it and perhaps use it with their upcoming projects. Thank you so much for coming on.
Gladly.
You can follow us on Twitter using the handle at civic tech chat. Visit us on the web at civictech.chat, or subscribe to us for content updates wherever it is you download your podcasts.
