When the bazaar sets out to build cathedrals BA ch 12

Author mentioned some key technical decisions like dropping the idea if it doesn’t work in reasonable time frame; maintain the core functionality working all the time while the changes have been made to the project, etc… What are some other ideas that you get in mind while you are reading these technical decisions or some other ideas that we may have seen in cathedral type project building (in our work places)?

In software development there are always difficult decisions that have to be made with various consequences. As described in this chapter larger scale software projects are not only technically challenging, but also involve other issues. Open sources project need to overcome technical, social and structural issues, while commercial software development teams usually need to deal with aggressive schedules, reduced costs.
The decision of completely redesign KDE from KDE3 to KDE4 was a courageous and risky decision. I believe such a decision was only possible because of the open source status the project. Given the large number of contributors they were able to maintain KDE3 and quickly redesign the system. The decision was needed to make KDE platform independent and ended up being a successful decision as it made the platform more stable and brought more users.
From my experience it is not easy to take a redesign decision in commercial environment. I have worked on couple of project that clearly needed a complete re-design. In one case, the system was very messy and very hard to maintain. Many developers argued to the management that a redesign was necessary and will pay off in the long run, but senior management completely opposed the idea because it was critical to bring new functionality to the market and the redesign was just too much of a risk to take. After reading the Evolution of Akonadi, KDEPIM community depended on architecture meetings / conference secessions to discuss the key architecture items and author mentioned about most of the high level / key items are agreed but implementation of individual items still faced some heated discussions. Have you had any similar experience where you agreed to key concept but varied how it needs to be implemented either in bazaar / cathedral model implementation of the project?

This happened on almost all the projects I have worked on in my current position. We develop firmware for a system where reliability and performance are critical. We regularly have heated discussions in low level designs and code reviews about implementations and code efficiency. Currently we are developing code of conducts and code guidelines so that we can refer to them for conflict resolution in the future. I like the section where the authors talks about how some of decisions are made in KDE. They talked about: “those who do the work decide”. I argue that some of us working in commercial companies can only dream of such an environment. As people who do the work we are usually not even in the room when decisions are made. Senior executives make the decisions usually based on market conditions, set the date the product needs to be ready and push the decision down to development teams for implementation.