One of the first technical decisions we faced was whether to reuse or rewrite. Fedora represents over twelve years of development effort and there are some fairly well-known arguments against undertaking a complete rewrite.
However, the challenge of reusing the existing codebase is daunting, and not only for technical reasons. Fedora is not just an open-source project, but it is a community-sourced project. That is, a significant part of Fedora's value proposition is the strength and expertise of its community. That community has driven and sustained Fedora over the years, but the technical debt of Fedora's codebase has become a liability for engaging and growing our community of developers. A strong and engaged developer community is an essential part of a preservation repository's success and sustainability, so our answer to the question of reuse or rewrite must support this goal.
At nine years, I am the longest-serving, active committer on the Fedora project and to this day I find many parts of the codebase difficult to approach, difficult to test, and therefore, difficult to change. We are past the era of relying on grant-funded teams of full-time, salaried developers working on Fedora. This doesn't appear likely to change. As a repository service, Fedora's relationship to end-users is indirect at best and consequently, the relationship between Fedora development and end-user value is not well understood or appreciated. Indeed, most of the energy in the Fedora ecosystem is now directed at higher-level frameworks (e.g. Hydra) and vertical products (e.g. Islandora), where the relationship between users and developers is more direct. A key part of Fedora's future has to be a modular, extensible codebase that embraces and facilitates community contribution and collaboration in its many and varied forms.
Two particular problems that I find the Fedora 3.x codebase ill-equipped to handle are: i) scalability and ii) transactionality. Moreover, I find these two problems argue against reuse.