A formalized process-centric approach to organizing system development is the best way to maximize contributions of a group and create a well-designed product. This "cathedral" method is a structured basis for software and hardware development, as opposed to a "bazaar" method, where input is given by a myriad of users, who, in turn become the co-developers. Even though the cathedral method can be extremely efficient in developing a product, some aspects of the bazaar method can be well adapted to this process centric and formalized approach.

A formalized and free-flowing process can be adapted to the development of any system hardware or software. Systems may range from the simplest few lines of code to a massive project, such as building a space shuttle. Each method of development has its advantages and disadvantages, but the cathedral method offers a solid and structured platform to build upon.

Software developed using Eric S. Raymond's "cathedral" method is "carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time." The process-centric method allows clear and concise delegation of responsibilities to the members of the group working on a system. This delegation of work ensures that each group members' contribution will be considered and almost always adopted. Individuals will be forced to stay efficient and on task if they have only one goal to accomplish. A clear and organized hierarchy exists in the cathedral approach, allowing for clear flow of communication between groups working on different aspects of the same project. In addition, the strict organization allows for a well-documented development summary. Project management could benefit from this documentation, which in turn would increase efficiency. The process-centric approach provides a solid, and often times very efficient development process. However, at times it can be very inflexible and can actually impede the progress of the project. If the project at hand becomes too large for one team to independently organize, then the project becomes a bureaucratic effort, which, without clear flows of communication, can become unmanageable. However, a bureaucratic cathedral approach is still more effective than a bazaar approach in that situation. Although it is more efficient, the cathedral approach may be improved by adopting some of the benefits of the bazaar's free flowing design plan.

Raymond's bazaar method stresses the importance of users as co-developers. The users know which changes to make, and sometimes how to make them. The program's code using the bazaar method is open source; in other words individual users can edit and recompile the program as they wish. Even though bazaar may be effective in developing a thoroughly examined small piece of software, it certainly does not provide an organized and structured basis upon which to design an entire product. A strictly bazaar approach may at times become extremely disorganized, and may require a number of experts to sift through the ideas of the users / developers. Businesses that seek a profit may find the bazaar approach extremely difficult to accommodate due to the non-feasible cost requirements. However, there are several aspects of the bazaar approach that may increase productivity, such as the "release early and release often" policy. This allows for the most efficient use of the bazaar method, increasing the number of eyes searching for a problem. "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone." Each aspect would work relatively well depending on the product being developed. Overall, this free flowing open source process has features that can be incorporated into a thoroughly structured approach, but it should not be used as the sole method of development.

Even though Raymond explains system development solely in terms of software, the aspects of each approach can just as easily be applied to any form of product output. For example, the development of the Challenger Space Shuttle used a very structured, process-centric approach. Each task in the shuttle's development was planned thoroughly and delegated to a specific group. The development of this product should have been accomplished efficiently. However, it failed in producing a product that completed its purpose - safely taking seven astronauts into space. The major technological flaw was localized in the faulty o-rings, which, upon launch, allowed fuel to leak out through the joints, puncturing the fuel tank and causing the shuttle to explode. The major problem in development, however, began when the project became entirely too massive for the established development process. The project was not managed as completely and thoroughly as it would have been in a strict process-centric development approach. In fact, after the tragedy, the NASA Management Study Group recommended that NASA "institute formal training and development programs for program/project managers." Failures in communication occurred between strictly established groups, and the poorly designed role of the managers in the development allowed a tragedy to occur. Although engineers at the low level of the development spectrum knew of the o-ring problem, the managers of NASA never became aware of the severity of the problem. The cathedral approach to designing the shuttle worked well for the most part, but faults regarding a small bug in design resulted in a catastrophe.

It is more efficient to design a product with the cathedral approach than it is with a strict bazaar approach. However, the process-centric and structured approach could benefit from a few added features that would be incorporated from the free-flowing bazaar approach. For example, using an outside group of well-educated users or witnesses to analyze a product would make finding a bug or technical problem much easier. If an outside group of scientists that were not involved in the design of the Challenger were allowed to give their input on the rocket boosters, their opinion about the faulty o-rings may have been better accepted. The bazaar approach's "many heads are better than one" aspect may prove invaluable in finding design flaws and in general creating better ideas for design. However with these aspects of a free flowing approach comes a need for structure and organization. The need for a modified version of the cathedral standard is apparent.

"It is important for organizations to try new development approaches." Any type of organization or business could benefit from a new development approach. A modified cathedral approach incorporating aspects of the bazaar method relative to the situation at hand is the best way to develop a well-designed product. In a case as massive as the Challenger, incorporating a few aspects of the bazaar method and a more thoroughly developed project plan may have been all that was needed to save the lives of the seven astronauts onboard. Jerrold Grochow, a contributor to eWeek Magazine, states, "All plans are based on a number of assumptions - assumptions that almost always turn out to be wrong." NASA must plan their development more thoroughly, and must include a number of other opinions in addition to their own. The development of the booster rockets was structured correctly, but with some additional opinions and a dynamic project plan, all seven astronauts may have survived.