Difference between revisions of "How it Works"

Latest revision as of 17:16, 24 April 2007

How the ADempiere Foundation works

This page will give you everything you always wanted to know about the foundation but were afraid to ask. The difference between membership and committership, who decides what, how elections take place, how is our infrastructure setup, what is the board, what is a PMC, what's the philosophy behind the incubator. Come and see behind the scenes of the Adempiere Foundation. Based on the similar goals and success of the Apache Foundation, we seek to stand on their shoulders and adopt many of their methods. We thank them for sharing their organizational structure and hope to put it to equally good use within the ADempiere Bazaar.

What is the ADempiere Foundation?

The ADempiere Foundation (AF) is a 501(c)3 non-profit organization incorporated in the United States of America and was formed primarily to:

• provide a foundation for open, collaborative ERP software development projects by supplying hardware, communication, and business infrastructure
• create an independent legal entity to which companies and individuals can donate resources and be assured that those resources will be used for the public benefit
• provide a means for individual volunteers to be sheltered from legal suits directed at the Foundation's projects
• protect the ‘ADempiere’ brand, as applied to its software products, from being abused by other organizations

That's the dry fact, but how did all this come to be and what does it really mean in its details? We need to step back a little in history.

History of ADempiere

Meritocracy

ADempiere originated as a community effort to sustain the support and development of the open source Compiére ERP project. As such, the founding individuals knew each other from participation in the Compiére forums and through contributions to the project. As the community rallied into Sourceforge, ADempiere rose higher and higher in the project rankings. More people were attracted and started to help out, first by asking questions in the forums, then by sending little patches, or suggestions, later by more important contributions.

When the group felt that newcomers had "earned" the merit to be part of the development community, they granted direct access to the code repository, thus increasing the group and increasing the ability of the group to develop the program, and to maintain and develop it more effectively.

We call this basic principle "meritocracy": literally, govern of merit.

What is interesting to note is that the process scaled very well without creating friction, because unlike in other situations where power is a scarce and conservative resource, in the ADempiere Bazaar newcomers were seen as volunteers that wanted to help, rather than people that wanted to steal a position.

Being no conservative resource at stake (money, energy, time), the group was happy to have new people coming in and help, they were only filtering the people that they believed committed enough for the task and matched the human attitudes required to work well with others, especially in disagreement.

After explaining the structure of the ADempiere Foundation, we will see how the meritocracy relates to the various roles.

The Foundation Structure

As ADempiere started to grow in popularity, due to synergy of its flexible business process architecture, technical merit and to the openness of the community behind the project, people started to create satellite projects. Influenced by the spirit of the community they were used to, they adopted the same traditions of community management.

So, by the time the ADempiere Foundation was created, there were several separate communities, each beginning to self-organize in order to achieve a different objective, but all united by a common set of goals and a respected set of cultural traditions in both etiquette and process. ERP software sits at the top of the IT stack, and therefore, requirements come in technically, from business requirements, localized language, legal, and taxation issues, and finally from the consulting entities that support and install the software.

These separate communities can be referred to as "projects" and while similar, each of them exhibited little differences that made 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 ADempiere world. Each project is delegated authority over it’s area of interest and expertise, and is given a great deal of latitude in designing its own charter and its own governing rules. At the same time, the cultural influence of the original ADempiere group was strong and the similarities between the various communities are evident, as we'll see later.

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 contributing members.

Board of Directors (board)

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, decision-making authority regarding the content and direction of the ADempiere projects is assigned to each respective project management committee.

The board is currently composed by nine individuals, elected between the members of the foundation. The bylaws don't specify the number of officers that the board should have, but historically, this was the number of the first board and it has never changed. The board is elected every year.

The board website has more information, the list of the current directors, schedule of meetings, and past minutes. Project Management Committees (PMC)

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 AF, who shall be designated chairperson, and may include one or more other members of the AF.

The chair of the PMC is appointed by the Board and is an officer of the AF (Vice President). The chair 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. See further discussion about the role of PMC chair and why chairs are officers.

The AF Bylaws (section 6.3) define a PMC and the position of chair. Some emails from the experiences of the Apache foundation help to clarify: here and here the intent of this role.

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 AF 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 AF 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 AF 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.

Officers

The Officers of the ADempiere Foundation oversee the day-to-day affairs of the Foundation. The officers are elected by the Board of Directors.

