wiki:Huishoudelijk Reglement

Life-Time Foundation By-Laws

This version of the by-laws has been approved by the "bestuur" of the foundation on 2012-XX-XX.

Introduction

These by-laws extend the "statutes" as they have been deposited for the Life-Time foundation. They are describing regulations that are not arranged by the statutes. The by-laws can never be in conflict with the statutes, nor with the law.

Abbreviations

BOD : Board of Directors = "Bestuur". Many of the procedural issues for the BOD are covered in the Statutes.

PRB: Project Representatives board

TAB: Technical Advisory Board

SAB: Scientific Advisory Board

Organization

The foundation has been set up to handle the interest groups for different open-source software packages. Each of the sub-organizations that deals with one software package is called a project of the foundation. The foundation is independent of a single developing entity: this ensures that every member that joins a project is a full member, and not less influential than original "founding" members of a project. Also, projects in the foundation are independent of a single source of funding. Furthermore, the structure of the foundation makes it possible to continue development when the original "founding partner" of a project is no longer interested, and even allows restarting development after a period in which no development has taken place.

What sets the life time foundation apart from other software governance foundations is that each project has two mostly distinct stakeholder groups: a scientific user group (mostly biologists, clinicians and other life scientists) and a technical programming group (bio-informaticians and (scientific) programmers). This duality has implications for the governance structure.

The foundation recognizes two kinds of open source software:

  • Community open source: projects for which the ownership is distributed in the hands of many contributors. Such code is normally distributed under an "unrestricted" license.
  • Institutional open source: projects for which a single or a few institutes have the ownership of all the involved code. This is normally distributed under a copyleft-license.

Both types can be governed by the foundation. For all institutional open source projects that are governed, the foundation shall be the sole owner; this is to be arranged during the project approval phase. This is the preferred situation. Community open source projects will only be accepted into the foundation if it is clear that that it will be impossible to have all copyright owners in a project sign a contributor agreement.

All (non-retired) code that for which the ownership rests at the foundation will be available at all time under an OSI approved license. This guarantee is a compensation to the open source community for donating ownership to the foundation.

Projects are largely self-organizing. These by-laws specify some guidelines and minimal rules that apply to each of the projects of the foundation.

Goal of the foundation

The goal of the foundation is in the laws. At the moment these bylaws were written, that was "De stichting stelt zich ten doel het beheren van, het bevorderen van de ontwikkeling van, en het vereenvoudigen van het gebruik van open-source software die in het bijzonder gemaakt is voor gebruik binnen de levenswetenschappen." or "The foundation has as its goal to maintain/steward open source software that is built especially for use in the life sciences, as well as the promotion of the development of such software and the simplification of its use."

Here are some example interpretations of this goal that we want to pursue specifically:

  • Raise the awareness of the need for proper software stewardship. Make sure people understand that data stewardship is useless if the stewarded data can only be read by obsolete or unmaintained software.
  • Make and keep software citable so that publication and credit can reach the right people.
  • Keep clear track of the financial support that is given to projects, and how it is spent to improve the software

Members of the foundation

The foundation is a "stichting" under Dutch law, and therefore does not have "members" (a "vereniging" could). Where this document speaks about members and membership, an affiliative membership is meant.

  • Individuals as well as organisations can become affiliate members of the life time foundation. They do this by associating themselves with one or more of the projects of the life time foundation.
  • 12-monthly rolling membership of the Foundation will be open to everyone who shows active participation in the governed open source projects (e.g. uploading of example datasets, programming of modules, acquisition of funding) or is contributing financially to a project.
  • Membership in the foundation is linked to membership in one or more projects. Financial contributions to the foundation as a whole can entitle an individual or organization to membership of the foundation without being a member of any project.
  • There are no membership fees, but the foundation is a certified not-for-profit organization in The Netherlands and as such can accept voluntary donations. Institutional affiliate members are strongly suggested to make a yearly donation to support the basis of the foundation.

Governance of the foundation

The Foundation will be governed by the following bodies:

  • A Board of Directors (BOD), which acts as the operational decision-making and executive entity of the Foundation.
  • A project representative board (PRB) , for strategic discussions.

Each of the projects will be governed by:

  • A Scientific Advisory Board (SAB) to enumerate and characterize the scientific priorities and needs of the Project
  • A Technical Advisory Board (TAB), to guide stewardship, design and development trajectories, and review architectural decisions

