Mostly lifted from the Apache Foundation
This page gives an overview of the proposed foundation structure: the difference between membership and committership, who decides what, how elections take place, how infrastructure is set up, what is the board, what is a Project Management Committee, and what's the philosophy behind the incubator.
Contents:
- What is the (ITM) Foundation?
- A bit of history
- Meritocracy
- The Foundation structure
- Roles
- Project management
- The Foundation Infrastructure
- The Foundation Incubator
- Other Foundation entities
- Conclusions
The foundation is a 501(c)3 non-profit public charity organization incorporated in the United States of America and was formed in 2016. The organization advocates, facilitates, and supports the modernization of the travel analysis industry to be responsive to stakeholder needs.
This foundation was formed out of an on-going need identified by urban planning practitioners across the nation to focus on innovation rather than rebuilding the same tools over and over again. This foundation will serve as an independent legal entity to which community members can contribute code, 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:
-
Serve as a clearinghouse of useful planning tools and methods and an incubator for development of innovative planning methods that can be applied in regions, cities, and neighborhoods across the country.
-
Provide critical infrastructure (legal, funding, hosting) to support the development of useful planning tools and methods.
-
Guide research toward useful outcomes for stakeholders.
-
Ensure tools developed under its guidance meet the most stringent software engineering and quality control standards.
-
Encourage the use of open data standards and interoperability across planning tools and related products.
-
Teach basic core competency in modern travel analysis skills, through workshops, online materials, and training.
-
Convene an initial conference to launch the first tranche of supported initiatives, possibly in cooperation with related efforts (e.g., TRB).
(to be added)
No one model can possibly be the "One True Model" for all stakeholders. Thus, there is a need for multiple projects to advance in parallel. Those projects can grow in market share and popularity, and can focus on different aspects of modeling and data analysis in support of good planning outcomes. These projects need to be united by a common set of goals and a respected set of traditions in both etiquette and process.
These separate communities are referred to as "projects" and while similar, each of them exhibit little differences that make them special.
In order to reduce friction and allow for diversity to emerge, rather than forcing a monoculture from the top, the projects are designated the central decision-making organizations of the ITM foundation world. Each project is delegated authority over development of its software and data, and is given a great deal of latitude in designing its own technical charter and its own governing rules.
The foundation is governed by the following entities:
-
Board of Directors (board) governs the foundation and is composed of members.
-
Project Management Committees (PMC) govern the projects, and they are composed of stakeholders, users, and members.
-
Various Officers of the corporation, appointed by the board, who set Foundation-wide policies in specific areas (legal, brand, fundraising, etc.)
The board is responsible for 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.
However, technical decision-making authority regarding the content and direction of the individual projects is assigned to each respective project management committee.
The board is initially composed by (seven) individuals, elected between the members of the foundation. The bylaws don't specify the number of officers that the board should have. The board is elected every year.
The board website has more information, the list of the current directors, schedule of meetings, and past minutes.
The Project Management Committees 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 PMC consists of at least one officer of the foundation, one chairperson, and may include one or more other members of the foundation.
The chair of the 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 the PMC is responsible, including the composition of the PMC itself.
The foundation Bylaws (section 6.3) define a PMC and the position of chair. The role of the PMC from a Foundation perspective is oversight. The main role of the PMC is not code and not coding - 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. That is key to our litigation protection mechanisms.
Secondly the role of the PMC is to further the long term development and health of the community as a whole, and to ensure that balanced and wide scale peer review and collaboration does happen. Within the foundation we worry about any community which centers around a few individuals who are working virtually uncontested. We believe that this is detrimental to quality, stability, and robustness of both code and long term social structures.
We firmly believe in hats. Your role at the foundation is one assigned to you personally, and is bestowed on you by your peers. It is not tied to your job or current employer or company.
However those on the PMC are kept to a higher standard. As the PMC, and the chair in particular, are eyes and ears of the foundation Board, it is you that we rely on and need to trust to provide legal oversight.
The board has the faculty to terminate a PMC at any time by resolution.
The Apache Developer Information pages have many more details of how PMCs work. A complete list of all foundation projects is also available.
The Officers of the foundation oversee the day-to-day affairs of the Foundation. The officers are elected by the Board of Directors.
The meritocracy typically has various roles within each individual project community:
- stakeholder
- user
- contributor
- associate
A stakeholder is someone that has an interest in the results of the project in order to better accomplish their job. 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 a subject matter resource.
A user is someone that uses our project. They contribute to the foundation projects by providing feedback to developers in the form of bug/error reports and feature suggestions. Users participate in the foundation community by helping other users in user support forums.
A developer is a user who contributes to a project in the form of data, code, analysis, and documentation. They take extra steps to participate in a project, are active on the developer mailing list, participate in discussions, provide patches, documentation, suggestions, and criticism. Developers are also known as contributors.
An associate is a contributor that was given management access to the project files ( including code repositories if applicable ) and has a signed Contributor License Agreement (CLA) on file. They have a foundation mail address. Not needing to depend on other people for the patches or small changes, they are actually making short-term decisions for the project. The PMC can (even tacitly) agree and approve it into permanency, or they can reject it. Remember that the PMC makes the decisions, not the individual associate.
A PMC member is a stakeholder, contributor or associate that was elected due to merit for the evolution of the project and demonstration of commitment. They have write and owner-level access to the project files, an organization email address, the right to vote for the community-related decisions and the right to propose an active user for associateship. The PMC as a whole is the entity that controls the project, nobody else. In particular, the PMC must vote on any formal release of their project's products.
The Chair of a Project Management Committee (PMC) is appointed by the Board from the PMC Members. The PMC as a whole is the entity that controls and leads the project. The Chair is the interface between the Board and the Project. PMC Chairs have specific duties.
A foundation member is a person who was nominated by current members and elected due to merit for the evolution and progress of the foundation. Members care for the foundation itself. This is usually demonstrated through the roots of project-related and cross-project activities. Legally, a member is a "shareholder" of the foundation, one of the owners. They have the right to elect the board, to stand as a candidate for the board election and to propose a committer for membership. They also have the right to propose a new project for incubation (we'll see later what this means). The members coordinate their activities through their mailing list and through their annual meeting. We have a full listing of members.
The foundation projects are managed using a collaborative, consensus-based process. We do not have a hierarchical structure. Rather, different groups of contributors have different rights and responsibilities in the organization.
Since the appointed Project Management Committees have the power 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, while there are some differences, there are a number of similarities shared by all the projects and best practices that are suggested:
Communication is done via emailing lists. These identify "virtual meeting rooms" where conversations happen asynchronously, which is a general requirement for groups that are so geographically distributed to cover all time zones (like it's normally the case for the various foundation communities). Virtual meeting rooms can be a GitHub issue, an online shared document, or something else.
Some projects additionally use more synchronous messaging or video chats (for example, instant messaging, skype, or google hangout).
In general, asynchronous communication is much more important because it allows archives to be created and it's more tolerant on the volunteer nature of the various communities.
Each project is responsible for its own project website. Further information to assist committers, developers, and PMCs is available at [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
The rules require that a negative vote includes 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.
Specific cases have some more detailed voting rules.
While there is not an official list, these six principles have been cited as the core beliefs of philosophy behind the foundation, which is normally referred to as "The Apache Way" and have been adapted for this Foundation:
-
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. 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.
Note that the foundation does contract out various services, including accounting, Press and Media relations, and infrastructure system administration.
All of the foundation including the board, the other officers, the committers, and the 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.
All of those foundation people 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.
Some people declare their hats by using a special footer to their email, others enclose their statements in special quotation marks, others use their apache.org email address when otherwise they would use their personal one. This latter method is not reliable, as many people use their apache.org address all of the time.
We endeavor to conduct as much discussion in public as possible. This encourages openness, provides a public record, and stimulates the broader community.
However sometimes internal private mail lists are necessary. You must never divulge such information in public without the express permission of the list. Also never copy an email between private and public lists (no Cc). Such an event would go beyond the normal need for email ettiquette and be a serious breach of confidence. It could have serious ramifications, cause unnecessary confusion and ill-informed discussion.
Private lists are typically only used for matters pertaining to people as individuals (like voting in new committers), and legal matters that require confidentiality.
In order for new projects to be created, the foundation created a project called Incubator which is responsible to help new efforts to join the foundation.
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 the proposals about the creation of a new project or sub-project
-
help the creation of the project and the infrastructure that it needs to operate
-
supervise and mentor the incubated community in order for them to reach an open meritocratic environment
-
evaluate the maturity of the incubated project, either promoting it to official project/ sub-project status or by retiring it, in case of failure.
It must be noted that the incubator (just like the board) does not perform filtering on the basis of technical issues. This is because the foundation respects and suggests variety of technical approaches. It doesn't fear innovation or even internal confrontation between projects which overlap in functionality.
The incubator filters projects on the basis of the likeliness of them becoming successful meritocratic communities. Example requirements for incubation are:
-
a working codebase -- over the years and after several failures, the foundation came to understand that without an initial working codebase, it is generally hard to bootstrap a community. This is because merit is not well recognized by developers without a working codebase. Also, the friction that is developed 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 or officer -- this person will act 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 diversity of its committer base and to play with 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 committers is not automatic.
Diversity of associateship 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: something that guarantees a better adherence to environment and user's needs, thus a higher change of finding real-life use of the software.
Along with the Incubator, the foundation has several other cross-foundation projects.
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 economical feasibility. We hope to continue to provide inspiration for businesses, governments, education, and for other foundations.