LWN.net Weekly Edition for May 2, 2013

LFCS: The Outreach Program for Women

At the 2013 Linux Foundation Collaboration Summit, GNOME Foundation Executive Director Karen Sandler spoke about bringing more women into open source projects. GNOME has produced measurable results in recent years with its Outreach Program for Women (OPW), which has now expanded to include numerous other free software projects.

Sandler started off by reminding the audience why it is important to talk about the subject of increasing participation from women in open source. If you have not experienced incidents of sexism directly, she said, you are not necessarily aware of what it can be like. She noted that when she herself started out in software development, she did not want to talk about the issue. Instead, she said, she just wanted to concentrate on doing her own work. When she went to law school, however, the percentage of female participants was considerably greater, and once she returned to the free software community, she could not help but notice the distinctly different corporate environment.

At present, 25% of all software developers are women, Sandler said, and 18% of currently graduating computer science students are women, but only 3% of free software developers are women. However, the Google Summer of Code (GSoC) program experiences a distinctly higher percentage, 8.3% in 2012, which Sandler said reflects hard work being done on the GSoC team's part. Rather than diving into the motivators and reasons for open source software's low percentages, she said, she wanted to take a practical look at how GNOME has improved its own participation statistics through OPW.

In 2006, GNOME had 181 applicants to its GSoC projects, out of which zero were women. The project realized that it had a real problem, so it launched its Outreach Program For Women, which offers paid internships working with GNOME software projects. The program was "moderately successful" that year, Sandler said, but none of the women who participated as interns stuck around after their internships ended. In 2010, the program was relaunched, with the addition of Marina Zhurakhinskaya, who currently co-leads the program with Sandler.

This incarnation of the program started with an effort to look systematically at all of the reasons why women are not participating in the project. Sandler noted that in "every discussion about women in free software we're always saying 'well, I think the reason why they're not here is because ...'" followed by any one of a handful of reasons. Rather than so assuming the answer (or answers), however, the relaunched program systematically looked at all of the possible barriers to participation, and it tries to address each of them in turn.

The program runs two rounds every year, one concurrent with GSoC, which Sandler said inspired the overall mentoring and internship process (the other round begins in January and runs through April). OPW produces advertising that specifically targets women, which Sandler said produces better results than did more generic marketing materials. In fact, OPW periodically hears from an applicant that she did not know she could apply for GSoC (or thinks that she is underqualified for GSoC), and OPW sometimes helps applicants apply to GSoC instead, especially if the code project in question makes more sense as a GSoC internship.

Successes and moving beyond GNOME

The effort has produced measurable results. Prior to the relaunched OPW, GNOME's GSoC participation garnered zero or one female student each year (or "binary numbers," Sandler quipped), out of the 20 to 30 total GNOME students. But in 2011, seven of GNOME's 27 GSoC participants were women, followed by five of its 29 participants in GSoC 2012. Similarly, 4% of GUADEC attendees in 2009 were women; at GUADEC 2012, 17% of attendees were women.

The program proved successful enough that GNOME decided it should not keep the program a GNOME-only affair. Sandler first reached out to the Software Freedom Conservancy (SFC), and SFC member project Twisted agreed to run its own internship program in conjunction with OPW's on a test basis. The test went well, so GNOME concluded it that should expand OPW to include as many projects as possible.

The marketing and branding materials were revised to highlight free software in general, and a broader OPW was launched for the January 2013 round, with ten other software projects participating—such as Fedora, Tor, JBoss, Perl, and Mozilla.

How (and why) it works

Sandler attributes the success of OPW to the systematic approach it takes. The outreach addresses women directly, which has been shown to be more effective. It also accepts non-students and non-developers, which has attracted a more diverse set of applicants, and it connects the interns with mentors, which helps participants jump in and ask for help when they otherwise might not.

One of the differences between OPW and other internship programs is that OPW requires applicants to make a contribution (code or otherwise) with their application. Zhurakhinskaya came up with the idea, Sandler said, and it has two beneficial effects. First, not everyone who applies for an internship can be accepted, but helping applicants get connected with a project during the application process allows them to get involved and make contacts. Second, the contribution requirement gives the OPW program managers a far better idea of what the applicant is like than would filling out a form alone.