Board of Directors

  • The Board of Directors (BOD) will be elected or re-elected every three years (see statutes) with roughly 1/3 of the directors being elected in any given year, to ensure continuity.
  • Noone can be elected for BOD membership more than 3 consecutive periods. { this might not be a good idea }
  • The main tasks of the Board of Directors are to define, refine and implement the strategy of the Foundation.
  • The BOD shall be comprised of seven Foundation members with at least two members representing the Technical Advisory Board, and at least two members representing the Scientific Advisory Board.
  • The Board of Directors will meet at least twice per year, physically or virtually.
  • The Board of Directors is responsible of keeping track of project funding agreements, for the approval of new projects and for the shutdown of projects that are no longer maintained.

{ Discussion point: maybe we should abandon the concept of SAB and TAB and only have a joint PRB for representation ? }

Project Representative Board

  • The PRB is invited for a meeting by the BOD two times per year.
  • Two PRB members from different projects can call an additional meeting with the BOD when an urgent subject comes up.
  • The PRB consists of at least 2 members from each project: one from the SAB and one from the TAB.
  • The PRB strives for consensus. Any votes on issues discussed in a PRB meeting are open. Every member present at the meeting has one vote.
  • The PRB can ask a member of the BOD to resign if it loses confidence.

Scientific and Technical Advisory Boards

  • Scientific and Technical Advisory Boards determine their own (regular!) meeting schedules, preferably once a month
  • For each project, a representation from the SAB are present in TAB meetings and a representation from the TAB is present in SAB meetings.
  • The SAB sets and updates the roadmap for the open source software development that is carried out by its Technical Community: determining backlog and priorities
  • TAB meetings are used to set up and evaluate development sprints and to coordinate the work progress.

Staff

Foundation will have a CEO voorzitter? and a CTO secretaris?, a CFO penningmeester? and an office manager (not necessarily full time) to deal with the purely executive tasks TODO: REALLY? Are they in the BOD? Are they also elected? Are their periods also limited (Flexwet!)

Technical Community

  • Each project has a Technical Community, formed by the subset of members who are active data experts and programmers
  • All members that will commit code or donate data to Foundation-governed project will sign a Contributor’s Agreement, which transfers the copyright on the committed code and data to the Foundation. This is necessary to maintain a clear legal status. As a compensation for this transfer of ownership, the foundation will guarantee the availability under open license of all donated code and data, following the aims of the foundation.
  • Membership of the Technical Community is open to all data experts and programmers that actively commit in one of the software products
  • The technical community chooses among themselves a subset of members that can form the Technical Advisory Board (TAB). All institutional members that are represented in the Technical Community should be represented on the Technical Advisory Board.
  • The Technical Advisory Board chooses among the members of the project a Project Release Manager who is responsible for guarding the software development process and packaging regular releases of the software products.
  • The Technical Advisory Board will have a regular meeting at a fixed timeslot. Suggested frequency for these meetings is weekly. Decisions are noted, and distributed to all members of the project as soon as possible after each meeting.
  • The Technical Advisory Board serves as advisors on topics related to broad architecture and other technical choices to be made in the Project.
  • Board Members representing the Technical Community are co-responsible with the executive team for guiding the Foundation in the implementation of the roadmap set out by the Board, and the executive team handles communication between the Board and the broader Technical Community [TODO : ???]
  • No single programmer is responsible for one piece of code, to avoid single points of failure. The reality that all code will be subject to change in the future is embraced, so all code is to be properly instrumented with tests. The Technical Community chooses its own project management methodology, Development in each project is done in an agile fashion.
  • Developers placed in the community by a contributing institutional member will spend all their working time on priorities set by the project. They will not be primarily allocated to work on features demanded by their partner in the foundation, a basic principle of Agile development. It possible to place developers part time in the community, if the contributing institution has a need for institution specific developments/projects. This should be specified in the Contribution Agreement.
  • Discussions and decision in the TAB should be based on trust and consensus, not on votes and power. In a voting situation, every SAB member has one vote. Voting should be rare.

