- Introduction
- Let Me Get This Straight, Apache Derby Is IBM Cloudscape?
- Development of the Apache Derby Database—Who Can Contribute and How?
- How Can IBM Sell a Product for Profit and Contribute the Same Product to the Open Source Community?
- How an Open Source Database Like Apache Derby Can Help
- Why the Need for a Local Data Store?
- Why Use a Relational Database?
- How the Apache Derby Platform Can Help Your Business
- A High-Level View of the Apache Derby Database
- The Apache Derby Components
- Developing Apache Derby Applications
Development of the Apache Derby Database—Who Can Contribute and How?
In this section, we will briefly discuss who can contribute to Apache Derby and how contributions are made. The goal of this section is not to make you an expert in how the Apache Software Foundation process works; rather, it will briefly describe how your work could end up in Apache Derby. For complete details on the concepts outlined in this section, see http://www.apache.org/foundation/how-it-works.
While you read this section, keep in mind that because Apache Derby and IBM Cloudscape share the same codebase, any changes to the host Apache Derby code are automatically reflected in the IBM Cloudscape binaries. The add-ons provided by IBM with IBM Cloudscape are proprietary, and their source code is not being made available; however, they can be freely used with Apache Derby. For example, IBM’s Java Common Client is not open source code.
Because Apache Derby is an open source database project, its success relies on an ecosystem to enrich and mature the quality of its code base. The development of Apache Derby is peer-based, and these development peers come from an ecosystem that includes personnel from IBM, current Cloudscape customers, and a host of other developers who have previous Cloudscape experience or who choose to become experts in this field because of its obvious advantages. The introduction of new features into the base source code must strictly follow Apache guidelines.
Anyone can be included in the Apache mailing lists and submit code. These developers are known as Apache Derby contributors. The actual code for Apache Derby is maintained in a Subversion (SVN) repository that is restricted to a smaller set of committers. (You can learn more about SVN at http://subversion.tigris.org/.)
The Apache meritocracy determines which members of the Apache Derby community can become committers. This ascension path is the nucleus of the Apache organization and its projects. The Apache Software Foundation has five different levels, as shown in Figure 1-1.
Figure 1-1 The Apache Software Foundation hierarchy
After contributors "earn their stripes" through meritable contributions and overall technical leadership for the direction of the source code, they can be promoted to committers. When a developer is considered a committer, he or she is granted access to the SVN repository. On their Web site, the Apache group calls this process meritocracy; literally, "govern of merit." You earn rights in accordance to your worth and efforts.
Committers get to vote on what contributed features make it into the build tree (again, the source code for the product is stored in the SVN repository). In this way, an experienced committee directs future innovations for the Apache Derby project (this is all part of the Apache process). Of course, because Apache Derby is open source, you are free to develop your own derivative works and use them for yourself, but we encourage all developers to become active in the development of Apache Derby—we are a community after all!
Each committee member can vote for a new feature, abstain from voting, or vote against a new feature for Apache Derby. Any negative votes must include an alternative proposal or a detailed explanation for the negative vote. (Bug fixes do not go through this process, but they do require review at check-in.) In essence, the community tries to come to agreement before moving forward with any changes. The Apache Software Foundation refers to this process as "consensus gathering," and it is a key construct in any Apache community.
IBM assigned six committers to the Apache Derby project when it released this product to the open source community. These committers are all steeped in IBM Cloudscape skills. In fact, they also have a deep understanding of other databases, such as DB2, Informix, Sybase, and SQL Server. Some of these committers are the original architects of the Cloudscape database. For Apache Derby to graduate from an Apache incubator project to a full-fledged Apache project, the committer ratio of IBMers to non-IBMers needs to "strike balance." Who will be among the committers that will join the Apache Derby project and help it become a full-fledged Apache project? It could be you!