Roles

The meritocracy enables various roles:

• User

user is someone that uses our software. They contribute to the projects by providing feedback to developers in the form of bug reports and feature suggestions. Users participate in the community by helping other users on mailing lists and user support forums. The passive users are also known as lurkers.

• Developer

developer is a user who contributes to a project in the form of code or 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.

• Committer

committer is a developer that was given write access to the code repository and has a signed Contributor License Agreement (CLA) on file. They have an adempiere.org mail address. Not needing to depend on other people for the patches, 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 people.

• PMC Member

PMC member is a contributor that was elected due to merit for the evolution of the project and demonstration of commitment. They have write access to the code repository, an adempiere.org mail address, the right to vote for the community-related decisions and the right to propose an active user for committership. The PMC as a whole is the entity that controls the project, nobody else. ADempiere Foundation Member

• AF member is a person that was nominated by current members and elected due to merit for the evolution and progress of the foundation. Members care for the AF 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 contributor for membership. The members coordinate their activities through their mailing list and through their annual meeting.

Project Management and Collaboration

The ADempiere 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:

Communication

Communication is done via open forums or mailing 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 ADempiere communities). Some projects additionally use more synchronous messaging (for example, IRC or instant messaging). Voice communication is extremely rare, normally because of costs and the language barrier (speech is harder to understand than written text). 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.

Decision Making

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.

Philosophy

While there is not an official list, these six principles have been cited as the core beliefs of philosophy behind the foundation. With the exception of the licensing standards, these where pioneered and defined in the Apache Software Foundation, and we are grateful for their guidance:

• collaborative software development
• GPL license
• consistently high quality software
• respectful, honest, technical-based interaction
• faithful implementation of standards
• security as a mandatory feature

All of the AF projects share these principles.

Operation

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.

Individuals compose the AF

All of the AF including the board, the other officers, the committers, and the members, are participating as individuals. That is one strength of the AF, 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 AF.

All of those AF 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 adempiere.org email address when otherwise they would use their personal one. This latter method is not reliable, as many people use their adempiere.org address all of the time.

Balancing confidentiality and public discussion

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 etiquette and be a serious breach of confidence. It could have serious ramifications, cause unnecessary confusion and ill-informed discussion.

The Foundation Infrastructure

The AF does not have offices or buildings, it's a virtual entity that exists only on the internet. It's only physical existence is the technical infrastructure that enables it to operate. The AF Infrastructure is mostly composed of the following services:

• the web serving environment (web sites and wikis)
• the code repositories
• the mail management environment
• the issue/ bug tracking
• the distribution mirroring system

The AF has an "infrastructure" team that is responsible for the management and day-to-day system administration and operation of the various hardware that runs the above services. Some of the members of the infrastructure team volunteer to be "on call" and be paged in case a system goes down.

The infrastructure team is also responsible for approving the installation of a new system or software on the AF machines.

The Foundation Incubator

In order for new projects to be created, the AF created a project called Incubator which is responsible to help new efforts to join the foundation.

Since the meritocratic rules operate across the AF 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 AF 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. The basic 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 AF 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 committership 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.

Other Foundation Entities

After infrastructure and incubator, the foundation hosts several other entities more or less formalized open to AF members and to invited experts or individuals that do not directly create code but serve for specific purposes. They are:

• the commit committee -- responsible for reviewing and managing commits to the ADempiere trunk
• the security committee -- (proposed) responsible for the handling of potential security holes in the software produced by the foundation that might impact our users. It gets contacted by the finders of the problems before the problem report is made available to the public, to allow the projects to provide a fix in time for the report, thus reducing vulnerability to a minimum
• the business development committee (BDC) – We in the ADempiere project clearly understand that an ERP is not a technical solution but applied to a business case. As a result we know that the ADempiere Project cannot be successful if the application suite is not implemented by businesses successfully and effectively providing business owners excellent returns on their investment of time, effort and fees. Therefore, the ADempiere project created the BDC, formed among members with extensive business experience in implementing ERP solutions worldwide. The BDC operates as a very large virtual consulting house where, that pre-qualifies requests and identifies appropriate local ADempiere service providers for consideration.
• the ADempiere Business Alliance (ABA) -- (proposed) The ABA is a committee designed to seek out and manage strategic business alliances that can be beneficial to the growth of the ADempiere Community

Voting