User Community

  • Each governed project will have its own Project User Community, formed by the subset of members who are "end users" of the governed software project.
  • Each project user community chooses among themselves a subset of members that can form the Scientific Advisory Board. All institutional members that are represented in the Project User Community should be represented on the Scientific Advisory Board.
  • The Scientific Advisory Board convene every month (online meeting) to discuss the progress of database and software development, prioritize features and bugs, identify outstanding issues that require intervention of the programmers or updates of the roadmap, exchange best practices for usage etc.
  • The Scientific Advisory Board appoints a Project Manager, whose responsibilities are to chair the user community meetings, to make sure discussed items are followed up with the Project Developer Community
  • The Scientific Advisory Board will make sure enough members are available to rigorously test incremental software updates to keep the Foundations progress as closely as possible to the Agile development principles.
  • For every major software product in the Foundation, the Scientific Advisory Board appoints a Product Liaison to which the programmers can refer if they have questions about implementation or usage of the product. The Liaison will clear major decisions with the Scientific Advisory Board.
  • Board Members of the Scientific Advisory Board represent the User Communities and act as liaisons between the User Communities and the Foundation where appropriate. The main aim is to bring in the main user requirements as material for the product roadmaps, and making sure that the roadmap is carried out consistently.
  • Discussions and decision in the SAB should be based on trust and consensus, not on votes and power. In a voting situation, every SAB member has one vote. Voting should be rare.

Project Approval and Shutdown procedures

  • New projects that are proposed will start as "proposed projects" under relaxed conditions.
  • Proposed projects will progress towards being a full project in the foundation within 12 months. If they do not succeed, the BOD will decide whether the period can be extended by another 6 months, repeatedly.
  • If the project is pre-existing institutional open source, all ownership must be transferred to the foundation before the project can be a full project in the foundation
  • Existing open source software projects that are compatible with the mission of the foundation can be suggested as candidate projects to be taken up by the Foundation.
  • The Board of Directors is the primary contact and decision making entity on these topics
  • Members can come and go over time.
  • If at any moment there would be only one independent member in a project, significant changes in the service level and/or development direction of the project must be approved by the BOD. Also, in this case, the project should be scheduled for transition to sleeping state in 6 months.

  • Projects can enter a sleeping state for indefinite periods whenever there are no members. The foundation will take over the minimal responsibilities to keep the software alive. The project may be shut down if no more interest is shown in development and/or significant efforts would be required to keep it alive. This is decided by the BOD alone.
  • There should be a ‘waiting room’ function and a ‘gatekeeper’ function in the foundation, connected to both advisory boards as well as to the executive level of the Foundation to deal with new software modules, data types and approaches proposed to the Foundation by the community. A careful consideration of each proposal to safeguard the bioinformatics, translational and life science focus of the Foundation will be critical.
  • code and license reviews
  • community assessment.

Funding agreements

  • The primary business model of the Foundation will be that any party that would like to have support for deployments of a governed open source project, or wants to see specific features or improvements on the roadmap of the project, has to enter into an agreement with the Foundation.
  • In such an agreement, the expected deliverables and timeline are made explicit, as well as the contribution of the partner to the foundation, either in financial support or in the form of developers that are placed within the Technical Community
  • The Foundation does not have the ambition to fulfil the need of pure Service Level Agreement support of software implementations. It will however actively engage with high quality service providers to make sure that this need is well addressed. Financial arrangements with such commercial service providers may well be explored as one of the sustainability pillars of the Foundation.
  • Dedicated end user training will be an important means to enlarge the user community and could eventually also be a modest source of income for the Foundation.
  • As it is unwise to rely on only one potential source of income, the Foundation will also engage as a co-applicant in future public and private funding opportunities aimed at generating relevant software packages.
  • Finally, the foundation may consider to allow ‘dual’ licensing for a fee of its Open Source software to commercial entities that wish to have a license for various reasons including deployment of the software in-house without the need to deposit newly developed code back into the Foundation. In principle the responsibilities coming to the foundation from any such arrangements will be taken up by the project.
  • Projects will pay 10% of raised funds(?) to the foundation so that it can maintain the common infrastructure and build up a reasonable financial reserve. This percentage can be lowered when the BOD decides that the financial reserve is high enough, and raised when the BOD and PRB decide that the financial reserve is too low or that more funding should be available to support the general actions of the foundation.

Foundation tasks outside of the projects

TODO

  • Marketing (?), Identity management, Central web site.
  • Project development services (Trac/Github/Wiki/??)
  • Financial management/Lobbying
  • Guarding funds for the projects
  • Offering legal advise for the projects (?)

TODO: Who performs these tasks? Where is funding from? 10% "internal tax" (see under funding)

Legal issues

  • TODO If a legal procedure is started against one of the projects, what do we do?
    • Notice and takedown?
    • Patent issues?
    • Copyright issues?
  • TODO Can we protect the foundation as a whole?
Last modified 6 years ago Last modified on Nov 22, 2012, 3:07:56 PM