Sire

Writing a program or library will always involve periods of time when you have to make critical decisions. Decisions that, once made, are pretty irreversible, and that will effect you, and everyone who uses your program and develops your program hereafter. Decisions with no clear right or wrong, but will be cursed by those that come after you as impossible and stupid mistakes that form the legacy bloat of a code, and that are held up as reasons to start again, and rewrite from scratch.

I am trying to make one of these decisions now. Like many such decisions, it is pretty difficult to articulate to a non-programmer. This one is pretty important though, of the magnitude of "Which side of the river shall we build our capital city?". One side of the river is easy to access, and easy to build on, but is very exposed to attackers (changes in APIs, changes in supported platforms). The other side is easy to defend, as everything can be self-contained and protected by the natural geography. However, building there is very hard...

The Thai people were faced with this exact decision in the 18th Century. After the ancient capital of Ayutthaya was destroyed by the Burmese, the Thai people had to decide where to build their new capital. They knew that the capital should be south of Ayutthaya (away from the Burmese), and so they went to the base of the strategically and commercially important Chao Phraya river. They were then faced with the decision of whether to build on the east or west bank of the river. Building on the west was easy, as they could develop the already-existing garrison town of Thonburi. Everything was available, there were few logistical problems, and development could be rapid. However, the west side was harder to defend than the east. The land on the east bank was surrounded by a natural curve in the river, and through the addition of ditches and canals, could be turned into a self-contained island. Building there was harder, and the east side contained only a small trading town, called Bangkok.

Being pragmatic, and having only just re-united his people and defeated the Burmese, the king at the time decided that the best course of action was to build on the west bank. The capital city of Thonburi was built rapidly and majestically. A palace, temples, markets and dwellings were built, and the city served well as the capital. However, it was not ideal. It was not as easy to defend as the east bank. Yet, the decision had been made, and everyone had to stick with it. Everything grew up on the west. After 15 years, political differences between the king and nobles meant that the king was removed (rather permanently..!). The new king took the opportunity to perform the equivalent of a code-review. He looked at the problems caused by the initial decision to build on the west, and decided that those problems would be too difficult to solve. He thus did what many programmers would do when faced with the wrong choice being made at the beginning of the project. He decided to scrap the original and rewrite from scratch. He moved the capital across the river to the trading town of Bangkok, and built a whole new set of temples, a new palace etc. Ayutthaya was the capital for hundreds of years before destruction by the Burmese. Bangkok has been the capital now for over 200 years. Thonburi was capital for just 15 years...

So, how does this relate to my decision? I am in the process of splitting Siren out into its own project. Siren is the foundation of Sire and of Aquire, and I had to build it rapidly to support Sire and Aquire. However, to do that, I built Siren on top of existing, third-party C++ libraries, for example Qt4 and boost. At the time, this was a very wise decision. These libraries are extremely well written, portable and well-documented. They provided features that were critical to the development of Siren, and to the entire Sire project. However, they introduced dependencies that have made the installation and development of Sire difficult and complex (e.g. new users have to learn how to install Qt, and they have to learn the Qt API). My decision is whether or not I keep these libraries, and so stay on the west bank of the river, or to replace these libraries with my own code, and so move to the east bank. Staying on the west is quick and easy, but becomes harder to defend with time. Qt and boost continue to evolve. I am particularly concerned about Qt. Making Siren depend on Qt would make everything built on Siren depend on Qt. I am using Qt4, but there will soon be Qt5, which has a very different philosophy and direction to Qt4. Since I started Sire in 2005, coding against Qt3, Qt has moved from an independent project to build C++ programs, to a framework owned by Nokia for building web and mobile applications in C++, Java, HTML5, QtScript and Javascript. This year, Microsoft entered into partnership with Nokia, and Qt has essentially been cut free, and its future looks uncertain. They are moving to a community governance model, which could work, but which has very few successful examples (failures include Netscape/Mozilla, OpenOffice etc., where a community of equal stakeholders failed to agree a common vision or delegate the boring coding jobs, and so the software lost focus and fell behind competing offerings from Apple, Google and Microsoft). I am concerned that the code I use in Qt4 will not be supported or available in 10+ years time. Already there are problems of porting Qt to post-PC devices such as iPhones and iPads, and the library is just too big and multi-faceted for what I need.

I use only a small subset of one of the Qt sub-modules (QtCore). This small subset is really critical to Siren, as it provides the code to abstract the platform (providing portability), threading, reference counting, internationalised strings and really powerful containers (vectors, hashes, dictionaries). This small subset is the foundation of Siren, but is the benefit worth the burden of tying all Siren-developed applications to the whole Qt library? And so I am left with a decision? Do I stay here on the west bank, building everything on top of Qt, and in so doing, making every future developer who uses Siren stay develop on top of Qt? Or do I move to the east, and drop or hide Qt? Academic code lives for decades, and I hope that Acquire (built on Siren) will be built into a wide range of applications over the next decade or so, so there is a strong argument that I should move away from Qt. However, replacing Qt, or abstracting away from Qt is a lot of work. The right decision is, I think, to move away from Qt, at least publicly. I think that I should remove the dependency on Qt from Siren, and just copy the subset of QtCore that I need in Siren into the library. Siren should be standalone, and have its dependencies copied in. One way to do this would be statically link Siren to QtCore, and to make thin-wrappers around the Qt classes that I need, e.g. Siren::String as opposed to QString. This would enable me to control the list of Qt classes that I actually use, and to then either copy the code from QtCore, or write the code myself (I'd prefer to copy the code, as Qt is LGPL, so that should be ok). It is a lot of work though, so I think I will have a very busy week... On the plus side, I hope that the time spent now will mean that Siren will last for decades, and will not, like Thonburi, be replaced in 15 years time! Speaking of which, Thonburi was eventually merged into Bangkok as the capital grew past the confines of the island on which it was built. Thonburi is now just a district of Bangkok, and with the exception of some lovely temples, there is little left to reflect its status as a capital city
of Thailand.