BA Chap. 12 - When the bazaar sets out to build cathedrals

Since I've never worked with a community on an open-source project, I always wondered how developers from around the world are able to effectively work together to develop great software without a direct manager to report to, and without compensation. Sure there are some professionals that get paid by their employers for contributing code to these open-source communities. But even at my current job where my company invests vast amounts of resources do I have trouble getting things done when I work with foreign teams. The article said it best with, "Discussions that can be finished in 15 minutes in a stand-up office meeting may take days of arguing". It seems that they get their best work done when they meet in their quarterly/bi-annual/annual meetings and have these week-long coding sprints. But even then, what do they do when a contributor doesn't provide what he/she commits to do or when he/she quits? I find it astonishing that work actually gets done due to personal motivation, and that their pride alone can provide better quality code because developers are not rushed to meet a deadline.

Overall, the article's chronological description of their communities thought process throughout the evolution of Akonadi & ThreadWeaver was intellectually stimulating. I initially did not understand why they didn't Unit Test the PIM infrastructure. Automatically testing the core functionality to see if anything broke by a change in PIM could have saved them time. Then again if the code-base was very large, the effort to do unit-testing may not have been worth it. I originally thought that applying the adapter or façade pattern to abstract the support of multiple backend implementations would've solved the assumptions that made about limited data and application usage. But then I realized that it wouldn't have solved their concurrent access to data requirement. Also, I didn't understand why they didn't use a DB indexes for their data when they discussed their need to load the whole address book into memory. Then, they later explained that their data had to support multiple types so it had to be stored in the DB as string. Indexes doesn't help in this situation so Akonadi was implemented to support serializer plug-ins for components.

Threadweaver, similarly, had some clever architectural features in their job queue for concurrency. The queue made sure jobs were executed in sequence through the notion of Dependencies without the nasty use of a mutex!