An interesting observation, seen in Table tab-dominant-fs, is that each device level file system listed in Section sec-bg-type-device has only a handful, generally no more than two, dominant implementations in use for each storage medium.
One might wonder why this is the case. Is it pure luck that these were the first file systems ever implemented on these media, and now they are the de-facto standards for their media? I think there are several reasons for their dominance. They are dominant because they are good and they satisfy the needs of the majority of users. They have been adapted to observed workload and improved quite a bit over the years, to a point where anyone thinking of writing a new one at that level has to come up with something substantially better to get a sizable share of the market. In short, reasons to write new file systems at the device level are rarely compelling, or surely they would have been written.
Every file system (or kernel) developer would agree that writing a new file system takes a long time, is difficult to test and debug, and has to be constantly maintained as operating systems evolve and change. Every small change takes a long edit-compile-run-debug cycle, with kernel crashes and lack of debugging tools [Golub90,Stallman94,SMCC94a] making the task frustrating. Worse, file system code developed for one operating system is almost never portable to another. After a long period of development for one operating system, the whole process has to be repeated if the file system is to be ported to a new operating system. It should come as no surprise, given the sheer size of file system code, that vendors and independent software vendors (ISVs) are reluctant to develop new file systems, at least at the device level.