Project Charter
Note
Status: This is page is obsolete and under review!
Overview
This document is a "work in progress". This proposal has been created by a few members but has not yet been approved or voted on by the community as a whole i.e. it does not necessarily represent the current views of the Community yet.
Currently it only describes the ADempiere Project.
Discussion
This page and the Best Practice page is under live discussion by the Round Table.
If you wish to edit anything here, please wait for official resolution from the 2nd European ADempiere Conference now in session.
However you may continue discussion over any points here at the Project Charter.
Introduction
The ADempiere Project is a community-based open source software development project dedicated to give members of the expert community a versatile platform, open model and means to provide a robust, full-featured, commercial-quality, and freely available industry suite of Enterprise Resource Planning ("ERP"), Supply Chain Management ("SCM") and Business ("Biz") applications. This document describes the overview, code of conduct, and project management of it.
Concept
The concept here of community-based is that the originators precisely are so and intend to keep it so. Even though the community came about originally from Compiere ERP/SCM Project in SourceForge, and the code base is derived from there, the ADempiere Project believes that the spirit of Open Source as to uphold the Bazaar model in stark contrast to the Cathedral model which was the direction the original project was driven to. In providing to an assured user base of implementors, subject matter experts and end-users, the ADempiere Project strives to provide all knowledge base free in its own wiki, including choice information of doing business using ADempiere.
By becoming a strong and well supported project, ADempiere becomes the base product for implementors and vendors that sells services around it to operate in a confident and stable environment.
Culture
A culture is set initially by the SourceForge-Compiere community merely wanting to share their work in an updated and unified code base. The community spirit ensures no single entity controls that. Thus the initial registration of the domain names was amicably entrusted among its advocates, namely www.adempiere.org goes to Redhuan D Oon , adempiere.com goes to CarlosRuiz, ADempiereforge goes to Trifon Trifonov and the SourceForge-Adempiere goes to Victor Perez, and so forth. In due time, all this collaterals including logo, branding, commercial platform has to be regulated to remain the property of the community and the Council members as mere trustees governed by law.
The manner and lightning pace ADempiere was formed is demonstrative of the resourcefulness expected of a proper Bazaar. The Forking Debate, resolution, introduction of the namesake with his philosophy, slogan, its wikipedia page and other infrastructure was done from start to finish, timestamped in the forum in matter of days as can be seen from the content of the stated domains.
Nevertheless, the applications that are the end-products of this community are meant to serve a much larger worldwide audience of business users that demand a culture of professionalism and organisation that is competitive with other vendor brands such as SAP, JDE, Oracle and Microsoft. Thus members of the community are encouraged and facilitated to sell their own service-based products in a laisserz faire Bazaar fashion.
No favoritism is allowed, either by way of patronage, subscription or membership. The leadership set this up, and gets out of the way. For organisational purposes, the community is represented by an ADempiere Council with a leader chosen by peers and in open forum. In Bazaar sense, further organisation is organic, fluid and self-determined.
ADempiere Principles
In line with the above aspirations the ADempiere Project will have to adhere to clear and strong principles.
Non-Profit
ADempiere shall operate as a non-profit organisation, and not support any commercial enterprise directly, favourably or exclusively except where such association is in futherance of the philosophy and culture described in this Charter. In this respect the Council shall set up a Trust Foundation to administer the formal nature of the organisation.
Contributors Right To Submit
The ADempiere Council and administrators are entrusted to facilitate and manage this project. They must never refuse any contribution that is fair and useful to the codebase. Any contribution or comment can be submitted in proper procedure as adviced by the respective administrators. All submission must honour the creators efforts and any infringement must be corrected within the code and not mean rejection of the code itself for such omission or error of copyright statement. Contributors stand the chance and opportunity to advertise their contributions within ADempiere and their businesses, and among their clientele. Recognised contributors may receive the right of displaying the ADempiere logo and other benefits to assist to that regard.
Support Of Business Partners
ADempiere shall regard interested vendors and implementors as keen supporters of the Project and shall lend any assistance to allow their succesfull implementation of ADempiere applications among their clients. Adempiere does this by ensuring that the codebase is clean and well updated with submissions and corrections by contributors. Business Partners may contribute through donations or services in kind, that are published and accepted by the Council under clear principle of non-patronage for such contribution.
Submission To Law
The ADempiere Project and its Council has highest regard for the natural and universal Law of authorship, encompassing the present Licensing Laws as professed commonly in the software industry. It will regard any infringement as a serious breach of code of conduct and disassociate itself from any such acts, and shall make amends to aviod any implications to its Charter.
Acceptance of Contributions
ADempiere shall accept contributions from any party as long as it is not in contravention of its Charter and not subjugated to support any particular commercial enterprise or branding. Contributions made to it can be declared openly or kept private as to its real author but stated in the books of the Trust Foundation.
Contributions made must be free from conditions and may be in kind such as premises, web-hosting, sponsorships of events and particular modules of the software.
Project Management
Mission
The community unabatedly contribute to ADempiere a milieu of application stacks comprising of a number of core model codebases with vertical and integrated addons catering to various and specific industries spanning across trading, organising, manufacturing, service and automation sectors. It intends to be modular and configurable for end-users to pick and choose their needed application. Rather than a "one size fits all", it aims to give "more sizes fit more better". It learns from the mistakes of its predecessor and improve into areas such as more up-to-date architecture, database independence, improved reporting tools, open migration tools and open documentation.
The potential of this project is the explosive growth proven and expected of the community's energy and effort that is self-driven rather than single-handedly run. Emphasising more on the community spirit that originally has given alot to Compiere, it now provides a critical mass of resources to expand in all directions and denominated enough for each and every application needed by the world.
The Project Roadmap draws out the technical challenges and issues for resolution within the Compiere suite. It emphasises use of the latest advancements in application design and development.
Direction and vision of mission... defining what it wants in the future...
Scope
Elements of the software environment.
Council
The ADempiere Council is comprised of pioneer founders of the ADempiere Community. Their overall goal is to uphold the principles of the project charter and foster a positive bazaar-like spirit.
Responsibilities
- Serve as liaison with the world in representation of the project
- Approve and uphold the governance rules of the project
- Promote an open bazaar like environment in all the project structure
- Legal representation of project corporate entities
- Define strategic direction of the project
- Progress and endorse partnerships with commercial entities that support the principles and objectives of the project
- Hold and protect project assets (passwords, domains, etc)
- Provide leadership in guiding difficult decisions, resolving problems, removing roadblocks
- Set a fine example for the community in professional conduct and a contributive spirit
Current Members
See Council
Project Management Committee
See details here
Roles
The Projects under this Charter are operated as meritocracies -- the more you contribute, and the higher the quality of your contribution, the more you are allowed to do. However with this comes increased responsibility.
Users
Users are the people who use the products that the Project produces. People in this role aren't contributing code, but they are using the products, reporting bugs, and making feature requests and suggestions. Users are encouraged to participate through the user newsgroup(s), asking questions, providing suggestions, and helping other users. Users are also encouraged to report problem reports using the bug tracking system.
Developers
Users who contribute code or documentation become developers. Developers are the people who contribute code, fixes, documentation, or other work that goes into the product. Developers are also encouraged to participate in the user newsgroup(s), and should monitor the developer mailing list associated with their area of contribution. When appropriate, developers may also contribute to development design discussions related to their area of contribution. Developers are expected to be proactive in reporting problems in the bug tracking system.
Committers
Developers who give frequent and valuable contributions to a Project, or component of a Project (in the case of large Projects), can have their status promoted to that of a "Committer" for that Project or component respectively. A Committer has write access to the source code repository for the associated Project (or component), and gains voting rights allowing them to affect the future of the Project (or component).
In order for a Developer to become a Committer on a particular Project overseen by the PMC, another Committer for the same Project (or component as appropriate) can nominate that Developer or the Developer can ask to be nominated. Once a Developer is nominated, the Committers for the Project (or component) will vote. If there are at least 3 positive votes and no negative votes, the Developer is recommended to the PMC for commit privileges. If the PMC also approves, the Developer is converted into a Committer and given write access to the source code repository for that Project (or component). Becoming a Committer is a privilege that is earned by contributing and showing discipline and good judgement. It is a responsibility that should be neither given nor taken lightly.
At times, Committers may go inactive for a variety of reasons. The decision making process of the Project relies on active committers who respond to discussions and votes in a constructive and timely manner. The PMC is responsible for ensuring the smooth operation of the Project. A Committer that is disruptive, does not participate actively, or has been inactive for an extended period may have his or her commit status removed by the PMC.
Active participation in the user newsgroup and the appropriate developer mailing lists is a responsibility of all Committers, and is critical to the success of the Project. Committers are required to monitor and contribute to the user newsgroup.
Committers are required to monitor the developer mailing list associated with all Projects and components for which they have commit privileges. This is a condition of being granted commit rights to the Project or component. It is mandatory because committers must participate in votes (which in some cases require a certain minimum number of votes) and must respond to the mailing list in a timely fashion in order to facilitate the smooth operation of the Project. When a Committer is granted commit rights they will be added to the appropriate mailing lists. A Committer must not be unsubscribed from a developer mailing list unless their associated commit privileges are also removed.
Committers are required to track, participate in, and vote on, relevant discussions in their associated Projects and components. There are three voting responses: +1 (yes), -1 (no, or veto), and 0 (abstain).
Committers are responsible for proactively reporting problems in the bug tracking system, and annotating problem reports with status information, explanations, clarifications, or requests for more information from the submitter. Committers are responsible for updating problem reports when they have done work related to the problem.
Projects
The work under this Top Level Project is further organized into Projects. New Projects must be significant works consistent with the mission of the Top Level Project, be recommended by the PMC, and confirmed by the EMO. Projects can be discontinued by decision of the Board.
When a new Project is created, the PMC nominates a Project lead to act as the technical leader and nominates the initial set of Committers for the Project, and these nominations are approved by the EMO. Project leads are accountable to the PMC for the success of their Project.
Project Components
The PMC may decide to divide a Project further into components. If a Project is divided into components, commit privileges are normally granted at the component level, and the committers for a given component vote on issues specific to that component. Components are established and discontinued by the PMC. When the PMC creates a component it appoints a component lead to act as the technical leader and names the initial set of Committers for the component. The component lead is designated as a committer for the Project and represents the component in discussions and votes pertaining to the Project as a whole. Component Committers do not participate in votes at the level of the Project as a whole, unless they are also the component lead.
Ports
For components that contain platform-specific code (such as SWT), it may be advantageous to allow developers to work on a port of the component to a new platform without requiring that they already be committers for the component. In this case the main code base is known as the component "core", and the port code base is known as a component "port". The decision to set up a port is made by the PMC. When a new port of a component is created, the PMC appoints a Port Lead, and an initial set of committers who will have commit and voting privileges specifically for the port. The port is done under the auspices of the core component, and all committers for the core component automatically also have commit and voting privileges on the port. Normally the Component Lead will also be the Port Lead.
Infrastructure
The PMC works with the EMO to ensure the required infrastructure for the Project. The Project infrastructure will include, at minimum:
Bug Database - Bugzilla database for tracking bugs and feature requests. Source Repository -- One or more CVS repositories containing both the master source code and documentation for the Projects. Website - A website will contain information about the Project, including documentation, downloads of releases, and this Charter. General Mailing List - Mailing list for development discussions pertaining to the Project as a whole or that cross Projects. This mailing list is open to the public. Project Mailing Lists - Development mailing list for technical discussions related to the Project. This mailing list is open to the public. Component Mailing Lists -- Development mailing list for technical discussions related to the component. This mailing list is open to the public. The Development Process Each Project lead must produce a development plan for the release cycle, and the development plan must be approved by the PMC and by a majority of Committers of the Project.
Each Project must identify, and make available on its web site, the requirements and prioritizations it is working against in the current release cycle. In addition, each Project must post a release plan showing the date and content of the next major release, including any major milestones, and must keep this plan up to date.
The Committers of a Project or component decide which changes may be committed to the master code base of a Project or component respectively. Three +1 ('yes' votes) with no -1 ('no' votes or vetoes) are needed to approve a code change. Vetoes must be followed by an explanation for the veto within 24 hours or the veto becomes invalid. All votes are conducted via the developer mailing list associated with the Project or component.
Special rules may be established by the PMC for Projects or components with fewer than three Committers. For efficiency, some code changes from some contributors (e.g. feature additions, bug fixes) may be approved in advance, or approved in principle based on an outline of the work, in which case they may be committed first and changed as needed, with conflicts resolved by majority vote of the Committers of the Project or component, as applicable. More restrictive rules for releasing changes may be established by the PMC near the end of release cycles or for maintenance streams.
The master copy of the code base must reside on the Project web site where it is accessible to all users, developers and committers. Committers must check their changes and new work into the master code base as promptly as possible (subject to any check-in voting rules that may be in effect) in order to foster collaboration among widely distributed groups and so that the latest work is always available to everyone. The PMC is responsible for working with the Eclipse Foundation to establish a release engineering and build process to ensure that builds can be reliably produced on a regular and frequent basis from the master code base and made available for download from the Project web site.
The PMC is responsible for establishing the level of testing appropriate for each Project, and approving the test plans.
All development technical discussions are conducted using the development mailing lists. If discussions are held offline, then a summary must be posted to the mailing list to keep the other committers informed.
Licensing
All contributions to Projects under this Charter must adhere to the ADempiere Project Intellectual Property Policy.
Part II
(hereby continuing original work of ADempiere Council..)
Community Process (todo)
ADempiereForge Strategy During the initial stage of forking, the strategy of source codes committed to our SourceForge is to maintain the present latest versions in use by Compiere users such as 253b where bug fixes are done and committed to SVN.
Other variants or forks of Compiere are housed as separate projects according to their respective owners. The subsequent version and addons of ADempiere will rest on the further work of architects from the various projects' teams.
Marketing There is a marketing roadmap to establish ADempiere ERP/CRM/SCM as a viable business suite for commercial and production use.
Partnership Alliance If there be any partnership alliance with any commercial entity outside ADempiere, ...
ADempiere Structure
- The structure of ADempiere
- Reasons for structuring ADempiere
- Community discussion
There is some discussion on the proposed structure of ADempiere here.
Political
(to be discussed in talk page if it is not in agreement as this is only a quick expedient suggestion)
- This section is meant to be more legal standing than the above sections for project administering purposes.
- It is meant to provide legal certainty and ensure minimal law and order in its due process of natural justice.
- It is not meant to be too legalistic and any semantic or literal argument beyond the necessary is frown upon as cumbersome and impractical.
- It applys the English Common Law's Mischief Rule which is, "What if this law did not exist? Would it now remove that mischief before it?".
Office Bearers
The bearers of office are:
- Founding Council & Leader
- PMC & Head
- CC & Head
- Security Head
- Project Admins
- Webmaster
- Wikimaster
- Branch Leaders
The executive administraton of the project falls under the purview of the PMC and CC which are subjected to periodic elections from the community.
The PMC in turn can appoint or remove Project Admins and other lesser officers.
PMC and Commit Committee Policy
- PMC (Project Management Committee) and CC (Commit Committee) may overrule decisions based on technical and urgent situations. In case of conflict with the general community, the PMC may hold an open meeting and only PMC members can vote on the outcome.
- Community members must abide by rulings of the PMC and CC.
- PMC may overrule a feature acceptance or stable/non-stable status of any feature.
- CC may overrule a trunk (stable) commit decision. It may ask the committer to revert successfully failing which it can suspend that committer's right for a short period.
- Repeat offenders may be subjected to community decision and voting for permanent suspension.
PMC and CC membership Policy
- PMC and CC members may be suggested and voted in by general community based on their merit and contributions.
- There should not be a single negative vote from any PMC and CC member to a nominee (to avoid poison and disruption to the ongoing work).
- If there is a negative vote, the nominator/nominee should address the negativity underlying reasons and try for a nomination again at a later date.
- Thus though rulings within PMC/CC may be democratic but joining it is not. It has to be meritocracy in order to join the PMC and CC.
Community Elections
- Thus it is clear that the Community Is Supreme in that it can in a community elections vote in leaders and also vote out leaders in the following elections.
- If any community member wishes to make changes to PMC and CC membership, can only do so via community elections and any other actions will be deemed illegal.
- Only the Council or Leader can call for a community elections, failing which a public outcry can force the Leader to do so.
- This is also in line with the universal Principle of Separation of Powers in that the Leader has no further executive powers and there are 3 branches of power, namely the People (Community), the Executive (PMC and CC), and the Monarchy (Council or Leader).
Commit Rights
Commit Rights is defined as the legal right to commit changes in ADempiere sourcecode to the SVN repository.
New commit rights can be granted based on:
- Has submitted contribution(s) that is accepted by the PMC or CC members's simple majority vote.
- Contributions submitted are in compliance with other rules stated in ADempiere Best Practice;
- not on promises of work that are not done or submitted in time. Such rights can be revoked by CC.
Simple majority is defined as minimally + 1 vote more than -1 votes.
- This is for expediency based on current practice.
Commit Rights is now granted by the votes of current committers
Commit Rights is revoked if developer doesn't commit anything within 30 days
Commit Rights can be revoked by simple majority of the rest of committers after a break of any of the rules stated in Best Practice.
Commit Rights for branches or under care of sub-projects without rights to
Commit to trunk can be granted by Project Admins with minimal vote.
Voting Rights
Only community members who are known and suscribe to this Political Section may vote.
New members may be allowed to vote early if they fulfill some basic introduction to make themselves known to the community.
Lurker votes can be noted but not counted
- One who disputes that s/he is a lurker is most likely not a lurker.
Not everybody can vote for everything - subject matters (see section above for clearer objective rules)
Inclusion of new code in trunk just can be voted by committers after some peer review
New functionalities must be voted by functionals and committers
Community issues can be voted by everyone
Branch Policy
Sometimes branches may be formed for localised testing away from the main branch or trunk.
Prospective branch leaders or maintainers can publish the intent in the forums to gather more support and advice before requesting for it.
Only Project Admins can create branches. Other members may request at least one Project Admin for supporting vote before doing so.
Branches may have its own branch committers. Again Project Admins can grant those rights if requested.
Branch work cannot go to trunk or stable branches under control of Comitt -
Committee without prior agreement.
Freedom To Dispute
- If there are disputes political in nature it should be openly discussed and all sides giving their sincere findings.
- Any responsible known member of the community may raise a dispute against any authority of PMC and CC in a substantiated manner.
- No forum discussion can be striken out or deleted unless it is unknown source or containing spam or profanities.
Arbitration
- If normal open discussion cannot settle a dispute, then arbitation may be seek chaired by any Project Admin not involved in the dispute.
- Settlement of dispute should be mutually arrived at.
- Party in conflict must be allowed the time and space to say their say, and no ruling can wipe their words out for the record.
Final Say
- There is no final say other than the voice of the community.
- However if the community failed to resolve a matter of contention then the - PMC and CC and Council collectively has final say.
- A notified maximum limit of 30 days or a full moon is considered a definite failure to act.