The Project obtains its strength from the communication of its members.
+In order for members to easily communicate with each other, the Project
+has a variety of mailing lists. These lists, with the exception of the
+announcement lists, are not moderated and anybody is more than welcome
+to join them. However, you must be subscribed to post to a list.
To reduce the bandwidth demands on everyone, mail should not contain
+attachments. It is recommended that you place interesting material (such
+as patches) either within the body of the message or provide a URL for
The Project's list fall into the categories below.
Announcement lists are very low traffic designed to communicate
+important information, such as final releases of a subproject's code, to
+a wide audience.
User lists are for users of a product to converse about such things as
+configuration and operating of the products of the Project.
Developer lists are for the developers of the project. On these lists
+suggestions and comments for code changes are discussed and action items
+are raised and voted on. For the developer community, these lists are
+the very center of the project where all the "action" is.
The commit lists are where all cvs code commit messages are sent. All
+committers are required to subscribe to this list so that they can stay
+aware of changes to the repository.
Most of the DB Website is maintained by the individual subprojects. Any comments regarding a product's web pages should be directed to the appropriate subproject's.
The portion of the Web site under db.apache.org/ site is managed as a joint
+effort by the subprojects and the DB Project Management Committee. Comments
+regarding these pages can be directed to the General mailing list, or to the
+DB Webmaster's mail box.
If you are unsure where to post, contact the
+DB Webmaster, who will direct you to the appropriate
The Apache Software Foundation
The DB Project is an effort of the
+Apache Software Foundation. The address for general
+ASF correspondence and licensing questions is firstname.lastname@example.org
All Contributors are encouraged to participate in
+decisions, but the decision itself is made by those that have
+Committer status in the Project. In other words, the
+Project is a Minimum Threshold Meritocracy.
Any subscriber to the list may vote on any issue or action item.
+However, the only binding votes are those cast by a Committer. If the
+vote is about a change to the source code or documentation and the
+primary uthor is a Contributor and not a Committer, the primary author
+of whatis being changed may also cast a binding vote on that issue.
The act of voting carries certain obligations. Voting members are not
+only stating their opinion, they are also agreeing to help do the work.
Each vote can be made in one of three flavors:
+ "Yes," "Agree," or "the action should be performed."
+ On some issues this is only binding if the voter has tested the
+ action on their own system(s).
+ "Abstain," "no opinion".
+ An abstention may have detrimental effects if too many people
+ On issues where consensus is required, this vote counts as a
+ veto. All vetos must contain an explanation of
+ why the veto is appropriate. Vetos with no explanation are void.
+ No veto can be overruled. If you disagree with the veto, you
+ should lobby the person who cast the veto. Voters intending to
+ veto an action item should make their opinions known to the
+ group immediately so that the problem can be remedied as early
+ as possible.
An action requiring consensus approval must receive at least 3 binding
++1 votes and no binding vetos. An action requiring majority
+approval must receive at least 3 binding +1 votes and more +1
+votes than -1 votes. All other action items are considered to have
+lazy approval until somebody votes -1, after which point they are
+decided by either consensus or majority vote, depending on the type of
All decisions revolve around Action Items. Action Items consist of the following:
Long Term Plans
Short Term Plans
Long Term Plans
Long term plans are simply announcements that group members are working
+on particular issues related to the Project. These are not voted on, but
+Committers who do not agree with a particular plan, or think that an
+alternative plan would be better, are obligated to inform the group of
Short Term Plans
Short term plans are announcements that a volunteer is working on a
+particular set of documentation or code files with the implication that
+other volunteers should avoid them or try to coordinate their changes.
A release plan is used to keep all volunteers aware of when a release is
+desired, who will be the release manager, when the repository will be
+frozen to create a release, and other assorted information to keep
+volunteers from tripping over each other. Lazy majority decides each
+issue in a release plan.
After a new release is built, it must be tested before being released to
+the public. Majority approval is required before the release can be
Showstoppers are issues that require a fix be in place before the next
+public release. They are listed in the status file in order to focus
+special attention on these problems. An issue becomes a showstopper when
+it is listed as such in the status file and remains so by lazy
Changes to the products of the Project, including code and
+documentation, will appear as action items in the status file. All
+product changes to the currently active repository are subject to lazy
This document defines the guidelines of The DB Project. It includes definitions
+of the various categories of membership, who is able to vote, how conflicts are
+resolved by voting, and the procedures to follow for proposing and making
+changes to the codebase of the Project.
DB is a Project of the
+Apache Software Foundation, charged with the
+creation and maintenance of commercial-quality, open-source, database solutions
+based on software licensed to the Foundation, for distribution at no charge to
Apache Software Foundation
The Apache Software Foundation provides support for the Apache community of
+open-source software projects.
+The Apache projects are characterized by a collaborative, consensus based
+development process, an open and pragmatic software
+license, and a desire to create high quality software that leads the way in its field.
This is the project general mailing list. This is where ideas, suggestions,
+and comments are exchanged that deal with the overall DB project. Matters
+that affect the project as a whole are decided here. If you are interested in
+adding a new project to DB, please see this page.
The Project Management Committee (PMC) was formed by the Apache Board on 17
+July 2002. The bylaws were last amended on 6 October 2004. There is no preset
+number of seats on the PMC. The PMC will strive to add every committer within
+DB that, in the opinion of the PMC as determined by a vote, displays the
+capability and desire to help guide the DB project. The PMC will nominate a
+chairperson from amongst their ranks for presentation to the Board. The list
+of current members can be found in our Project Credits.
The PMC is responsible for the strategic direction and success of the DB
+Project. This governing body is expected to ensure the project's welfare and
+guide its overall direction. The PMC may not necessarily participate in the
+day-to-day coding but is involved in the overall development plans, the
+alleviation of any bottlenecks, the resolution of conflicts, and the overall
+technical success of the project.
The PMC is answerable to the Apache Board with its Chairman serving as
The PMC discusses issues and determines strategic direction via mail list.
+All binding votes happen on the PMC list.
PMC members may resign at any time. A committer will remain on the DB PMC
+until removed by desire of the committer, action of the board, or vote by the
+PMC. The Chairman may resign as Chairman at any time without resigning
+membership to the PMC. The chairperson will serve until voluntary
+resignation, action of the board, or vote by the PMC. The Chairman or any
+member may be removed from the PMC by a 3/4 vote of the PMC.
In order to be elected to the PMC, a person must have served as a
+Committer and be nominated by a PMC Member. The nominee must
+receive 3/4 positive vote with a minimum of 3 positive votes. Abstaining PMC
+voters do not affect the result.
Creation of Subprojects
PMC members may propose the creation of new subprojects. Creation of a new
+subproject requires approval by 3/4 positve vote with a minimum of 3 positive
+votes of the PMC. Abstaining PMC voters do not affect the result. New code
+enters the DB project in accordance with ASF policy.
The call for a vote on issues not detailed here may specify requirements for
+passage. The minimum and default requirement for a passing vote is simple
+majority of PMC members casting ballots. The default voting period is 10 days
+and the minimum is 7 days unless the success or failure is arithmetically
Not every software product is suited for life at DB. Before proposing a new
+subproject, it is important to read this document carefully and determine
+whether your product is a good fit.
Here are some best practices that we will expect to find in a successful
+proposal. This is not a checklist, but guidelines to help communicate what is
+expected of a DB subproject.
+Before submitting a proposal, be sure to study the guidelines that
+govern DB subprojects. These guidelines explain our system
+of Meritocracy, which is the core of the DB Project. If the product
+developers do not wish to adopt this system, then they should not donate
+their code to the Project, and should look elsewhere for hosting.
+DB is a Project of the Apache Software Foundation.
+A prime purpose of the ASF is to ensure that the Apache projects continue to
+exist beyond the participation of individual volunteers. Accordingly, a prime
+criteria required of any new subproject is that it already enjoys -- or has a
+high potential for attracting -- an active community of developers and users.
Proposals for non-established products have been accepted, most often when
+the proposal was tendered by experienced open source developers, who
+understand what it means to build a community.
A design document, developer and user documentation, example code, and a
+working implementation all help to increase the likelihood of acceptance.
+Well-documented products tend to build stronger communities than products
+that rely source code and JavaDocs alone.
+To considered, a product must have at least 3 active developers who are
+already involved with the codebase. This is an absolute minimum, and it is
+helpful for there to more than three developers. It is very helpful for
+at least one of the developers making the proposal to already be active in a
+DB subproject or other open source initiative.
At DB, the core developers of a product (the Committers) manage
+the codebases and make the day-to-day development decisions. We are only
+interested in products that can guided by their own development communities.
+DB provides the infrastructure, and some essential guidelines, but the
+Committers must take responsibility for developing and releasing their own
Alignment with existing Apache subprojects.
+Products that are already used by existing subprojects make attractive
+candidates, since bringing such a codebase into the Apache fold tends to
+benefit both communities. Products with dependancies on existing Apache
+products are also attractive for the same reason.
+DB products are generally server-side software solutions written for the Java
+platform. Proposals for products outside this venue will have greater
+difficulty in being accepted.
These are anti-patterns that we have found detrimental to the success of a
+proposal. Some of these are lesson learned from the school of hard-knocks,
+others are taken from proposals which have been rejected in the past. All
+will raise a red flag, making it unlikely that a proposal will be accepted.
+Products which have lost their corporate sponsor (for whatever reason) do
+not make good candidates. These products will lack a development
+community and won't have the support needed to succeed under the DB umbrella.
For example, we have seen proposals that contain paragraphs like this:
The alleged quality of a product is not the prime criteria. To be accepted,
+we must believe that a product will attract volunteers to extend and maintain
+it over the long term. A product like this, arriving with no volunteer
+developers or open source community, does not further
+DB's mission, and would not be accepted.
We generally recommend that an orphaned product start with an independent
+host, and consider making a proposal after it has started to build a
Inexperience with open source.
+We often receive proposals that start with "We will open our software if you
+choose to accept it." This is the wrong way to approach the proposal process.
+A closed source project does not have an open community, and so we have no
+way to tell if the developers can work in an open source environment.
+Products that have lived on their own and have started to develop their own
+community, have a much better chance of being accepted.
If the product's developers have not worked with open source before, it is
+recommended that they spend some time contributing to an existing open source
+project before trying to manage one of their own. Since DB subprojects are
+managed by their own Committers, it is important that a new product supported
+by people who understand how open source works.
+Apache communities attract developers with diverse backgrounds. Products with
+a tightly-knit team of developers may have difficulty shepherding new
+developers into the fold. It is vital that we believe the developers will
+discuss development issues openly with the community, and not make
+decisions behind closed doors. We are especially wary of products with
+developers who all share a common employer or geographic location.
Reliance on salaried developers.
+DB has strong ties to the business community. Many of our developers are
+encouraged by their employers to work open source projects as part of their
+regular job. We feel that this is a Good Thing, and corporations should be
+entitled to contribute to open source, same as anyone else. However, we are
+wary of products which rely strongly on developers who only work on open
+source products when they are paid to do so. A product at DB must continue to
+exist beyond the participation of individual volunteers. We believe the best
+indicator of success is when developers volunteer their own time to work open
No ties to other Apache products.
+Products without a tie to any existing Apache product, and that have
+strong dependencies on alternatives to Apache products, do not make good
+candidates. Many Apache products are related through common licenses,
+technologies, and through their volunteers. Products without licensing,
+technology, or volunteers in common will have trouble attracting a strong
A fascination with the Apache brand. The
+Apache Software License is quite liberal
+and allows for the code to used in commercial products. This can induce
+people to donate a commercial codebase to the ASF, allow it developed as open
+source for a time, and then convert it back to commercial use. While this
+would legal under the Apache Software License, we are wary of proposals that
+seem to be more interested in exposure than community.
Final acceptance is based the rules defined in the
+Project Management Committee Bylaws which state that
+"Creation of a new subproject requires approval by 3/4 vote of the PMC." The
+proposal for a new subproject must submitted to the DB General
+mailing list, where the PMC conducts business. All discussion
+regarding the proposal will occur the General list, including the final vote.
The roles and responsibilities that people can assume in the project are
+based on merit. Everybody can help no matter what their role. Those who
+have been long term or valuable contributors to the project obtain the
+right to vote and commit directly to the source repository.
Users are the people who use the products of the Project. People in this
+role aren't contributing code, but they are using the products,
+reporting bugs, making feature requests, and such. This is by far the
+most important category of people as, without users, there is no reason
+for the Project.
When a user starts to contribute code or documentation patches, they
+become a Contributor.
Contributors are the people who write code or documentation patches or
+contribute positively to the project in other ways. A volunteer's
+contribution is always recognized. In source code, all volunteers who
+contribute to a source file may add their name to the list of authors
+for that file.
Contributors who give frequent and valuable contributions to a
+subproject of the Project can have their status promoted to that of a
+Committer for that subproject. A Committer has write access to the
+source code repository and gains voting rights allowing them to affect
+the future of the subproject.
In order for a Contributor to become a Committer, another Committer can
+nominate that Contributor or the Contributor can ask for it.
Once a Contributor is nominated, all of the Committers for a subproject
+will vote. If there are at least 3 positive votes and no negative votes,
+the Contributor is converted into a Committer and given write access to
+the source code repository for that subproject. This is an example offer
+letter that should be sent to the volunteer after 3 positive votes have
Once there are 3 positive votes and the response to the above letter has
+been received, the Contributor must sign and submit the Contributor
+License Agreement (CLA) as described
+on the ASF Licenses page.
+Once the CLA has been received and processed, the PMC chair should
+request that a new account is created. See details
+here. If the new
+committer already has an Apache account, the appropriate SVN access
+should be granted by the PMC chair by following the instructions
Note 1: All committers will be given access to the db-site module on
+request. In other words, committers should be able to update the main DB
At times, Committers may go inactive for a variety of reasons. A
+Committer that has been inactive for 6 months or more may lose their
+status as a Committer. Getting access back is as simple as re-requesting
+it on the project's Developer mailing list.
A list of some of our current Committers can be found in our
Management Committee (PMC)
Committers who frequently participate with valuable contributions may
+have their status promoted to that of a Project Management Committee
+Member. This committee is the official managing body of the DB Project
+and is responsible for setting overall project direction. In order to
+become a Member, someone on the PMC must nominate the Committer. The
+individual may then be approved with a 3/4 majority of the PMC.
To view the Project Management Committee bylaws, click