Of course, starting a foundation does not resolve community relationship issues. If there's dysfunction, such as a crisis of trust between community members, merely incorporating won't likely solve it. Addressing community relationship and trust issues before incorporating is key, otherwise these issues are likely to be wired into the foundation's structure and bylaws, perpetuated indefinitely.
The steady growth of long-term entities such as the Apache Software Foundation and the Eclipse Foundation, the introduction of foundations for large projects such as OpenStack and LibreOffice, and the existence of general-purpose foundations such as OW2 and OuterCurve provide ample evidence of the increasing importance of foundations in driving open source forward.
All of these foundations cultivate trust in the stability of the activities they represent and encourage corporate participation. We will see more of them.
Another key driver of today's open source movement is the sheer volume of available licensing choices and how choice of open source license is changing, thanks to increased participation from corporate organizations that recognize the importance of community.
All software automatically benefits from copyright protection for its author, giving her control over who can make copies of the source code or derivatives, including extracts of source and compiled binaries. Since the executable version of software has to be copied onto a computer to be used and into memory to be executed, it's necessary to have a license from the copyright holder for any use of the software.
In the earliest days of open source, there were broadly two choices for licensing copyright. People sharing Bill Joy's pragmatic do-what-you-want outlook picked licenses like the one used on the Unix Berkeley System Distribution (BSD) he pioneered. Others sharing Richard Stallman's view that software freedom demands social engineering picked the General Public License he devised for his GNU Project -- so called because it is a license benefiting the general public.
The adoption of these ideas by businesses was a key motivation for creating the Open Source Definition as a tool for categorizing licenses as open source. In 1998 it was clear that others wanted to replicate the experience of the Mozilla project and declare their work "free" while frequently disregarding the need to deliver software freedom, much as many businesses in today's food industry seek to use the term "organic" without delivering on the holism behind the term. To combat this, the Open Source Initative was formed to promote the term "open source" to signal truly "free" software. From that point, only licenses granting anyone freedom to use, study, modify, and distribute the software would be approved by OSI as representing.
Businesses wishing to avoid using the GPL tended to follow the example of the Mozilla project and created their own license. As a result, over 60 new licenses were approved by OSI in the first few years of the open source era. But this proliferation has come with a cost. Open source licenses often don't mix; when you make your own, you condemn your project to isolation. Creating a new license like this is a problem that arises from a fundamental misunderstanding of the role of the license in open source, treating it as a traditional bilateral legal agreement. Instead, an open source license is a multilateral agreement, "the constitution for the community," as Eben Moglen once put it.