Here we provide an overview of the mission, goals, and governance structure of the Zephyr Foundation for Advancing Travel Analysis Methods, as well as a narrative of the philosophy behind the Foundation and guidance for conducting Foundation business.
Contents:
- What is the Zephyr Foundation?
- The Foundation structure
- Individuals roles
- Project management
- The Foundation incubator
- Conclusions
The Zephyr Foundation is a 501(c)3 non-profit public charity organization incorporated in the United States of America, formed in 2017. The organization's mission is to advance rigorous transportation and land use decision-making for the public good by advocating for, facilitating, and supporting improved travel analysis and forecasting methods.
The Foundation serves as an independent legal entity to which community members can contribute code, ideas, methods, funding, and other resources, secure in the knowledge that their contributions will be maintained for public benefit.
To serve this mission, the Foundation has established the following goals:
-
Support. Provide robust infrastructure, including financial, administrative, and legal support.
-
Encourage. Encourage the use of open data standards, rigorous development practices, interoperability, reproducible research methods, and evaluation of research.
-
Incubate. Incubate innovative and useful planning methods in preparation for deployment by regions, cities, and neighborhoods.
-
Teach. Teach core competencies and next generation travel analysis skills to researchers and practitioners.
-
Guide. Guide research towards useful avenues and products.
-
Convene. Convene leading academics and practitioners to guide the Foundation’s efforts.
The Foundation is organized around projects, also referred to as communities. Projects focus on different aspects of travel demand modeling and data analysis, with the ultimate goal of supporting good planning outcomes. The Foundation therefore carries out its mission by executing projects, and by maintaining and sharing the products of these projects with the public. Projects undertaken by the Foundation should advance one or more of the Foundation's goals. The projects are conducted according to the etiquette and process established in the Bylaws and this narrative, and additional project-specific guidelines.
While participating in the Foundation's activities, which includes using its products, members, stakeholders and users agree to respect and follow the Foundation's processes and Bylaws, and to conduct themselves in a manner consistent with the Foundation's mission. Persons involved in the Foundation's activities do so in a personal capacity, and never as representatives of the organizations they otherwise work or advocate for. This means that users and contributors exercise good judgment in disclosing potential conflicts of interest, and also that members retain their Foundation roles and responbilities irrespective of changes in their work association.
The Foundation is governed by the following entities:
-
Board of Directors (Board), composed of members, which governs the Foundation.
-
Project Management Committees (PMC), which oversee projects. PMCs are composed of stakeholders, users, and members.
-
Officers of the corporation, which are nominated by the Board and elected by the membership, and who conduct the Foundation activities in specific areas (legal, financial, brand, fundraising, etc.).
-
Members, who elect the Board, and propose and/or vote on motions that set the Foundation policies and procedures.
The board is responsible for the management and oversight of the business and affairs of the corporation in accordance with the Foundation Bylaws. This includes management of the corporate assets (funds, intellectual property, trademarks, and support equipment) and allocation of corporate resources to projects.
The Board selects projects for funding and establishes the PMCs that will guide each project or community. The technical decision-making authority regarding the content and direction of the individual projects is not the responsiblity of the Board; instead, it is assigned to each respective PMC.
The Board has the faculty to terminate a PMC and/or replace a PMC chair at any time by resolution.
The Board is composed of seven individuals, elected by the members of the Foundation. Two to three members of the board are elected annually.
PMCs are established by resolution of the Board, to be responsible for the active management of one or more communities, which are also identified by resolution of the Board. Each project is delegated authority to design its own technical charter and its own governing rules. This delegation of technical guidance is intended to foster diversity of ideas and methods in the outcomes of the Foundation's activities. Project procedures must always comply with the Bylaws.
The primary role of each PMC is oversight -- not to develop the technical approach, but to ensure that all legal issues are addressed, that procedure is followed, and that each and every release is the product of the community as a whole. Successful execution of this oversight role is a key component of the Foundation's litigation protection mechanisms.
Each PMC is also tasked with furthering the long term development and health of the community as a whole, and ensuring that balanced and wide-scale peer review and collaboration happen. PMCs shall actively discourage communities centered around a two or three individuals who work without seeking broader input for long periods. We believe that this is detrimental to the quality, relevance, and robustness of products.
Each PMC is led by a chairperson, and in addition consists of at least one officer of the Foundation. The PMC may include one or more other members of the Foundation, at the discretion of the chair.
The chair of a PMC is appointed by the Board, has primary responsibility to the Board, and has the power to establish rules and procedures for the day-to-day management of the communities for which that PMC is responsible, including the composition of the PMC itself. Section 6.3 of the Bylaws define a PMC and the position of chair.
Members of PMCs are kept to a higher standard than all other members of the Foundation. This is because the PMCs and appointed chairs are directly responsible for the main activities carried out by the Foundation. The Board and the membership rely on each PMC to ensure that their corresponding communities always behave in a lawful manner, and in accordance to the Bylaws and the mission and goals of the Foundation.
The Zephyr Foundation takes many of its PMC ideas from the Apache Foundation. The Apache Developer Information is taken as guidance where specific Zephyr Foundation PMC guidance has yet to be established and there are no conflicts with Zephyr Foundation bylaws or other established governance.
The Officers of the Foundation oversee the day-to-day affairs of the Foundation. The officers are nominated by the Board of Directors and elected by the membership.
Persons are appointed as members on the basis of merit, for the evolution and progress of the Foundation. Members care for the Foundation itself. This is usually demonstrated through project-related and cross-project activities. Legally, a member is a "shareholder" of the Foundation; that is, one of its owners. Members have the right to elect the Board, to stand as a candidate for Board election and to nominate persons for membership. They also have the right to propose a new project for incubation. Members coordinate their activities through their mailing list and through their annual meeting.
The Foundation operates as a meritocracy; that is, it is governed by members selected on the basis of ability. And furthermore, governance responsibilities are accorded to individuals that have demonstrated commitment to contribute to the Foundation mission and goals.
Persons need not be Foundation members to participate in projects. Individuals can participate in project communities in the following capacities:
- Stakeholder
- User
- Contributor
- PMC member
- PMC chair
A stakeholder is someone that has an interest in the results of the project. They contribute to the Foundation projects by providing feedback to the PMC about the overall direction and needs of the project. Stakeholders participate in the Foundation community by serving as subject matter resources.
A user is someone that uses project products. Users can participate in the Foundation community by helping other users, for example in user support forums, or by providing feedback to the PMC.
A contributor is someone who contributes to a project in the form of data, code, analysis, ideas, reviews, methods, and/or documentation. Contributors are users that take extra steps to participate in a project, beyond simply being on the receiving end of the project products. Contributors are also known as developers.
A PMC member is a stakeholder or user appointed due to merit for the evolution of the project and demonstration of commitment. PMC members have write and owner-level access to the project files, an organization email address, and the right to vote on community-related decisions (including formal release of the project products). PMC members are appointed by the PMC chair.
Each PMC chair is appointed by the Board and is tasked with establishing rules and procedures for the day-to-day management of the project community, including the composition of their respective PMC.
Projects are managed using a collaborative, consensus-based process. The Foundation does not have a hierarchical structure. Rather, different groups of contributors have different rights and responsibilities in the organization.
Since PMCs have the authority to create their own self-governing rules, there is no single vision on how PMCs should run a project and the communities they host. At the same time, projects share the following recommended best practices:
Communication is done via email lists or messaging applications. These identify "virtual meeting rooms" where conversations happen asynchronously, to facilitate collaboration over multiple time zones and locations. Virtual meeting rooms can be a GitHub issue, an online shared document, or something else. Some projects may also use more synchronous messaging or video chats, again in the interest of effective and timely interaction. In general, asynchronous communication is preferred because it allows for archives to be created, and is more respectful of volunteers' time availability.
Each project is responsible for its own project website. Further examples to assist contributors and PMCs are available at Apache Infrastructure.
Projects are normally auto-governing and driven by the people who volunteer for the job. This is sometimes referred to as "do-ocracy" -- power of those who do. This functions well for most cases.
When coordination is required, decisions are taken with a lazy consensus approach: a few positive votes with no negative vote is enough to get going.
Voting is done with numbers:
+1 -- a positive vote
0 -- abstain, have no opinion
-1 -- a negative vote
A negative vote must include an alternative proposal or a detailed explanation of the reasons for the negative vote.
The community then tries to gather consensus on an alternative proposal that resolves the issue. In the great majority of cases, the concerns leading to the negative vote can be addressed.
This process is called "consensus gathering" and we consider it a very important indication of a healthy community.
Projects may have more detailed voting rules, at the discretion of the PMC chair.
The following principles, adopted from the Apache Foundation, describe how the Foundation projects are expected to be conducted:
-
Respectful, honest, technical-based interaction
-
Driven by usefulness
-
User-friendly packaging and licensing
-
Consistently high quality work products
-
Faithful implementation of standards
-
Lawfulness as a mandatory feature
All of the Foundation projects share these principles. Similarly, Foundation projects are required to govern themselves independently of undue commercial influence.
All projects are composed of volunteers and nobody (not even members or officers) are paid directly by the Foundation for their job -- though expenses for travel may be reimbursed. There are many examples of committers that are paid to work on the projects, but never by the Foundation themselves, but rather by companies or institutions that use the software and want to enhance it or maintain it.
The Foundation may contract out various services, including accounting, press and media relations, and infrastructure system administration.
All of the Foundation including the board, officers, contributors, and members are participating as individuals. That is one strength of the Foundation: affiliations do not cloud the personal contributions.
Unless they specifically state otherwise, whatever they post on any mailing list is done as themselves. It is the individual point-of-view, wearing their personal hat and not as a mouthpiece for whatever company happens to be signing their paychecks right now, and not even as a director of the Foundation.
Individuals working with the Foundation implicitly have multiple hats, especially the Board, the other officers, and the PMC chairs. They sometimes need to talk about a matter of policy, so to avoid appearing to be expressing a personal opinion, they will state that they are talking in their special capacity. However, most of the time this is not necessary -- personal opinions work well.
Project members are encouraged to conduct as much discussion in public as possible. This promotes openness, provides a public record, and stimulates the broader community.
However sometimes private communication is necessary. In such instances, information gained from private communications must never be divulged to other parties without the express permission of the original participants. Sharing private information is a serious breach of confidence that is detrimental to good faith collaboration. It could have serious ramifications and lead to confusion and ill-informed discussions.
Project members are encouraged to reserve private communication for matters that require confidentiality, such as certain legal matters, or matters pertaining to people as individuals.
There is special project that is tasked with assisting with the creation of new projects. This special project is called Incubator.
Since the meritocratic rules operate across the Foundation from bottom to top, it is vital for the long-term stability of such a form of government, that the initial set of committers has to know very well the dynamics of such a system, as well as share the same philosophical attitude toward collaboration and openness that the Foundation expects from its projects.
The Incubator is responsible for:
-
Filtering new project proposals
-
Marshalling the resources new projects need to develop
-
Supervising and mentoring the incubated community to help them reach a meritocratic environment
-
Evaluating the maturity of the incubated project, and either promoting it to official project/ sub-project status or retiring it when it fails to thrive.
The Incubator (just like the Board) does not perform filtering on the basis of technical approach. This is because the Foundation encourages technical diversity as a pathway to useful innovation. The Incubator filters projects on the basis of their likeliness of becoming successful meritocratic communities. Example requirements for incubation are:
-
A working codebase -- the experience of the Apache Foundation has been that it is generally hard to bootstrap a community without a working code base. This is because merit is not well recognized by developers without a working codebase. Also, the friction that develops during the initial design stage is likely to fragment the community.
-
The intention to donate copyright of the software and the intellectual property that it may contain to the Foundation -- this allows the Foundation to obtain an irrevocable and permanent right to redistribute and work on the code, without fearing lock-in for itself or for its users.
-
A sponsoring Foundation member -- this person acts as the main mentor, giving directions to the project, helping out in the day-to-day details and keeping contact with the Incubator PMC.
The incubation period normally serves to estimate whether or not the project is able to increase the size and diversity of its contributor base, and function within the meritocratic rules of the Foundation. It might seem rather easy to achieve, but it must be remembered that in a volunteer and highly selective environment, attracting new contributors is not automatic.
Contributor diversity is important for two main reasons:
-
It gives long term stability to the project development; in fact, with all the developers affiliated to the same entity, the chance of seeing all of them moving away from the project at the same time is much greater than with a community of individuals affiliated to unrelated entities.
-
It gives a greater variety of technical visions, which promotes better adherence to user's needs, thus a higher chance of resulting in useful products.
The Apache Foundation represents one of the best examples of an open organization that has found balance between structure and flexibility. We hope to emulate their success here. We strive to find balance between openness and economic feasibility. We hope to inspire agents across the broad planning community to collaborate selflessly, disinterestedly and effectively.