How do you organize and manage something so hugely successful and widely varied? Not easy, but Harvard's Cyberlaw Clinic has some good advice.
As of today (June 1, 2017), we've been talking about open source for exactly 19 years, 3 months and 23 days. The start date was February 8, 1998, when Eric S. Raymond distributed an open letter by email with the subject line Goodbye, “free software”; hello, “open source”. What followed was a deliberate (though barely coordinated) effort by many geeks (including yours truly and this magazine) to make open source a thing.
It worked. In books alone, the result looked like what's shown in Figure 1.
Figure 1. Google Books Ngram Viewer: Open Source
I am sure that the line would have continued rising toward the sky if Google hadn't tired of scanning books in 2008 (https://backchannel.com/how-google-book-search-got-lost-c2d2cf77121d).
Anyway, we succeeded. As both an concept and a practice, open source is embedded in technology, business, culture, government—you name it. In fact, it is so widely uttered, you might even call it mature.
But it's not, because making full sense of open-source development is still an uphill struggle, especially if you're an organization trying to manage it—especially in a world that still doesn't fully understand it, even though it gets talked about constantly.
This is why it's good to have help such as just came from Organization and Structure of Open Source Development Initiatives (https://dash.harvard.edu/handle/1/30805146), a new report by Dalia Topelson Ritvo (https://tara.law.harvard.edu/cyberlawclinic/bio/dalia-topelson-ritvo), Kira Hessekiel (https://cyber.harvard.edu/people/khessekiel) and Christopher T. Bavitz (https://cyber.harvard.edu/people/cbavitz) of the Cyberlaw Clinic (https://cyber.harvard.edu/teaching/cyberlawclinic) at the Berkman Klein Center for Internet & Society (https://cyber.harvard.edu) and Harvard Law School. (Disclosure: these are all colleagues through ProjectVRM and the Berkman Klein Center, where I am an alumnus fellow.)
The angle of the report is organizational, and the organizations it addresses are less those of the development efforts themselves than of companies that need to get some kind of handle—or several handles—on the simple fact that they already support open-source work, either by employing developers of open-source code or because they have a code base they would like to open up and release to the world. There are as many answers to What should we do? as there are companies and developers, which also doesn't make things easy. But there are controlling factors in the real world that can help guide decisions, even as the same factors can be deeply frustrating.
For example, taxes.
Early on it was easy for an open-source project in the US to obtain 501(c)(3) status, which relieves an organization of the need to pay taxes. Apache and Mozilla both got their 501(c)(3) status right out of the gate, without much sweat. Coming along later, the Open Source Elections Technology Foundation (OSET) had to wait six years for it, after an initial denial by the Internal Revenue Service. Then there were the IRS's BOLO—“Be On the Look-Out”—lists. According to the report, “Every released BOLO dated between August 2010 and July 2012 included open source organizations.” Why? Because, said the IRS, “[t]he members of these organizations are usually the for-profit business or for-profit support technicians of the software. The software is provided for free, however; fees are charged for technical support by the for-profit.” This, says the report, “misrepresented the wide variety of open source business models, ignoring that many open source organizations do not have affiliations with for-profit businesses.”
BOLOs are gone now, but the IRS's sphincter remains no less tight. Concludes the report:
While some open source software organizations may continue to obtain 501(c)(3) status, this option may be closed off—in particular, for organizations that choose not to or cannot offer activities to educate the public in software development or a demonstrable connection to a charitable purpose. Given these changes, open source software organizations can no longer count on obtaining 501(c)(3) status and may want to evaluate the pros and cons of adopting alternative business structures.
Those include 501(c)(4) and 501(c)(6), which are alternative tax-exempt status recognitions. The former is for “civic leagues or organizations...devoted exclusively to charitable, educational, or recreational purposes”. The latter is for “business leagues”. Specifically:
In the open source software community, 501(c)(6) organizations generally act as umbrella organizations for many projects rather than working directly on a single project. For example, the Dojo Foundation and the Eclipse Foundation are 501(c)(6) organizations that support open source software projects.25 But, a shift in IRS policy toward open source software organizations applying for 501(c)(6) status—which parallels the shift regarding 501(c)(3) applications—may be underway.
That happened, for example, when the IRS turned down the OpenStack Foundation's application for 501(c)(6) recognition.
Advice:
Given the complexities associated with achieving exemptions from federal income tax, open source software organizations may have to begin reassessing their business models. Organizations may decide to continue to operate as nonprofits while paying federal income taxes, generate and rely on profits, or adopt a middle path between those two extremes.
There are many choices for middle paths: Limited Liability, S, C and Benefit Corporations, for example. The report unpacks all of them.
Then there's the matter of governance. Back in the early days, governance wasn't much of an issue. It still isn't in cases where leadership is strong and clear, such as with Linux. But in countless other cases, governance can get complicated and contentious—because humans, basically.
Recently, for example, the Drupal Association went through a major crisis when one of its main contributors was exiled for an unspecified infraction involving sexual kinks—or...something. Not clear—if you want the particulars, links abound on the web. The two most relevant to the governance issue, however (at least at the time of this writing), are “Working through the concerns of our community” (March 31, 2017, https://www.drupal.org/association/blog/working-through-the-concerns-of-our-community) and “Next steps for evolving Drupal's governance” (April 10, 2017, buytaert.net/next-steps-for-evolving-drupal-governance).
Both Linus Torvalds and Dries Buytaert (of Drupal) are what the report calls benevolent dictators. But while Linux remains at the bazaar end of the bazaar-cathedral spectrum of projects, Drupal has some cathedral elements. For example, Dries also runs Acquia, a for-profit company that deploys Drupal in the world.
The report also describes other models: meritocracies (Apache for example), delegated governance (Ubuntu, possibly, with qualifications), dynamic governance (or sociocracy). There are also models from outside the open-source world—for example, federated nonprofits, aka “Model E”. Examples of that are the Girl Scouts and the American Red Cross. These are important to recognize and learn from, because they've been around a long time and have survived troubles that many open-source projects still haven't encountered. Hence this advice:
One major challenge for all organizations—but particularly those focused on specific skill sets (like institutions engaged in open-source software development)—is recognizing the value of outside perspectives and non-technical skills. Because the heart of every open source project is the development and maintenance of the project's code, it's not always apparent how non-technical contributions should be recognized, or how they might improve development processes or community relations. In the same vein, those who are the best developers and code contributors may not always possess the soft skills required for open-source leadership roles.
As we know.
Bottom lines:
When open source creators launch new projects, their primary concerns may be technical. But expanding their focus to the organizational can have enormous benefits. Projects that make thoughtful decisions around corporate formation may streamline dealings with the IRS and also create stable entities that will help them be sustainable and dedicated to their ultimate missions. Projects that spend time considering questions about corporate formation set themselves up to create a welcoming project community with engaged and invested contributors; and then govern that community effectively....
Though it is sometimes overlooked, the history of the open source movement shows us that the projects that defined their corporate structure and governance practices early and concretely set themselves up for success. While some elements of the landscape have changed—most notably the IRS's attitude toward open source projects—the benefits of intentionality remain.
To me the most important issue is the tax one, because we still haven't made clear the leverage on both technology and the economy that comes from nonprofit work on open-source code. If we had made this clear, the IRS's job would be easier today, and fewer projects seeking nonprofit status would be stuck in limbo.
But maybe that job is an impossible one.
A few years back, a former FCC chairman told me there were two things that federal lawmakers, almost across the board, didn't understand: “One is technology and the other is economics.”
Still, it's worth trying.
Maybe the sell is to ask them if they think technology is a Good Thing. If they say yes, we can add that open source causes commercial successes, and that it's not the other way around. In other words, if you want to maximize commercial successes and technology benefits in the world, go ahead and give nonprofit status to open-source projects that want it. The good work those projects do will throw off a lot more tax money as well.
