wiki:Why this foundation

Options for governing open software

Authors: Barend Mons, Rob Hooft, Albert Mons

This document is based on a question at a meeting for the governance of the “dbXp” software. It was originally planned to set up a simple “Phenotype Foundation” to secure the future development of that software independent of any people that are currently funding it. Before this process starts, we would like to compare different possibilities to achieve the governance goal.

The goal of the governance structure is: Set up a structure that is independent of funding at a specific moment and can keep the development of the software alive. Structure it such that users can bring in programmers to work on the core together, and those users can determine the priorities of the core programming together.

The conclusion of our exploration is that we should probably set up a single Dutch foundation for the governance of different bioinformatics software packages. Setting this up as part of the CWA (the goals of CWA fit well to this purpose) would make it easy to extend the foundation to have a chapter in the USA.

Main questions that helped us get to this conclusion are posed and answered below.

1. Do we need a software foundation?

Yes.

The main alternative of a software foundation would be to sustain something like the status quo: the software could be taken care of by an existing organization like NBIC or DISC-DTL, and developed by partners in that organization.

Disadvantages of that approach are:

  • Preserving software is not the prime goal of such an organization
  • Ownership of the code is not unambiguously determined (it could be, though).
  • They are government funded projects that may have other obligations or priorities
  • Other interested parties may feel inhibited to join the effort, because the software is not perceived as an independent effort (They can ask themselves: will I have a true say in the future developments or will it actually be NBIC that is dictating what happens).
  • Funding may end, will the structure be able to keep the software development alive?

These disadvantages do warrant using an organization that has software governance as its sole or primary target.

A good option would be to join another existing foundation that already exists and does not suffer from a lack of impartiality: the Concept Web Alliance. This has as advantage that a 501(c)3 (tax exempt not-for-profit organization) has been set up for CWA in the USA already (see below). Although CWA was set up to enable and advance collaboration in data interoperability and stewardship, a logical extension would be to also assist in OS developments and data hosting etc. A separate ‘daughter’ could be set up for the purposes of the goals to be achieved here.

NBIC funtions de facto as the pen holder for the CWA project in Europe and could set up a Dutch foundation for the purposes intended herein.

2. Should we set up a new software foundation?

Probably.

It might be possible to make the effort part of the existing CWA foundation bodies, either as a separate foundation that is governed by CWA, or as a project of CWA. Whether a new legal entity is needed would a question for legal counsel (Maurits at B&B?)).

A completely different alternative would be to join an existing organization for software governance. An example organization is the Apache foundation. However, existing foundations we know all build software for software engineers, and not for another completely distinct user group. Their structure therefore does not have a group of developers distinct from the group that decides on the direction of the development. We will need a different governance structure than existing foundations, so setting up our own organization has a clear preference.

A not-for-profit foundation is the most logical choice. So the options are:

  • A Dutch foundation as part of the CWA project by NBIC
  • A completely independent new foundation
  • A ‘daughter’ of the USA 501 ( c ) 3
  • A combination of 1, 2 and 3 starting with the Dutch situation but set up to eventually expand internationally

3. Should the effort be specialized to bioinformatics?

Probably.

Pure bioinformatics software shares the same potential governance structure: biologists (in the wide sense of the word) determine the features, software engineers implement them together. It is possible that software for other user groups could use the same philosophy, but it is unlikely to be worth the extra complications.

4. Do we need a foundation per software package?

No.

The efforts of setting up the governance structure and foundation can be shared between software packages. Setting up a separate governance structure per software package will have a very large overhead; with a combined foundation many common issues can be arranged in the statutes of the foundation, and exceptions and details can be arranged at the project level. This also saves time setting up partner contracts and contributor agreements (especially for partners in multiple projects). A larger combined foundation can also take responsibility for keeping some packages alive while their development interest is minimal. Shared hosting of the projects and the development infrastructure can also save money. A shared reputation can also attract attention to the foundation and cause cross-pollination of the interest in the different projects. Sharing experience inside the organization can prevent making the same mistakes in different projects. A shared organization could also have as secondary target to promote interoperability between the different projects.

Possible disadvantage (could be seen as an advantage as well) of a single shared foundation is shared liability risk: if something happens in the development of one package, the whole foundation will be affected. This could be covered by an insurance? Another issue that needs to be addressed is the more complex fee structure and funding administration, but this can be overcome. Obviously, the name, the image, and the look and feel of the foundation will be more general, and this could be seen as a restriction on the projects. Each project will need to be attracting the right interested people by itself, but within the structure of the larger organization. Something that can also be seen as a disadvantage is that the goals of the foundation are more general; this should be solved at the project level. Further, we should make sure that a general foundation does not require an extra management layer adding bureaucracy.

5. Do we need to go international?

Probably in due time. The only immediate demand is to set up an initial Dutch structure that will be able to support local chapters later.

Internationalization in the future may be desirable: If the organization is Dutch national, it may be difficult to attract international funding and international attention (e.g. from the USA: tax free donations require a 501(c)3 organization in the USA itself). Of course if we are going for a single bioinformatics software foundation, the extra effort and cost of setting up and maintaining the chapters can be shared between the projects.

6. Other, unanswered questions

  • Should the foundation govern software only, or data as well?
  • Should the foundation put restrictions on the licenses for the projects?
  • If we set up a foundation, should it become the “grandfather” of the nbic trac server or should it set up a successor?
  • Time schedule and initiative/responsabilities.
  • Ben: Public/private issues should be resolved.
  • Are there any other reasons to have multiple chapters, except to receive tax-free money in the USA?
  • Liability must be discussed with legal counsellor
Last modified 7 years ago Last modified on Jun 6, 2012, 9:15:40 AM