During the internships, the focus is on encouraging participants to take on manageable tasks that can land during the internship period; it is sometimes tempting to want to take on a large, ambitious contribution, Sandler said, but the downside is that not being able to deliver on such a project is not a positive experience. However, mentors are encouraged to stay in close contact with the interns, and can ramp up the project if the intern is getting things done. Interns are also required to post bi-weekly blog updates on their work, and the interns' posts are aggregated on Planet GNOME, which helps raise the profile of the program.

There is a specific IRC channel for OPW participants, plus regular meetings for interns. GNOME has historically tried to provide travel assistance for GUADEC to the interns, and is now building a specific travel stipend into program. All of these mechanisms help the interns build ongoing relationships with community members, Sandler said, which is important since (as the organizers recognize) building mentoring relationships is the most important aspect of the program. OPW makes a point of encouraging mentors to continue to keep in touch with their interns after the program ends, and of encouraging former interns to stay involved by (among other things) presenting at conferences.

A large number of interns have returned as mentors, Sandler observed, which is one of the best indicators of success. But even those interns who never return to open source software development leave the program with a better understanding of software freedom, the community that produces it, and of its potential to change the world, and they become advocates for the movement.

Similarly, implementing OPW has helped GNOME in ways that extend to participation by men as well as women. The process of finding mentors identifies people who will be good mentors for anyone, the process of identifying smaller tasks for OPW applicants' initial contributions helps the project find good starting points for all newcomers, and so on.

Up next

The next round of OPW internships is slated to begin in June (concurrent with GSoC); most applications are due on May 1, although applications for the kernel internships are due May 8. But there are many other ways to help get more women involved in open source software, Sandler said, such as the Ada Initiative, which runs the AdaCamp unconference for women in open source and open culture projects. The next AdaCamp is planned for June 8 and 9, in San Francisco. AdaCamp is invitation-only, she noted, so it is important to apply as soon as possible.

Some people feel like they must choose to support one initiative or another, Sandler added, but in reality all of the different efforts fit together, and they address different aspects of participation. She encouraged everyone to help out in some way, whether by spreading the word, inviting potential participants to apply, or by persuading your company or free software project to participate as a mentor. Participating in OPW as a mentoring organization requires just two things, she said: funding to pay the stipend for at least one intern, and mentors willing to work with newcomers. Zhurakhinskaya has set a tentative goal of 12% participation from women in GSoC 2013. That may be a little ambitious, Sandler said, but only by setting lofty goals can we get there.

Comments (5 posted)

A report from the Google Test Automation Conference

The focus of 2013's Google Test Automation Conference, held April 23 and 24 in New York City, was "Testing Media and Mobile". A major theme was WebDriver, which is an API for automating web browsers. Mozilla presented its work on WebDriver support in Gecko and extensions to WebDriver to allow automated testing of FirefoxOS beyond just the Gecko-powered content layer. Google talked about WebDriver support in Chrome/Chromium, including Chrome on Android. Others demonstrated FOSS software that re-purposes the WebDriver API for testing native mobile applications on Android and iOS. WebDriver seems to be gathering a lot of momentum in the world of automated user interface (UI) testing.

WebDriver

Selenium is a commonly used tool for web browser automation that is primarily used to automate UI-level tests for web pages and rich web applications. Selenium controls the browser by sending mouse and keyboard events, and gathers results by querying the state of particular document object model (DOM) elements. So, for example, a test script for an online contact-management application might click an "add contact" button (that loads a dialog via Ajax), then check that certain DOM elements have appeared, and that they contain a particular text. You target DOM elements using XPath locators. Selenium also comes with an IDE (implemented as a Firefox plugin) that "records" test scripts by watching the mouse and keyboard.

This type of testing is not a replacement for unit testing or isolated component testing; but as Ken Kania pointed out in his talk [video], you still want some guarantees that what the user sees in the UI is correct.

Selenium initially relied on JavaScript run in the browser to simulate user interactions; but since version 2.0 (released in 2011) Selenium incorporates WebDriver. WebDriver fires events natively at the OS level, thus overcoming many limitations in the JavaScript-based approach.

