Is your organization an investor, expecting a return on its investment, or a disburser of no-strings-attached donations?We interpret "Fund" as a verb rather than noun: we fund things and have done so for a decade. We are a full 501(c)(3) public-benefit nonprofit and are not after the returns that, say, a venture capital fund would seek. In fact, in contrast to the pursuit of such returns, we have negotiated with a few proprietary software vendors about products that are commercial failures but could be open source successes if re-licensed with an OSI-compliant license. As for "Fund" the noun, we are considering the establishment of an endowment that would support nonproproprietary software and hardware. Is it necessary for open source projects to receive funds like this? Are there some key open source projects that just can't boostrap themselves with volunteer labor, consulting, etc? How does your typical open source project sustain itself? And what are the shortcomings to this "traditional" path that you're hoping to address? Yes, with regards to the necessity and your touch on three related issues here: one-time project assistance, project bootstrapping and long-term project sustainability. With regards to one-time assistance, we often find that funding is the last tool that is appropriate to help a project in need. Developers are generally well-equipped to make technical decisions on behalf of a project but are unprepared to serve as strong financial and administrative decision makers. We have encountered situations where projects more urgently needed help with nontechnical matters such as attending an event, shipping equipment or finding a home for a domain name. We always try to help projects exhaust any and all free resources that are already available to them and are preparing to formalize this help with select conservancy services that would provide such administrative support in an unintimidating way. Project bootstrapping takes a number of forms including the authoring of new code from scratch, the adoption and completion of promising code that has never quite reached production quality and the relicensing of proprietary code. Our direct donation projects have addressed all of these approaches to varying degrees and with varying success. In all cases, we believe that the public awareness of a project is just as important as any new lines of code because both bring the project closer to a critical mass of community that should result in priceless amounts of future technical and nontechnical contributions. While new and relicensed proprietary code projects promise to best meet any given technical needs, such projects usually face the challenge of beginning without a community. "Build it and they will come" is genuinely possible thanks to the Internet but mindshare is still an elusive and precious commodity. I am most excited about promising pre-1.0 projects as they often have established communities and could genuinely be "best kept secrets." The hangup is that often such projects have strong but introverted communities of developers who have satisfied their own technical needs with the project and either do not recognize the value of a broader user and developer community or are actually hostile to the idea. Two promising but under-the-radar projects that fall into this category are the GNUstep and Lazarus development environments. As for long-term project sustainability, we are witnessing a gradual transformation of the software industry away from licensing-based funding and business models to countless alternative models, the best of which haven't been invented yet. While project bootstrapping is important, projects can face financial challenges at any stage of maturity. For example, the foundation behind the Gnash project recently lost its funding. How an organization responds to such challenges is the key: the Free Software Foundation turned to a membership model to address its funding challenges. Our organization was once faced with the loss of our main credit card but survived. We're pleased to see that the FSF is trying the credit card model of funding that Linux Fund pioneered. This is simply the nature of public good in the USA: it comes with no guarantees and, as Andy Grove put it, only the paranoid survive. There is, however, the occasional unexpected success: the Mozilla project received so much money from its Firefox Google search toolbar that it jeopardized its nonprofit status. You highlight consulting and, like the Firefox search toolbar, there are ways to incorporate such "commercial" activities into nonprofit software foundations. Some nonprofits, in fact, wholly own for-profit consulting divisions which in turn advance their mission. As long as software costs nothing to duplicate, I am convinced that nonprofit software foundations will eventually dominate the software industry, but again therein lies the challenge: what sources of revenue will sustain them? To address these issues, Linux Fund is continuing to develop new funding models and introduce unintimidating administrative services that will gradually grow unincorporated, volunteer-driven software projects into authoritative foundations. What do your donors and sponsors hope to achieve with their support? Do you find that it's mostly interest in a particular project, or is it OSS in general? Donor motivations vary greatly and require great care to leverage. Individual donors who are project developers often see the value of the work to the project as whole, and may personally see their lives made easier by it. Non-developers are more inclined to want to benefit either a given project or category of projects. I love when people support two loosely-related projects like the OGD1 and gEDA/PCB as I know they've recognized the relationship. Corporate sponsors are primarily after the PR value, and we highlight a number of possible approaches they can take in directing their donation. The majority of our direct donations to date have been from grass-roots individuals, and we see great value in this growing community. Do you provide any non-monetary assistance to the people behind open source projects (such as public relations, organizational, or technical help)? Yes, as outlined before; I also invite you to watch for formal announcements in the coming months. Our Ubuntu Massachusetts LoCo project is, in fact, a beta test of several elements of these services including event planning and printing sourcing. Their enthusiasm has been amazing, and we see no reason for them not to benefit from the collective wisdom of the community. How do you determine which projects to fund and the cash goal? I lead a Technical Advisory Board that identifies projects with unique potential. Project selection begins with a lot of listening, and it was several months into our direct donation projects that I discovered the FSF High Priority project list only to find that we were already addressing several of its concerns. Our ideal partner project is one that is promising but not yet production ready but also aims to shatter a glass ceiling in the software industry: enabling free and open source software to enter a field where it currently is absent. Mechanical and electronic CAD and EDA design software are a perfect example as virtually everything made by humans has gone through design software. An incalculable amount of data exists in .dwg and related AutoCad formats, and this is the exact same situation the world faced with .doc and .xls formats. Literally our collective knowledge is saved in those formats, and it is critical that we have open access to the data locked in them. Our gEDA/PCB and VectorSection projects address these issues, and if the majority of the top 500 supercomputers can run Linux, it is absolutely possible for nonproprietary software to penetrate traditional industry. Every project begins with a budget to achieve a certain goal, and from this we determine cash goals ideally in incremental steps and milestones. Incremental projects allow individuals to adopt certain portions of a project and know they are making a difference. This effectively allows a nontechnical individual to make a solid code contribution through a financial contribution, and that's exciting. I am glad to see that the Google Summer of Code project has encouraged many projects to think about development budgets for the first time. Does a project's choice of open source license have any bearing on its eligibility for funding? Our top concern is that project's license is OSI-compliant and we encourage the use of the more popular copyleft and copycenter licenses such as GPL and MIT/BSD/ISC. My personal opinion on nonproprietary softare licensing is that we'll need to wait about twenty more years to see who has the best approach. While there is clearly a valuable role for lawyers to play in this community, we would prefer see funds first and foremost go to developers. How will the introduction of the BSD Fund affect the allotment of time and resources to Linux projects? Fortunately, BSD Fund coattails on virtually all Linux Fund legal and mechanical infrastructure and does not introduce significant time or financial overhead. With the recent introduction of the BSD Fund Visa, BSD Fund is a bit like Linux Fund circa 1999. What proportion of donations go towards administration and running costs? If you want an exact figure, under 8.25% to date, and only upon the successful completion of a project. We continually refine our model for partner project direct donations and hope to eliminate any overhead withholding through direct donations to our General fund and other revenue sources such as our credit cards. Donors should be aware that with the relatively high cost of electronic processing fees, you can help any given project most effectively by writing an ordinary check.
OSNews would like to thank the OSNews readers for supplying the questions, and of course, Michael Dexter for taking the time to answer them. The next interview with community questions: the Arch Linux team. That interview will be up later this week.