Collaborative projects will have shared assets that need managing
Once a collaborative project is in progress, the collaboration will naturally start to require the management of shared assets on behalf of the community of collaborators. This will include technical assets such as a source code repository, mailing list service, wiki, translation memories, build services, test systems and so on. While these can in many cases be hosted on shared services such as GitHub, it’s important to ensure that no member of the community has exclusive control. Even the most trusted individual can leave a project, and a lack of clarity about who legally “owns” those servers can lead to painful disputes.
Even more important is the stewardship of legally-recognised assets such as domain name registrations, trademarks, shared cash from donations and other sources, hardware bought for general use and so on. It’s very important these assets are legally controlled by the project rather than by a subset of individuals.
In time a project may have more significant assets, including public events, staff and even premises. By the time these are acquired, a community must definitely be anchored in a legally-recognised entity.
An independent legal entity is the best vehicle
Most projects aspire to creating a legal entity of their own, such as a limited liability company or a non-profit company. While it’s easy to start such things, getting it right and ensuring the control of the entity is in the right hands from the beginning – before there’s a crisis – takes experience.
Many people assume the best way to triage these issues is to start a new charitable entity – often colloquially called a “Foundation” irrespective of the actual structure – as these are government regulated and must incorporate both equitable treatment rules and not-for-profit objectives. But experience shows that starting a charity doesn’t actually guarantee as much as people expect. It’s still important to have the benefit of experience, so starting a new “open source foundation” – the expectation of many collaborating groups – may not be the best first step.
A fiduciary and administrative umbrella is a wise first home
Experience also shows that projects may be better protected seeking the shelter and assistance of an existing “umbrella” charity designed for open source projects. A number of these exist – Software in the Public Interest and Software Freedom Conservancy, both in the USA, are well known. The Apache Software Foundation has evolved into a form of project umbrella, providing its “incubator” process as an on-ramp for new projects, and the Linux Foundation is evolving an equivalent process. Outercurve Foundation can also offer assistance, viewing themselves as a liability firewall for contributors and sharing their excellence at packaging open source IP. Also referred to as fiscal sponsors, this approach is addressing a real need for, as open source becomes more popular and mature, formalizing the governance and corporate structures of open source projects.
In Europe, such arrangements are much less common, but a new open source umbrella Community Interest Company (CIC) called Public Software is being formed for European projects, and that’s an entity that holds good promise to host TravelSpirit in the future.
With a collaborative governance infrastructure in place, read more about our mission.