WebDriver has three parts: A protocol (using JSON over HTTP and now a W3C working draft); a "local" implementation, which is a library used by the automated test scripts (implementations exist for a variety of programming languages); and a "remote" implementation, called the "browser driver" that is implemented as a browser plugin (Firefox, Safari) or as a separate executable that communicates with the browser's own debugging and inspection interfaces (Internet Explorer, Chrome, Opera). The Chrome and Opera implementations are officially supported by the respective browser vendor. There are also WebDriver implementations for mobile browsers. These are typically implemented as an app that uses a WebView object — i.e. the WebDriver app contains a browser in-process. These implementations extend the WebDriver protocol with mobile-specific APIs (finger gestures, screen orientation, etc.).

A WebDriver test script in Python might look like this (taken from a slide from Kania's talk):

    driver = webdriver.Chrome('chromedriver.exe')
    driver.get('http://www.google.com/xhtml')
    search_box = driver.find_element_by_name('q')
    search_box.send_keys('ChromeDriver')
    search_box.submit()
    self.assertTrue('ChromeDriver' in driver.title)
    driver.quit()

This script starts up a WebDriver "browser driver" targeting the Chrome browser (apparently on Windows). It then has the browser make an HTTP GET request, waits for the response (which contains an HTML form), and fills in and submits the form. Finally, the script does the actual test, which is to assert that the submitted text is present in the title of the HTML page sent as a response to the form submission. Real-world test frameworks would decouple the details of which particular browser is being tested (in this case, Chrome) from the test script itself, but this example gives the idea.

ChromeDriver

Kania, who is from the Google Chromium team, talked about Google's work on ChromeDriver (WebDriver for Chrome). ChromeDriver has been available for the desktop browser on Linux, OS X, and Windows for over a year; it is available in the Chromium source repository.

Recently ChromeDriver was re-architected into "ChromeDriver2" to support more platforms. Currently, the only addition is Android, and still at alpha-level quality; if you want support for Chrome on Chrome OS or iOS, "you have to be patient... or contribute", Kania said.

ChromeDriver is a stand-alone executable that speaks with WebDriver on one side, and communicates with the browser on the other side. Since ChromeDriver2, it uses the Chrome DevTools protocol to control the browser (see Kania's ChromeDriver architecture slide). Kania noted that Chrome is a multi-process browser, and the main browser process already uses this DevTools protocol to communicate with the renderer processes.

Michael Klepikov, from Google's "make the web faster" team, talked [video] about Google's work to make the profiling information from Chrome Developer Tools programmatically available to WebDriver scripts. This slide shows the specific API to enable this profiling. Klepikov demonstrated a test script that launches Chrome, goes to news.google.com, searches for "GTAC 2013", and switches to web (as opposed to news) results, all via the UI; it (presumably) also asserts that certain results are displayed. He demonstrated this test both on the desktop Chrome browser (video), and on Chrome running on a real Android phone (video). When the test completes, it prints the URL of a web server on localhost (powered by WebPagetest) serving an interactive display of the timing measurements, which can also be viewed within the Chrome Developer Tools interface.

Marionette: FirefoxOS meets WebDriver

Malini Das and David Burns from Mozilla presented [video] the work done on automated testing for FirefoxOS. The FirefoxOS runtime engine is based on Gecko (Firefox-the-browser's rendering engine), so the phone's user interface, as well as the bundled apps and third-party apps, are written using HTML5, JavaScript, and CSS.

The existing Firefox WebDriver implementation (a browser plugin) works for the desktop browser, but not for FirefoxOS. So Mozilla has built WebDriver support directly into Gecko, under the name Marionette. Why WebDriver? The Firefox test suite contains thousands of Selenium WebDriver-based tests, and there are thousands of web developers already familiar with WebDriver.

Marionette allows full control of the phone (including telephony functions), and not just within an individual application. Marionette scripts can even control multiple devices at once (to test a call from one device to another, say). Mozilla has written client-side libraries (what the WebDriver spec calls the "local" side: the automated test script) for JavaScript and Python.

WebDriver isn't fully specified for gesture-based input, so Mozilla has added its own extensions. You can define gestures by chaining together actions (a "pinch" could be implemented as press-move-release with one finger, plus press-hold-release on another finger). Another Mozilla extension to WebDriver is the setContext function, to switch between the "content" and the privileged "chrome" contexts. Third party application developers only need to test at the "content" level, but testing FirefoxOS itself often requires access to privileged functions.

Marionette supports (non-UI) unit tests too, and can run the hundreds of thousands of tests that already exist for Firefox. Marionette can run these tests against Firefox on the desktop, the Boot to Gecko simulator, FirefoxOS device emulators, and real FirefoxOS devices. David demonstrated some geolocation unit tests running on an emulator, though there wasn't much to see other than the emulator booting up, plus some text output on a console. Unfortunately the demonstration of an actual UI test running on a real phone encountered technical difficulties. "Let me demo how quickly the phone resets", David said to much laughter.

Of course there are security concerns with allowing a phone to be controlled remotely. For now, Marionette is only available in engineering builds; Mozilla is working on a way to deploy it for third-party developers.

Appium: automation for native apps

Jonathan Lipps from Sauce Labs started his talk [video] with a complaint: while "mobile is taking over the world", test automation for mobile apps is extremely underdeveloped.

Lipps is the lead developer of Appium, a test automation framework for native (and hybrid) mobile apps; it is released under the Apache 2.0 license. Appium consists of a server that listens for WebDriver commands, and translates them into implementation-specific commands for the particular device under test (Android or iPhone, real device or emulator). Re-using the WebDriver protocol (originally intended for in-browser web applications) means that users can write tests in any existing WebDriver-based framework.

Appium extends WebDriver with mobile-specific features by hijacking WebDriver's executeScript command (you pass in a string starting with "mobile:" instead of actual JavaScript). Presumably a more official mechanism will be worked out eventually.

Behind the scenes, Appium uses the operating system's official automation frameworks: UI Automation and Instruments on iOS; uiautomator on Android. Appium also has an optional backend for the community project Selendroid which, unlike uiautomator, works on versions of Android prior to Jelly Bean.

Lipps demonstrated [video] Appium's brand-new support for FirefoxOS by running a test script against the FirefoxOS simulator. The test launched the Contacts app, asserted that Lipps's name wasn't present in the list of contacts, clicked the "add contact" button, added him as a contact, and finally asserted that the new contact was present in the list view. Lipps had added FirefoxOS support during the conference, since Burns and Das's talk the previous day, which really shows the advantages of open standards like WebDriver.

Android uiautomator

Guang Zhu (朱光) and Adam Momtaz from Google covered [video] in some detail the Android uiautomator framework. Much like Selenium WebDriver tests, a test for a mobile application needs a way to control the mobile device, and a way to receive feedback on the state of the device; Zhu provided a survey of the approaches taken by existing Android automation frameworks (slide 1, slide 2, slide 3). uiautomator uses the InputManager system service for control, and the Accessibility service for feedback. This means it will only work if the application's widgets meet accessibility guidelines — which will hopefully encourage more developers to make their apps accessible.

Set-top box testing with GStreamer and OpenCV

I (David Röthlisberger) demonstrated [video] how YouView uses GStreamer and OpenCV for video capture and image processing to run black-box automated tests against YouView's set-top box product. Using GStreamer's gst-launch command-line utility, I showed how easy it is to capture video and insert image-processing elements into the GStreamer media pipeline. (Incidentally, the ability to create a prototype so quickly using GStreamer's command-line tools was crucial to obtaining management buy-in for this project at YouView.)

Using these technologies, YouView built stb-tester, released publicly under the LGPL v2.1+. stb-tester scripts are written in Python, and have two primitive operations available: press to send an infrared signal to the system under test (pretending to be a human user pressing buttons on a remote control), and wait_for_match to search for a given image in the system-under-test's video output.

I also showed some examples of "model-based testing" built on top of stb-tester: First [video], a script that knows how to navigate within a menu arranged as two rows of thumbnail images (aka a double carousel), so instead of saying "press UP, then LEFT, etc.", the script says "navigate to entry X". Second [video], a state machine of YouView's "setup wizard", that allows test scripts to generate random walks through the possible user choices during the setup wizard.

In spite of the name, stb-tester can be used to test any consumer electronic device, not just a set-top box, as long as it outputs video and can be controlled via infrared. See stb-tester.com for documentation and introductory material.

Who's responsible for testing?

"Your developers — or worst case, test organization — produce tests."
—Michael Klepikov [video]

Another major theme of the conference, which was more on the people and process side, was that the responsibility for testing is shifting from a separate test team to the developers themselves. In any organization following modern development practices, developers will write unit tests for their code; but end-to-end integration testing, performance testing, and security testing have traditionally been the domains of separate teams. Even Google has separate positions for "Software Engineer" and "Software Engineer in Test", and there seems to be a difference in status between those two positions — though judging from conversations with various Googlers, that difference is decreasing.

Claudio Criscione, who works on web security at Google, gave a talk [video] on an internal tool his team developed to find cross-site scripting vulnerabilities; he said they put a lot of effort into making the tool easy to use, so that development teams could run the security tests against their own applications, taking the load off the security team. Similarly, James Waldrop pointed out in his talk [video] that his performance testing team at Twitter can't possibly scale up to test all the systems being produced by the various development teams, so instead his team provides tools to make it easy for the developers to write and run performance tests themselves. Specifically, he presented Iago, which is a load generator developed at Twitter and released under the Apache 2.0 license.

Simon Stewart, who created WebDriver, leads the Selenium project, and now works at Facebook, said in his talk [video] that Facebook has no such thing as a "Software Engineer in Test", only "Software Engineers". Furthermore, Facebook has no test or QA departments. The developers are responsible for testing.

About the conference

The conference is in its 7th year (though it skipped a year in 2012). Attendance is free of charge, but by invitation and limited to around 200 technical participants; applications are announced each year on the Google Testing Blog. Live streaming was available to the public, along with a Google Moderator system for the remote audience to submit questions to the speakers.

It was a very polished conference — you can tell Google has done this before. It was held in Google's New York City office; meals were catered by Google's famous cafeteria. A sign-language interpreter was on site, and stenographers provided live transcripts of the talks. Videos and slides are available here.

Comments (5 posted)

LFCS: The value of FOSS fiscal sponsorship

As open source becomes more popular and mature, questions of formalizing the governance and corporate structures of projects are becoming of increasing importance, as can been seen by the rising visibility of various FOSS foundations. At the Linux Foundation Collaboration Summit in San Francisco, Tony Sebro shared his insights about the value that fiscal sponsors bring as umbrella organizations for FOSS projects. Sebro is the General Counsel of Software Freedom Conservancy, which is the home of about 30 free and open source projects, including Samba, Git, and BusyBox.

Sebro kicked off his talk (slides [PDF]) by explaining some of the problems that unincorporated open source projects face. The Internet makes it easy for developers to get together and collaborate on a project. Unfortunately, there are several potential downsides in such a loose organization, especially when a project grows larger. While individuals and corporations can contribute time and code, it's difficult for unincorporated projects to raise and manage funds. Of course, many projects use PayPal, Flattr, and other means to obtain funding, but an unincorporated project has no central place to hold and manage the assets. What happens in practice is that the project founder or a similarly trusted developer will hold these assets.

Fortunately, this arrangement works out in most cases, but it can lead to severe problems in the case of a dispute—the person who registered the domain name owns it, rather than the project, and it's unclear who holds trademark rights. Sebro noted that it's possible to hold common-law trademark rights even if a trademark has not formally been registered. This is something few developers are aware of and it can lead to uncertainties as to the ownership if there is a dispute. More generally, unincorporated projects suffer from a lack of administrative support and expertise. Most developers want to write code and tend not to worry about administrative tasks.

Sebro further explained that developers working on an unincorporated project face potential risk and legal exposure. For example, if a project intends to organize a conference they may have to sign a contract with a venue. Since an unincorporated project cannot sign contracts, one of the developers would have to do so. The person who signed the contract would be on the hook if there were any serious problems, for example if the project had to cancel the conference due to lack of registrations or unforeseen events. Finally, Sebro argued that there's little insulation from corporate influence. An unincorporated project could be taken over by a company quite easily by employing the core developers or by spending significant engineering resources on the project.

Advantages of forming a legal entity

The solution for these problems, according to Sebro, is to provide a corporate home for the project. For most projects, a 501(c)(3) non-profit is the most appropriate structure, he said. 501(c)(3) refers to the US tax code that defines a charity. A 501(c)(3) charity can receive charitable donations on behalf of the project, manage and spend funds according to its mission, and enter into contracts. A non-profit can also provide administrative support, such as bookkeeping, legal services, and technical infrastructure for the project. The non-profit can act as the central place to hold project assets, so there are no uncertainties as to the ownership of trademarks, domain names, and physical assets (such as servers or t-shirts and other merchandise).

Sebro suggested that a non-profit may potentially limit the exposure to risk for individual developers. He cited the US Volunteer Protection Act, which limits the liability of volunteers acting on behalf of a public charity. Sebro noted that developers would have to act under the auspices of the charity in order to benefit from the protection and they cannot be grossly negligent. While Sebro seemed fairly confident that the Volunteer Protection Act would limit the risk for developers, "this has not been tested", he said. However, a non-profit home can certainly protect individual developers from risk associated with contracts, conferences, and similar activities.

Another advantage of a formal structure is that it insulates a project from corporate influence. A 501(c)(3) charity must work toward meeting its charitable mission and must act in the interests of the public. A charity may not tailor their activities toward one or more individuals or corporations. Furthermore, while corporations can make donations, they cannot dictate how their donations are to be used. Answering a question from the audience, Sebro explained that this is a fine line to draw. He said that a company cannot donate to a non-profit in order to get a specific feature implemented that is of primary interest to the company, as that would provide a direct benefit to the company. However, it can certainly make donations so the non-profit can add specific features on its roadmap—even if the company benefits from these features. At this point, Sebro briefly explained the difference between 501(c)(3) organizations, like Software in the Public Interest or Software Freedom Conservancy, and 501(c)(6) organizations, like the Linux Foundation and the Eclipse Foundation. While the former is a charity which has to act in the interest of the public, the latter is a trade association—companies working together to further a common goal. According to Sebro, a 501(c)(6) insulates the group from imbalanced corporate influence, as the organization has to balance the interests of competing members.

(Don't) do it yourself

Having explained the advantages of incorporating as a 501(c)(3) organization, Sebro explained different ways that projects can go about obtaining the benefits of such a structure. The one that may seem most obvious is to create your own. The process in the US would be to create a corporate and governance structure, such as officers and a board of directors, and to incorporate at the state level. The tricky part, however, is to attain 501(c)(3) status, which is required so that donors get tax deductions for their contributions. Unfortunately, new applications for 501(c)(3) undergo close scrutiny where the mission involves free and open source software, he said. Any newly formed FOSS organization will be handicapped, according to Sebro, as it will be difficult to obtain 501(c)(3) status.

A new organization would also have to answer many questions regarding its service plan: would it handle bookkeeping and legal services in-house or via a third party, and most importantly, does it have enough funding to cover that overhead? Summarizing pros and cons, Sebro said that the organization would benefit from the single brand and complete autonomy that comes from having its own non-profit. However, it comes with significant drawbacks—high overhead, a lack of clarity about who is actually going to do the work and provide the required business and legal skills, and the major uncertainty regarding attaining 501(c)(3) status.

The alternative solution is to create a relationship with an existing FOSS foundation that can act as a fiscal sponsor. It's important to note that a fiscal sponsor does not sponsor a project through monetary contributions. Its function is to provide a legal structure and environment in which projects can operate and raise funds. Many fiscal sponsors also offer a range of services to projects, typically for a fee or by taking a certain percentage from a project's donations. Sebro's talk explained two types of fiscal sponsors: comprehensive fiscal sponsors and grantor/grantee fiscal sponsors.

Comprehensive fiscal sponsors

When a project joins a comprehensive fiscal sponsor, they sign a fiscal sponsorship agreement (FSA) and become fully integrated into the sponsor—in a sense, it's like a merger and acquisition in which the fiscal sponsor takes over the open source project. The fiscal sponsor supervises the project to ensure that it follows rules of the IRS (Internal Revenue Service, the US tax agency) and is in compliance with the mission of the fiscal sponsor (which is broadly defined to encompass many projects). In the case of Software Freedom Conservancy, technical decisions and questions of infrastructure are decided by the project. The Apache Software Foundation (ASF), on the other hand, dictates parts of the development process (the Apache Way). In return for joining a comprehensive fiscal sponsor, projects will benefit from the service portfolio offered by the organization. This can include legal services, bookkeeping, conference organization, and more. Software Freedom Conservancy, for example, offers a service plan from which members can choose à la carte. Furthermore, developers are shielded from risk because they are acting as volunteers for the non-profit.

There are a number of advantages of this type of structure: overhead is shared, the fiscal sponsor has 501(c)(3) status already, and it is likely to have a lot of experience running a non-profit so it can offer reliable services and solid advice. A drawback is a certain loss of autonomy: since a fiscal sponsor is responsible for several projects, they are likely to be more conservative than a single project may be on its own. Another risk is that pooled resources imply pooled risk: if member A owes funds, would the assets of members B and C be at risk? Sebro cited the Charitable Trust Doctrine which says that donations have to be spent for the declared charitable purposes under which the donations were solicited. Spending member B's resources to pay for debts caused by member A may be in conflict with this doctrine, which could therefore provide some protection. Sebro mentioned a case that held "New York's long-standing policy honoring donors' restrictions on the use of the property they donate has greater weight than the claims of creditors." While there is some uncertainty in this area, Sebro argued that the best way to manage this problem is through good governance.

Grantor/grantee fiscal sponsors

An alternative arrangement is for projects to enter into a grantor/grantee relationship with a fiscal sponsor. This model is more lightweight: projects don't join the fiscal sponsor but remain autonomous. Sponsors can receive and manage funds on behalf of the project and provide these funds to the project in form of a grant. The sponsoring organization has a duty to ensure that the funds are spent in an appropriate way. In a sense, the fiscal sponsor acts as a bank for the project, but it can also offer a range of services to projects. Software in the Public Interest (SPI) follows this model.

This structure also allows the sharing of overhead burden and provides administrative functions to the project. While the project can stay autonomous, it won't benefit from potential risk protection at it would have if the work was done under the umbrella of a non-profit. The project and organization also have to be careful that grants are spent according to the purpose of the grant. If a fiscal sponsor takes money and gives it to a project without supervision on how it is being spent, it may run into problems with the IRS.

Advantages for developers and corporations

Sebro summarized the advantages of joining an existing non-profit foundation: it's a shortcut to benefit from 501(c)(3) status, there are economies of scale and lower administrative costs, and the administration can be outsourced to people who have experience running a non-profit organization.

In addition to these direct benefits, projects may also find it easier to obtain funding and other contributions from companies. Compared to an unincorporated entity, a 501(c)(3) fiscal sponsor provides better governance, better structure, and mentorship. In other words, it provides stability to an open source project, which is something corporations are seeking before they invest in a project. Non-profits also provide a neutral territory: a company is not able to control how the project is operating but neither can its competitors. However, corporations can still "vote" by allocating employee time: if a project has different sub-projects or tasks, it can decide which areas to focus on.

Role and sustainability of fiscal sponsors

Sebro explained that there are different roles that fiscal sponsors can play for projects. He asked whether a fiscal sponsor should be seen as a playpen, an apartment, or a nursing home. In fact, these roles are not mutually exclusive and a fiscal sponsor can play all of them. In the playpen role, the fiscal sponsor essentially provides an environment for incubation until a project reaches a certain maturity and decides to go its own way. Sebro cited former Conservancy member jQuery which decided to form its own trade association. Many projects view a fiscal sponsor as an apartment—a long term living solution. Sebro mentioned that a comprehensive fiscal sponsor could hire staff for a specific project, although Conservancy is far away from being able to do that. Finally, a nursing home, or mausoleum, can provide a home for projects that are essentially dying off. There is some value in that context as the copyright and other assets can be assigned to the fiscal sponsor. This makes it easier to the revive the project or relicense its code in the future.

Finally, Sebro raised the question of sustainability. Fiscal sponsors usually take a cut from donations to member projects in order to fund their operations (Conservancy: 10%; SPI: 5%). In the case of Conservancy, this is not sufficient to cover its operations and it relies on donations to the general fund from corporations and individuals. Sebro mentioned examples from other areas (e.g. the arts) where fiscal sponsors have achieved a sustainable model, but many FOSS fiscal sponsors still have a long way to go in that respect.

Comments (10 posted)

A goodbye note from Michael Kerrisk

I'm stepping back from full-time writing at LWN to focus on a number of other projects. Writing for LWN has been an exhilarating ride where I've learned a lot. I'd like to thank all readers for their interest in my articles and their often valuable comments. Even more, I'd like to thank my colleagues at LWN. Their thorough and insightful input made each and every one of my articles better—in some cases much better—than it would it would have otherwise been. I've thus gained a first hand understanding of why I have appreciated LWN so much as a reader. Although I step back from working on LWN with some sadness, I won't be disappearing from these pages altogether: I still plan to contribute occasional articles in the future as time and interests permit.

Comments (11 posted)