- 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
This chapter is from the book
This chapter is from the book
This chapter is from the book
How an Open Source Database Like Apache Derby Can Help
Several vendors are open sourcing their databases these days. Some have yet to publish their source code. The Apache Derby initiative is unique in that the entire source code is published. IBM believes that delivering this code to the Apache Derby community enables a richer and more robust feedback mechanism by which more functions, features, and benefits can be driven into the Apache Derby database.
Another unique and differentiating feature of Apache Derby is that this database was born out of a very successful proprietary initiative and consumer adoption lifecycle. Many features in this product resulted from specific business needs, and customers paid for the right to have these features. Since the Informix acquisition, IBM has continued to invest in this database, and it now powers much of the IBM software middleware stack. An open source Apache Derby database is interesting from both business and technical perspectives.
Open Source Software from a Business Perspective
From a business perspective, the Apache Derby database provides a way for individuals and companies to collaborate on projects that result in a greater sum than each could accomplish on their own: in short, it is synergistic.
It also flattens the "time to value" curve for projects by allocating fixed and variable costs across a greater sum of resources (most of which are not yours, which is a good thing from a cost allocation perspective). This effect drives down the marginal (per unit) cost of new features that are continuously driven into a product and would otherwise cost the recipient more money to obtain and leverage.
For example, consider maintenance programs such as Microsoft’s Software Assurance (SA), which are used to deliver technology updates with new features to Microsoft software. Agreements like this come with their own usage terms but no promise with respect to the delivery of new features. However, new features are prepaid in advance, without credit. For example, SQL Server has a built-in five-year gap between SQL Server 2000 and SQL Server 2005. During this time, Microsoft did not release a significant amount of new functionality because of the business unit’s release schedule, in spite of a user base that required a technology update. (They did deliver some new features. For example, their 64-bit engine was delivered outside of a scheduled release to remain competitive in the database space.) The point here isn’t to besmirch Microsoft, but rather to point out that the delivery of new technology had nothing to do with technological innovation. In fact, some would argue that there has been limited technological innovation with this product (because there wasn’t a release) in the last four years (until the release of SQL Server 2005)—yet not only was the right for these new features prepaid for, but there was also an opportunity cost of not having access to them.
On the other hand, the Apache Derby formula gives access to innovations from their earliest inception, as soon as they become part of the stable build stream. The point is that users of Apache Derby can take advantage of a new feature independently of its location in the product lifecycle, individual business unit goals, corporate funding, and so on. Rather, the decision to take advantage of a feature is based on need—early adopters will gravitate to new features earlier, whereas others might choose to wait until new features are more mature and tested—with a database like Apache Derby, you can do this.
Because this book is written with the Apache Derby application developer in mind, it is beyond our scope to discuss in detail the business benefits of the open source movement. There is a host of information on the Web about the business value of open source software. A good place to start is at http://www.ibm.com/developerworks/rational/library/1303.html.
Open Source Software from a Technical Perspective
From a technical perspective, because the source code for Apache Derby is readily and fully available to an "interested" and participatory community, the open source model has the advantage of transforming application developers into Apache Derby co-developers. Code bugs have a better chance of being detected, and the community serves as a quality assurance tier beyond the test buckets engineered by function verification testing (FVT) and system verification testing (SVT) units in the proprietary model. Beyond the mere detection of problem code, the fix for any issue can be delivered when the code is ready, outside of the complexities of a release cycle, costly hot fix schedules, or emergency rating systems.
The open source model also helps drive key technical features into the product more quickly because more developers are working on solutions to today’s problems, and they get these improvements into the code at the same time (and not in correlation to profit center results). Quite simply, when software like the Apache Derby database is open source, it is free from business conditions and acts as a propellant for new features. In addition, the open source model enables end users to leverage features in a granulized and "as-needed" fashion (some applications will need urgent access to a performance feature, whereas others can wait), with full and open access to the build tree.
When discussing the benefits of open source software, we found the following quote quite interesting: "Source-level debugging saves valuable time throughout the embedded development process by eliminating the guesswork about how the code is interacting with the kernel or other low level operating system code." This quote (from Microsoft:
http://msdn.microsoft.com/embedded/prevver/ce3/download/source/default.aspx)captures one of the key technical advantages of open source software. It’s our point exactly.
The Apache Derby project delivers where other companies’ marketing collateral tailors off.