 I'm Dalia Topolson-Ritvo. I'm the Assistant Director of the Cyber Law Clinic here at Harvard Law School in the Berkman Center. This is Kira. I'll let her introduce herself. Hi, I'm Kira Hessekeel. I also am part of the Cyber Law Clinic at the Law School in Berkman Center, and I am the project coordinator. And before I start, I think it's worthwhile to give a little bit of background on this project and how it came to be. So I was approached a little over a year ago by the MacArthur Foundation to look into why the IRS was not granting tax-exempt status to open-source organizations. Historically, open-source organizations have pretty easily gained tax-exempt status. And the standard would be that if you were an open-source project and you wanted to incorporate, you would file for 501C3 status, which is the category under law that's used for this tax-exempt status, which we'll go into a little bit more in a second. Partially because the idea was that we're giving code out for free, so it's a charitable purpose. So that was kind of the assumption. And I think that became the trend with open-source organizations. So why suddenly, out of the blue, were open-source organizations like the more famous ones that you know of Mozilla, Apache, the Free Software Foundation? Why were they all able to get tax-exempt status? And all of a sudden, open-source projects and organizations were really struggling and being challenged by the IRS? I will tell you this. I have not spoken to the IRS, as you can possibly imagine. This is not something that they talk about freely. But in 2010, in response to Tea Party activism and PACS, the IRS started to scrutinize who got tax-exempt status a little bit more closely. And they came up with this Beyond the Lookout list. On that list was a number of types of organizations. PACS were one type of organization that were on the list, but also news organizations and open-source organizations. Why open-source organizations? What suddenly caused the IRS to really scrutinize this a little bit more closely? I don't have a scientific or true answer. I just have instincts based on the research that we've done. But I think it's a combination of the success of the open-source movement and the open-source development process, which was adopted at that point in time. This is around 2010, not just by what would generally, I think most of us could assume, be perfect for a nonprofit, but also corporations. Suddenly, large corporations were using open-source development processes to launch full-scale products. So suddenly, the commercial world and the non-commercial world were starting to emulate each other. I find that to be a success of the open-source community and showing how a collaborative development process that relinquishes some IP ownership rights can be actually very beneficial for a community, regardless of your corporate structure. Nonetheless, this did cause the IRS to scrutinize these organizations more specifically because corporate America was now getting much more involved in open-source projects, both as contributors and as owners of open-source projects. So what is one to do? Is this completely an accurate portrayal? I would say no. I think that the open-source community lies on a spectrum. I will give my disclaimer early. When talking about open-source, it quickly becomes political. People have very strong opinions about open-source. I do not. I find it a process that can be beneficial to develop code, like any other collaborative creative process. Whether code should be free or not, I don't really take a position on that. I think you can involve various models. And as a lawyer, I still defend intellectual property in many instances. But I do see it as an excellent tool, both for development, collaboration, personal development in many ways, et cetera. So I will not take a political view. And I include, I hope that people are willing to talk about their own views if they want to and how this feeds into this conversation. So now that we have the background, I thought maybe we could talk about what it is to incorporate in the first place. So why would an open-source project incorporate? I'm a person in my dorm. I'm coding away. I think this is really cool. I'd like to collaborate with other people. Do I need to incorporate at this point? What is the benefit of incorporating? So why incorporate? You may not need to incorporate the day one if you're just an individual. But let's say you're a little bit more sophisticated. You got together with your friends. There's three of you. And you want to launch this excellent product. You think it's very beneficial to the collective or the common, so you want to make sure that it's open-source. And you want to make sure that it's a viral open-source license, meaning that it will remain open throughout the development process with contributors, et cetera. So why would you need to incorporate? Well, the first one is limiting your liability. That's the primary reason that organizations incorporated in the first place. What incorporating does is shield the individual person from liability and just attaches all liability for the organization to the organization itself. So to the extent you have personal assets that you want to protect, et cetera, it's a good idea to incorporate. The second is the laws of incorporation actually require you to put some mild structure around your organization, which Kara will talk a little bit more about governance structures generally. But this actually can be really beneficial to an organization when we start talking about who makes decisions, how decisions are implemented, what happens when there's a dispute within the organization, et cetera. Corporations require you to write bylaws that dictate your mission and also create a board of directors. Traditionally, the board of directors is intended to counterbalance management and create a check against what management may be doing, and it may be that person might be self-interested. Now, if you're a corporation of one, this doesn't really matter. But if you are creating a distributed model where you want more input from different types of people, having a board of directors can actually be very beneficial in the open source context. Because suddenly, you can create a board that checks potentially the founder of the project or something like that to ensure that the organization is committed to whatever bylaws were written, that they're implementing the processes that they thought about. And it also forces the project owner to really think about these things at the forefront. And we'll talk a little bit about business modeling in a little bit. And finally, clear ownership of assets. Again, if you're an individual, this is not as problematic. But if you have multiple people who are considered the founders, to have a corporation to own all the intellectual property assets is very useful. Now, we all know that open source, or at least those of you involved in the community, the idea is that everything's freely licensed. That doesn't mean that intellectual property ceases to exist. And the assets are still owned. The original creator of the code still owns that intellectual property. So having a clear title for that code actually makes it simpler, as you may want to grow and do more sophisticated things as an open source project. So incorporating helps you do that. So you've incorporated. You go to legal zoom. You file your C corp. And there you are. You've got a corporation. Congratulations. So the next step in most open source organizations is to seek 501c3 status or tax exempt status. The first step that you do is you file as a nonprofit in your own state. Every state has its own rules. You may be tax exempt in that state. Many states don't exempt any taxes until you get IRS exemption as well for federal taxes. But generally, this is what open source organizations have tended to do. Why have they done this? This was the question that I asked myself. OK, so the IRS is rejecting this. But what is that golden ticket of being a nonprofit? So in some sense, as it makes sense, you don't have to pay federal income tax. That's awesome. We don't want to pay federal income tax. The slides aren't in the wrong order. So you don't have to pay federal income tax. Your donors get to deduct their donations from their taxes. That's awesome, right? You can get money, and you can also serve this as a benefit to your donors. You may be exempt from state income sales and employment taxes. That really depends on the state of incorporation, where you incorporate reduced postal rates and exemption from federal unemployment tax exempt financing. I'm not going to go into that, but it's another essentially tax exemption that it can be really beneficial. But when you're not making income because you're delivering this for free, is this worth? There's other reporting requirements that you're obligated to comply with. Your bylaws need to state a particular mission, and not everybody's actually eligible for tax exempt status. So the question that I had is, why would you go through that? Why would you engage with the IRS and try to convince them that you're a charitable organization, or you're an educational organization, or a scientific organization? And it really came down to, from my perspective, and again, this is solely my perspective, that seemed to be the norm. That was the norm within the open source community. Why? Primarily to engender trust amongst their community that they weren't profit-driven organizations, and that they wouldn't pull back the code all of a sudden and make it proprietary and undermine the trust that they created with all of their contributors. Now, this remains a salient concern today. And if you're an open source organization and people are taking their time and energy to contribute to your project, you don't want to alienate them in any way, shape, or form, because you want to continue that collaborative energy. So is it necessary to be tax exempt in order to engender this trust? No, not in my opinion. That said, it goes a long way to show we're not in this for profit. We're in this to produce a great piece of code or a product or something that is owned by the commons in some way, since shape or form. And I'm not using IP here to talk about this, just generally, that it's a part of the commons. So just quickly, who is eligible for 501c3 status? I've highlighted the three that really tend to be utilized by open source organizations. They're either charitable, consider themselves charitable organizations, educational organizations, or scientific organizations. Now, originally, these were categories that the IRS accepted pretty blindly, to be really honest. But as they've started to scrutinize this space a little bit more, they've started to reject these categorizations of open source organizations. Simply giving software away for free is no longer a charitable purpose, according to the IRS, partially because many for-profit organizations and commercial organizations are giving software away for free all the time. And it is to their commercial benefit. So just the fact that you're giving it away is insufficient for charitable. So what are they looking for charitable? They're looking more for some tie to the impoverished or human rights or things like that. Freedom of expression comes up a lot in the software space. It's been utilized to mix results by the open source community. But these are the types of things that you would want to tie yourself to, is some larger purpose that the code is intended to. The other thing is, is the purpose the code itself or to advance this philanthropic or charitable goal or human rights goal or educational purpose? What is the true purpose of the organization? If you start talking too much about code, they're going to quickly think commercial or they're going to quickly think of a commercial development process versus some charitable purpose for the organization. So the IRS is much more focused on what is the purpose of the holistic organization than what is necessarily the purpose of the code. Second, scientific. Initially, again, there was a lot of use of, this is for scientific research. We're researching how code is developed, et cetera, and this and that. The challenge is that most open source organizations do not release research papers on their code. They release the code itself, but it's not researching the code. It's not doing scientific research in the more traditional sense of the word. So the IRS has started to create categories that need to be met or elements that need to be met in order to actually be eligible under the scientific category. Specifically, the organization must engage in scientific research. The scientific research must not include activities that are incident to commercial or industrial operations. This is a really key one to open source communities. And the scientific research must be undertaken in the public interest. So just the development of code, even if it can be a rich source for research, generally is not considered research in the traditional sense, especially when you're emulating what commercial entities are doing themselves. They consider it a development process that is common across the commercial world. And they're not accepting that as a true scientific research that is in the public interest. So the scientific argument has started to lose its steam. And then there's the educational purposes. And when they look at educational purposes, the ones that they seem to accept are when you're really educating the public. You're putting out sample code and telling them how to do it, or you're creating fora and educational conferences and things like that to educate people. It's not just that you put code on GitHub and that could be educational for somebody if they're self-motivated. It's really got to be the purpose of the organization is to educate people. Now, many projects, and I would say most, don't really go to that level. It's more likely that they're putting out code and they're collaborating with each other. And then some people use a public works that they're creating a public work with this open source. The IRS has also tended to reject that argument because it needs to be fixed to be a public work. And open source code is inherently not fixed because it's constantly iterating and developing. So it's become more of a challenge for open source organizations. So does that mean that no open source organizations can gain this status? Absolutely not. I just think that at the outset, before going through this process, before hiring a lawyer to help you prepare your application, et cetera, it's important for open source organizations to really think about why do I want this tax exempt status? What is so important to me that I need to be a 501c3? Trust is a big thing that comes up a lot, but are there other ways that we can engender trust? And, or if there really is a charitable purpose, if you're really advancing human rights through the development of these tools, or open source is just one element of a broader organization, I would say you're probably a good candidate. You're just gonna have to overcome the hurdle that for a few years now, the IRS has had a knee-jerk reaction against open source organizations getting this status. So what other options are there? So the newest option in corporate structure that can help engender that trust and help organizations create that communal trust is the Benefits Corporation. The Benefits Corporation is not available in every state yet. It's a very new corporate structure, but what signifies it, and here I've got the quote from the Massachusetts Benefits Corporation Law, is that in a Benefits Corporation, unlike a regular corporation where the duty of the board and the managers is to essentially maximize profits for the organization, in a Benefits Corporation, they can, directors and officers may are expressly permitted to consider and prioritize the social and environmental impacts of corporate decision making, which provides a lot more latitude. Usually what happens is in the bylaws, you actually explicitly state the mission that's usually required under the Benefits Corporation's laws and it varies state to state. And in your bylaws, you will say the primary mission of this organization is to do X, Y, Z, and we will forgo profit in certain circumstances for our shareholders in order to attain that goal or maintain this mission. Probably the most famous example of the Benefits Corporation was Ben and Jerry's. They were eventually bought by Unilever, so we can't really categorize them in that category anymore. I don't know if they maintained the Benefits Corporation status or not, to be very honest, but their whole goal was to foster local economy and also foster environmental sourcing, et cetera, responsible sourcing of materials and ingredients, et cetera, like that, et cetera. So Ben and Jerry's was held up as the bastion of the Benefits Corporation and kind of kicked off this movement. Now, it's not the same as nonprofit. You can get bought, sold, et cetera, so it does impact how you manage your intellectual property assets, how you communicate with your communities, but being a Benefits Corporation tied to some other mechanisms to include your community in decision-making can go a long way and engender the same level of trust that just being a tax-exempt organization can be. It also opens up additional financing opportunities that may not be available to an organization if they're a nonprofit. Nonprofit, you really are tied to foundations and donations is pretty much how you get your financing. If you're a for-profit company, suddenly venture capital can come in, private investments, et cetera, which if you're trying to build out an organization in a more sophisticated manner may or may not be beneficial. So with that, I'm going to now toss to Kira to talk a little bit about various governance structures that can tie into whatever your legal corporate structure may be. Yeah, so we're going to transition into talking about different governance models, some of which exist already in the open source community and are very well-known. Some are not so well-known and some are that I've found from other sources that I think could map well onto the sorts of concerns and goals open source organizations have. And like Dahlia said, how you structure your organization internally can also help sort of buttress the trust issues and openness of an open source community. So the first one I'm going to start with and we're going to go sort of from most top down and straightforward to most distributed in terms of who decides what is what's known in the open source world as a benevolent dictatorship. So for those of you who are familiar with open source organizations, I think Linux, that's the model that Linux uses. Why is it called a benevolent dictatorship? Because there's one person, usually one of the project founders at the top of the organization who has ultimate say over all decisions. So I've sort of mapped out for every model what the structure looks like. It's pretty straightforward. At the top you have the leader who maps out the goals and the vision of the project, what needs to get done and how that should function. And contributors who are just community members in the open source project submit code patches to that end. Those ideas, those patches are reviewed by committers who are more experienced community members and in the case of a benevolent dictatorship they're selected by the leader from among the contributors for this role and they approve them. Day to day, this is basically all that happens. Decisions are made by committers and the group at large if it's about process but the leader has final say over everything and will also resolve major conflicts that arise and also will intervene in the code development process when necessary. The when necessary is defined by the leader so that could be not very much, that could be a lot. So one of the benefits of this model and why it's sort of bubbled up naturally in the open source community and different projects is that it's very efficient. The chain of command is simple and clear and there's one person who makes all of the decisions. That's a lot of responsibility for one person that person has to be very involved in much of what's going on in the organization. If it's a big organization, that's a lot. So and because of that the community perception of the leader can have a big impact on how successful the project is. Namely because people don't wanna work with difficult leaders, particularly when they're volunteering their time and their talents, they're not getting paid, they do this because they're passionate about it. So the most successful versions of a benevolent dictatorship are those where the leaders are pretty judicious about using their authority and sensitive to community concerns and they also make the priorities of the project pretty clear so people don't pour themselves into something that ultimately gets tossed aside because it wasn't really a priority to begin with. This is something that Linux has, Linux is a very successful open source organization but Linus Torvalds who's the founder and well respected for his technical expertise has sometimes been criticized for being sort of cavalier in how he makes decisions. Some people, for some people they just don't wanna work on Linux because they don't like how Linus Torvalds leads the project. For some people it's not a concern but this is something that needs to be thought about. So and as you can see there's not like a lot of defined structure as how to processes on the day to day level work. That's really dictated by the leader and that's gonna vary from project to project so it just needs to be made very clear. If this seems like a two top down level for people one way to mitigate it might be using sort of a board of directors model to modify this either a group of outside experts who can advise the leader and help he or she make decisions or sort of conversely a community board that's not made up of committers but just other people from the community who can help bridge that gap between the top level of leadership and the average contributor. Okay so moving on, oops. So another very popular model already in the open source community is a meritocracy. The idea behind a meritocracy is that the merit of what the community what contributors brings in is how the community determines where the project should go and whereas I had sort of arrows leading up my chart of the benevolent dictatorship here I don't have any arrows because the idea is that the project is run by the community at large and everybody's on equal footing. There are different roles that you can have in the community but no one is supposed to be more senior than anybody else. So usually the founders of a meritocratic open source organization sit on what's called the project management committee and there may be a couple other people on this committee and they said general goals and whereas the leader of a benevolent dictatorship would select committers here it's the project management committee and those committers in turn approve contributor patches. So on a day to day basis if somebody submits something and nobody has a problem with it it gets approved, it's called lazy consensus. There's only sort of conflict and resolution if people disagree. Whereas contributors, the general contributor gets their code reviewed by a committer. Committers can also submit code but that's not reviewed until the entire community talks about the product release. So that kind of means that the committers have a little extra control over the direction of the project because their contributions don't get looked at until it's whatever software is basically ready to go. So in this model the authority is very decentralized and the community is really in charge of a lot of things. So that can be really good because this is something that the open source community values having input not feeling like their contributions are valued. But there's also a potential for bias decision making particularly because of the sort of group consensus model and the role of committers in deciding day to day what gets in and what doesn't. For this model to really work effectively it's really important for the project management committee or the project founders to make clear community norms especially when you define what merit means in a meritocracy. If merit only means contributing code that looks like X, Y or Z then you're not gonna get other sorts of contributions. And some groups have sort of mitigated this by also making it very clear that non-technical merit is important so your ability to help the community navigate problems or to establish clear processes that can be considered merit. But it's something that these groups have to think about. Okay so next we have delegated governance which is the model that I sort of have borrowed from a community manager of Ubuntu who's named John O'Bakin. And it looks kind of like a meritocracy in some ways but rather than the authority being sort of loosely spread out through the community it sort of starts at the top and we're back to arrows and is delegated out through a series of councils and sub-councils that are groups of community members who have been nominated and approved by the community or even elected for a certain period of time. Sometimes these groups have term limits as to how long you can serve on one of these councils to keep different members of the community involved. So the general council will, you know, at the top determine the project direction, how processes work on a larger level. And if the organization is large enough you'll have these sub-councils and I've just sort of made a model here but it could be different in a different organization that have specific charges. So there might be a technical sub-council that determines who's developing what and a process sub-council that says this is how we're gonna run things or a community sub-council that focuses on community engagement and how a community works together. So they sort of parcel things out and if a conflict arises the appropriate sub-council might resolve it and if they can't resolve it through voting they'll escalate it up the chain and eventually it can go to the community general council if it's pertinent. So a big benefit of this is that this allows a lot more community members to be actively involved in the governance. It's not just there's a couple of committers who have this check mark authority. It allows people to specialize based on their talents and that's not always just coding. So as a result people can be more engaged in the project and it also means that the leadership isn't involved in every single decision. People are given authority to make calls at lower levels and only have to escalate it if it can't be decided. When you add more process though in any situation things take a little longer. You don't have one person saying yes, no to everything. Conflicts may take a little longer to resolve. It's not necessarily bad but it's something to think about. It can also mean that people are more invested in the end decision. You don't have that sort of feeling of alienation that you might get in a benevolent dictatorship where somebody's mad, their code is excluded and they don't really understand why. And then finally if your councils are elected versus appointed by the founders or nominated and sort of confirmed that's gonna determine how democratic and how dispersed the authority is. That's just something to think about. And then the final model that I wanna talk about is something that comes from totally outside the open source world but I think could be something that groups, particularly those that are really, really interested in community involvement might gravitate towards. It's called dynamic governance or sociocracy. This is used in some businesses and non-profits. It's a dynamic model because the idea is to involve the whole organization in decision making. So to translate that to the open source context that would mean that every contributor has a role in governance of the organization in some way. So it again sort of looks similar to the delegated governance and so each of these circles represents a team of contributors. One major difference is that rather than majority voting, all decisions in a project circle are gonna be made by consensus. The other chief difference is that the circles are all what's called double linked. So there's two representatives in each circle from the level below it. So you have, using the model I've put up here, in the community circle you have two arrows going up to the general circle that decides everything for the project. One of those is the community circle team leader and then one of them is just another member of the team who's sort of been selected by that circle. So the highest level still makes overarching decisions for the organization and there's a path for escalation of conflict but more community members are involved. It's more consensus driven and you don't just have the top leaders making every decision. So that can be really empowering for community members provided that the open source project leaders and founders do a lot of community educating on how this model should work. You can't just throw people into a circle meeting and assume that they'll know how to reach consensus in a real way and how to manage this process. This all needs to be explained pretty explicitly. And because you, to have this model really work you need a lot of commitment from every contributor. This is gonna be a better model for some smaller, smaller to medium sized open source organizations. It's gonna be harder to have people contribute and flip in and out of the organization because without their involvement they can't, you know, the process isn't gonna work as well. They really need to be committed to a project in order for this model to run. And some people don't want that. They just wanna contribute their code and go on their merry way and not think about it but other people will be drawn to that. And so because of this need to really have people committed to certain areas, if a project wants to run with this dynamic governance model, they might need to identify, you know, okay, so we want sub-circle B to have a specific number of people and also to develop a process for bringing new contributors to the areas of greatest need. So that's all the models I have for you today. But the important thing about all of this to note that is that none of these are like set in stone. I've presented, you know, visuals to make it easier to understand but projects can combine or modify models to get what works best for them. The most important thing is that they think about this sort of at the outset, particularly in conjunction with what Dolly was talking about, about vision and goals because otherwise it's easy to fall into something that functions but doesn't quite work well with what their ultimate goal is. There's lots of ways to bring these models together or change them to make a best fit. And just to piggyback off of what Kira was saying, different organizations may need to modify their model based on different levels of maturity and growth of the organization. So day one, when you've just put something on GitHub, maybe too early to do some of these more sophisticated models of governance but as a project gains speed and in the vein of trying to engender that communal trust, it's useful, I think, for the organizations to think about how they're going to involve the community while also allowing the project or organization to continue to be nimble. This also, this tends to bump into itself the most when it comes to financing because your financier is one thing, right? And your community wants another thing. And how do you bridge that gap, including the community in certain types of decisions and being very transparent at the outset as to what decisions they are included in, what decisions are at the behest of maybe the founders or the board of directors or something, I think is really useful. And these are lessons learned from the commercial space but also the nonprofit space. What Kira looked at was volunteer driven organizations across the board to kind of come up with some of these models to supplement the two primary models which is the meritocracy and the benevolent dictatorship. So that's all we have in the sense of formal presentation. Just another thing that I wanna reiterate the Kira raised, something that's been challenging, I think for open source organization that has bubbled up in our conversations with people is the inherent bias within communities that merit is actually ascribed to the noisiest people rather than necessarily to the people who can contribute the most. And it's as the software community, general talks about bias infused within code, et cetera. This is a really interesting and important element in my perspective to think about also when you're setting up governance structures, who to include and it shouldn't only be technologists or are you narrowing the field for success for a project because you're not including input from maybe other areas that might be useful. And generally, let's say take a typical nonprofit, they'll pull somebody who's a volunteer who's in finance and they'll pull a volunteer who's a lawyer and they'll pull a technical person and they'll put them all on the board so that they have some expertise to leverage, especially in the context where there's not a lot of bandwidth or a lot of support. So we'll throw it out to all of you if you have any questions or thoughts or comments, we welcome it and challenge anything that we've said. First of all, we are not coders, I am a lawyer, so I may be completely off base, yeah. Thanks guys, this was a good presentation and I was just wondering if you could speak to some of the employment law issues in both the for-profit versus nonprofit thing, I guess the hypothetical I'm thinking about is there is a minimum wage and so if I'm a committer or project leader and I'm not compensated, am I owed back wages or there's sort of ways around that liability? So there's no, I mean, generally volunteer-driven organizations don't create an employment relationship with their volunteers, it's very explicit, you're volunteering your time. If you've been involved in any volunteer-driven organization, you generally don't sign any contracts saying you're a volunteer, there isn't that. I don't know of any case law and this is not something that we've looked at specifically but I don't know of any case law where contributors to an open source project have then asked for back pay because they were treated as employees. There's a certain type of relationship that needs to be established in order for that employment relationship to really, for that to be nebulous, like let's say they're giving you office space and they're giving you the laptop to use and you're working for the project 40 hours a week all the time. This is where consultants and corporations tend to start battling about whether they deserve benefits or not or things like that. In the open source community, there's nothing obligating anyone to contribute anything, you're not soliciting it, there's nothing and let's be more sophisticated open source organizations do have employees, they have staff coders and engineers that keep everything running, et cetera and they do employ people. As do nonprofit organizations, they often have large staffs. If you think of the Red Cross, they're a very large organization, they employ a lot of people but their volunteers are still considered volunteers and I haven't really heard of an issue like that. It's something to look into but generally unless you're really taking up a lot of a person's time and you're requiring it of them, it would be difficult to establish an employment relationship. Yeah, we've got a hand over here and then over there. Just open up a question about how organizations should or can't manage schisms and quirks. So I think this goes back to Kira's models of governance and if you're a benevolent dictator, you're going to define the source of your, how the destiny of your code. Now under an open source license, depending on the license, you can fork it and then I would say you'd have to rebrand it some way or something like that, so it's not confusing but you can't prevent a fork under an open source license. It's just a new. It wasn't asked about preventing it more about managing, how do gracefully manage a fork or a schism when it happens? Sure, I think and I like Dahlia, I'm not a coder. I haven't had a personal experience with this but I think the probably establishing a process at the outset, regardless of what your explicit governance model is of how you wanna do, address these issues as they arise because they often do is not a bad idea. Additionally, if you have an open source governance structure that's more community, it involves more of the community. It might make it easier to sort of have these conversations within the community if people have different ideas and figuring out if something can or can't fit under the umbrella. It might make things a little bit more flexible but this is just my sort of theory. It would have to be tested out but to me, the more transparency and the more community involvement might make it easier to deal with that. The other thing, this is an element of PR, right? So having, talking about who in your community should be involved in decision making, somebody who understands communications and how to message things to their own community so that a fork doesn't suddenly unravel the community, that's a communications problem and that's something that a PR person would deal with very artfully whereas I might not personally. So I think those are the things to think about and I think infusing your community with a broader set of tools across your community is important. I think we have a mic back here. Thank you very much. What would be an appropriate number for a board? That's a difficult question and one that organizations toil with a lot. I think it really depends on the nature of the organization, who you're trying to include and also how big you are. If you're one person, your board, you may ask some people, you may be a board of one. I don't advise that from a liability standpoint. That's not ideal. You generally want some other people involved in the board. But it can be as small as two or three, two is I sit on a board right now for a multi-stakeholder initiative that has over 20. The reason being is they're trying to allocate inclusiveness across the different constituencies that often have very differing interests. We're talking corporations, civil society, academics, it's a broad set of voices, so everybody needs a seat at the table, a representative seat at the table. The larger the board, the more unwieldy and difficult to manage. So it really depends on the size of the organization, what they're trying to do. I would say initially keep it small, start small and then build out. That said, if the community starts getting bigger and noisier and you start to see some conflicts arise, that's a great, the use of the board and allowing people to cycle in and out of the board is a great way to give people a voice at the table, even if there needs to be voting. Also in the bylaws creating voting structures, a lot of the open source community doesn't like structure. It's like, we're all friends, we all get along, we're all coding together for a common goal that's lovely. As the lawyer in a room, I have to say, what happens when you disagree and people do disagree? So building in the structure for those unusual moments in your bylaws can help because then you have a piece of paper that says, no, this is what we need to do. We need a two thirds majority vote for this type of decision. Like for instance, somebody wants to acquire the open source project. That's great financially, right? But it can really, really upset your community, right? So what do you do? But you have staff to pay potentially if you're big enough. You have code to sustain, et cetera. So this is where having people on the board can really be helpful. The size is less of a concern to me and more of the mechanisms by which people are added to the board. Are they elected? Are they appointed? How do they get there? Do they have terms? I'm a big fan of terms so that decision makers don't get stale or too institutionalized. But one more thing, does the IRS have an idea in terms of how large a board should be if you're applying? The IRS doesn't care about the size of a board. They just care that you're appropriately championing your mission and that you continue to conduct yourself as a non-profit and not a for-profit. So they're more concerned about that because the IRS is mostly concerned about tax collection. So if they see a way or a window to get you to pay taxes, then they're going to try to undermine that. And pulling from the non-profit world is old there. Also, thinking about the purpose of having each seat on the board, why is it there? There are also some structures of boards where they have different sections that have different purposes. So some non-profits, when they have board members who have served a long time and they want to sort of transition them into a different role, will have a super advisory board that meets only once a year versus the more regular board that meets on it actively. And it's more involved in decisions. They keep that expertise and long service and that connection while also allowing new people to cycle in. And it all goes back to the bylaws, et cetera. I will say this. We are not covering state law in this conversation. And state law may dictate if there's a certain amount of people that need to be on a board or not. And that could vary, state to state. And I don't know the answer to that specifically. I think we had a question over here. First, I want to thank you for your intellectual honesty acknowledging that Tea Party is the one that made IRS to look at themselves. My question is, why isn't there is some kind of movement that everything that released under Creative Commons should have automatic nonprofit type of status since it's antiquated to the academic research in some ways? So again, this goes back to what I said initially. I think initially the idea was to very openly say we're not doing this for profit. And I think Creative Commons is actually, just so that everybody knows, Creative Commons is actually an open source license, not generally utilized for software code, but rather for creative endeavors like music, et cetera. And the interesting thing about Creative Commons is this hasn't been an issue in that space because musicians generally want to make money. And they're very open about it, so our filmmakers, et cetera, but they realize that there's value in releasing a little bit of the reins of the licensing regime in order to maybe proliferate your work more or include it in different ways, allow for more remixing and more creative development off of whatever you've initially created. And it's very individualized in person to person. In the software space, I think because they're developing what could be potentially products and would potentially compete with commercial products, I think there was much more sensitivity to this, are we a corporation? If we are a corporation, we're a nonprofit to show the community that's contributing. And they're doing it, coders are amazing to me that they go to their day jobs, right? And then they go home and they code more on their own. That's amazing, it's very rare. I see very few professions that do that. And they're giving of their time and it's not beyond the pale for them to want some sense of ownership over the entire process. And I think that's why there was this desire for nonprofit. It also is important to note that many of the initial nonprofits became fiscal sponsors. So they were trying to aggregate open source code and sponsor the development of more open source code. This goes back to the more politicized views of open source, et cetera. So historically, if you're thinking about Apache Free Software Foundation, they act as incubators. So if you're thinking about yourself as a foundation and you're thinking about somebody who may fund something, then in that case, becoming a nonprofit makes perfect sense. Whereas if you're an individual project, I think that's up in the air a little bit more. And I think it's important for open source organizations to feel empowered and to really be thoughtful about what is the best way for us to achieve our mission? And this is just one tool available to me to achieve that mission. And structure yourself, think a little bit as a business model. And I use the term business loosely, not in the sense that we're trying to make money, but in the sense that we should model ourselves and create transparency so that we can engender our community and actually foster. One of the biggest challenges of the open source community right now is abandonment of projects. And so what is the process by which to create a sustainable, long-term project that can mature over time? And I think when you're just writing code in your room, that's hard to think about. And you may not have the expertise to think about that. Any other questions? Sure. In relation to foundation, did you ever provide a one-state free nonprofit? They can be. So there's other tax-exempt categories. Generally, the major difference is that donors aren't tax-exempt foundations, I believe. And I'm not an expert in this. Definitely call it tax lawyer or corporate lawyer. I'm an IP and privacy lawyer who's been dabbling all of a sudden into corporate law. Yeah. Actually, in free software for your prominent organizations, which are organized as foundations. Yeah, they're organized as foundations. Originally, Apache did get 501c3 status. And that's how they did. You can be a foundation that's under 501c3 status, which allows you to get these tax-exempt donations. I don't know if they've changed since they've become more mature. To be really honest, I haven't tracked their development. It's a good question. And I'll make sure to follow up on that. Yeah. Well, I built and ran a 501c3 in the open foundation. And we ran into this exact problem where the IRS actually questioned our 501c3 status. And we had to go through a whole bunch of stuff. And eventually, we had to shed supporting the technology development itself from the mission of the organization in order to keep 501c3 status. And my understanding was that Linux Foundation and Apache and others that were 501c3s, they haven't a long time ago. And they're sort of grandfathered in. But if you want to do it today, then the IRS is responsible that you can't do a 501c3 if you're going to directly support the technical development of a product. And that's basically the major difference between organizations that are supporting other organizations to create their own products versus or being a home for them in a sense. I will say also that what has now been deemed fiscal sponsors, there are newer fiscal sponsors that are actually not requiring open source organizations to be tax exempt. That was another driver, and I forgot to say that at the beginning, that the fiscal sponsors themselves, in order to be eligible to be part of their family, let's say, or part of their portfolio, were requiring organizations to gain nonprofit status. There are now fiscal sponsors like the Open Technology Fund that don't actually have that requirement. This is also interesting if you're developing products under a grant from another type of foundation, not necessarily tied to open source. This comes up a lot, whether you're a nonprofit or not, and whether you're eligible to get that grant. This happens a lot. And right now in the startup world, particularly incubated at universities, they start out very nonprofit-y, right? But eventually, they start veering more into the commercial space. Mostly remain sustainable as an organization, financially lucrative, and capable of continuing to develop whatever they're developing. So you'll see even projects that have been incubated here at Harvard, they start out as a nonprofit. They eventually break the organization into two parts. There's the nonprofit part, and then there's a for-profit part, and they may be affiliated in some formal sense legally or not, that kind of continue to develop products. We've also seen organizations bifurcate their mission-driven portion into the 501c3, and their Development Shop Act as a consultancy. So that's another model that can be used. And what I would like to do with what we're going to ultimately publish is to empower open source organizations to make these decisions a little bit more strategically and thoughtfully, so that they're not sitting there battling the IRS, which I don't think any coder really wants to do, right? I mean, I'm a lawyer, and I'd rather not talk to the IRS ever. So how do you create a sustainable platform that is inclusive, allows for scalability and maturity? And obviously, we're talking in an idealized world. Not every project is going to become a bigger project. I've heard from our fellow geeks that part of the challenge is just getting contributors to come. How do you get those people? I don't know the answer to that. But these are the questions, and thinking a little bit more strategically beyond just the legal structures, but also how you're going to do your outreach, how you're going to foster your community. And I think there's learnings from other types of communities that, frankly, are presented with the same challenges. Not every open source organization is going to grow giant, and not all of them really want to. We've talked to some people from the Berkman community and beyond who have developed open source projects. And when they talk about, well, what's the end goal? They're not necessarily saying they want to have unlimited people from all over the world. Many of them like working in open source because it's easy to collaborate. But they're really thinking about a group of 30 people max who are going to be contributing and are people they have relationships with already. So thinking about that and then constructing the way you govern your organization around that can be really important. I also think the open source community, as it's become a salient part of code development across the board, has also changed from a community that really is trying to free code to a community that's developing code for a number of different reasons, including freeing code. But also if you're a young student or somebody trying to learn how to code, it's a great opportunity for professional development. And we've seen that with just the individual contributors. And then they use that to foster their own portfolio when they go out to seek jobs, et cetera. And they may continue to participate very actively in the open source community once they reach that. But they might not be as concerned about some of these community issues as somebody who's more tied to the specific piece of technology or something like that. And I don't want to undervalue those concerns. There's a really interesting case study that worth looking at a little bit more is the MakerBot. This is more in the hardware space, not the software space. But this was an open source developed 3D printer that got pulled into back and became proprietary. My sense is it was because of financing primarily that they got some sort of investment that the investors were like, but you need to own everything. It can't be open source anymore. How do you navigate that question and without alienating the community? The MakerBot community got very, very upset. It didn't stop MakerBot from doing it, but is there a way to address that community and do what you need to do to continue to survive? And I think these questions as open source development becomes more proliferated across the various development shops. It's important to think about, especially if you as a project owner really have certain belief systems or values that you want to maintain. I think it's good to think about these on the front end and not something that is natural to think about. You think about clarity of code and the functionality of whatever is being created not necessarily how do I get contributors and who's the right person to sit on my board and all these things. This is where I absolutely empower people to make friends with people who don't do what you do. I think if I only talked to lawyers, I would be really restrained in how I could advise clients. So I think it's the same thing. I think we're out of time right now, so if there's any lingering questions, we can hang out for a few more minutes. But thank you so much for joining us, especially after a holiday weekend.