We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.


Proprietary Software and the Software Development Cycle

Originally published August 10, 2006

We shouldn't be surprised when new products or major upgrades to commercial software products take longer and cost more to develop, and deliver less than what was originally expected. After all, proprietary software marketing efforts often conflict with the software development cycle.

For open source software projects, the software development cycle is often a smooth, well-marked road down which developers travel to arrive at usable software; for commercial developers of proprietary software, the cycle is a series of obstacles to be struggled through, against the odds, to arrive at the goal of being first.

Or is this truly the case?

While open source software developers work comfortably within the constraints of the traditional software development cycle, proprietary/commercial software developers must approach the process as an adversarial one in which managers strive to adhere to budgets and schedules even when their actions affect the ability of their programmers to deliver a quality product.

Or could this be different?

The Software Development Cycle
Like any process-oriented task, the development of a software product is both cyclic and iterative. The cycle begins with the software requirements provided by end users to analysts and programmers. Ideally, there is an ongoing dialog between users and developers to report and respond to problems on either side. Unlike the engineering of physical projects such as bridges or buildings, however, the software project cycle doesn't stop when a program is released. The development cycle continues for as long as the software is in use so that bugs can be fixed, features added or improved, performance enhanced or new platforms supported.

From the moment software is released to users, they begin finding the bugs that developers missed in their pre-release tests. At the same time, users and developers will discover features that don't work as advertised or that could work so much better if only they were implemented in a different form, or functions that when added to the existing program would make it far more useful. From these inputs, programmers can patch the most serious bugs and maintain a list of desired changes and additions to the program for its next release.

According to Wikipedia, developers began to identify the different stages of software development with Greek letters after “...[a]n early IBM hardware development convention dating back to punched card tabulating and sorting machines. Hardware first went through an alpha test for preliminary functionality and manufacturing feasibility, then a beta test to verify that it actually correctly performed the functions it was supposed to and then a c test to verify safety. With the advent of programmable computers and the first sharable software programs, IBM used the same terminology for testing software. Beta tests were conducted by people or groups other than the developers. As other companies began developing software for their own use and for distribution to others, the terminology stuck and now is part of our common vocabulary.”

All software developers work through these stages; however, an important difference between proprietary/commercial software and open source/noncommercial software projects is that release of proprietary software is controlled far more strictly. Access to pre-release versions of a proprietary project is given only to users selected by the vendor. Open source software code is available to anyone, and users have the option of downloading, compiling and using stable releases or development releases; proprietary developers are also more constrained in the way they can report and respond to problems reported by users and testers.

The Conflicting Goals of Software Development
In a perfect world, the number one objective is to produce complete, safe, stable and robust software that can be used by end users and/or customers to produce output accurately and efficiently at optimal performance on all the systems it is designed for.

In theory, both commercial and free/open source software projects share this as their ultimate goal.

In practice, commercial teams may face additional objectives as part of their development process that are either minimized or nonexistent for non-commercial open source software developers. Commercial developers must operate within a framework shaped by externalities unrelated to the process or product but integral to the success (or failure) of the company producing the software.

The result is that a combination of these externalities and additional objectives make the task of software development very different for non-commercial as compared to commercial developers:

  • Budget constraints. Commercial software vendors allocate a finite amount of money for the completion of a project, but externalities abound. Budgets may depend on receipt of startup financing, achievement of intermediate milestones and the political acumen of the project leaders. Noncommercial software project budgets are subject to the amount of time their participants are willing and able to commit to the project – certainly beneficial when talented and motivated programmers commit to a project, but often a stumbling block when those programmers must choose between paying the mortgage or writing free software.
  • Schedule constraints. Commercial software development implies two separate but parallel efforts: marketing and developing. The marketing team must announce plans, scheduling and product features to be included in the new project. The schedule may need to be tweaked to accommodate needs of the vendor's other projects, to coincide with industry events, or to beat a competitor to market with a new product. While open source projects are less subject to strict scheduling, if developers fail to fix bugs, add features and generally address user demands, they risk irrelevancy.
  • Corporate culture constraints. The corporate culture of the development organization will always generate constraints. Choice of development environments, programming languages, GUI styles and other parts of the infrastructure of program development may be imposed on the development team, whether they are appropriate or not – but open source projects can be just as limited to open source tools and techniques.
  • Staff constraints. Commercial project staff members may be chosen for their political acumen, connections and seniority rather than for their motivation and ability to produce the best result. Open source developers are either self-selected volunteers, or individuals recruited across organizational and national boundaries by the project leaders. Although they must be motivated, open source projects depend on the ability of their leaders to recruit volunteers who are also skilled.
  • User-imposed constraints. Will users require that the product be backward compatible with their existing applications? What kind of user interface do users need? Will that change from version to version and product to product, or is there a corporate standard that can be counted on to remain stable? Commercial developers must balance user needs with the goal of increasing shareholder value; noncommercial developers have greater freedom to satisfy end users.
  • Market-imposed constraints. Commercial software vendors are notorious for competing on bullet lists of feature sets, so feature “support” may become a requirement regardless of whether or not the feature is useful. Mere existence is sufficient to include a feature in promotional materials. Similarly, vendor support for data formats that don't belong to the vendor depends on whether support for open or competing proprietary formats undermines the vendor's ability to lock users into its product.
  • Features/objectives mandated by other external factors. Some more subtle constraints include the need for the development team to develop software compatible with a vendor's other product lines, and in many cases conform to an overall architectural vision decided upon by corporate executives.

The end result is that there is considerable pressure on developers of proprietary software to push software through the process more quickly at the expense of stability, robustness, performance and rich feature sets.

Which Model Works Better?
Does the software development cycle model work better for open source than for proprietary software?

Yes. But also no.

It's a trick question because the software's quality of being commercial or noncommercial is orthogonal to the software's quality of being proprietary or open:

(The differences and overlaps across these categories, as well as the wider variety of software considered noncommercial and proprietary, are worthy of much deeper discussion.)

Since open source software can be commercial, and proprietary software can be noncommercial, and some of the major players have key products in two or three of the four boxes, the differences in the development cycle for different types of software are rapidly blurring.

Red Hat, MySQL and Oracle have corporate goals associated with their commercial software releases. However, to the extent they are open source, those projects benefit from the greater availability and wider distribution of source code earlier in the development cycle. These commercial/open projects also benefit from the availability of coders and beta testers from outside the sponsoring corporations – while retaining this key source of funding.

As noncommercial open source projects grow in importance and gain corporate or alternative organizational sponsors, they also gain some of the benefits of commercial projects such as increased and guaranteed funding to pay for programmers and equipment, professional management and exposure to a wider audience with the help of corporate PR and marketing efforts.

The ideal result will be commercial and proprietary software vendors adapting open source techniques to improve their development process – and noncommercial and open source projects adapting commercial approaches to software development.

  • Pete LoshinPete Loshin

    Pete is Founder of Internet-Standard.com, an open source and open standard computing consultancy providing technology assessment, needs analysis and transition planning services for organizations seeking alternatives to commercial software. Pete has written 20 books, including “TCP/IP Clearly Explained” 4th Edition, Morgan Kaufmann, 2003) and “IPv6 : Theory, Protocol, and Practice,” 2nd Edition (Morgan Kaufmann, 2004).

    Pete can be reached at pete@loshin.com or at 781. 859.9175.

Recent articles by Pete Loshin

 

Comments

Want to post a comment? Login or become a member today!

Be the first to comment!