Okay, let’s start with a “I feel sorry for you, I know the feeling” message for tsdgeos (maintainer of KPDF and one of the poppler developers), who’s experiencing a situation similar to the one I just ended . At least I can say I’m not alone.
Then, let’s see one of the recent news about Jörg Shilling latest funny decision. Now, I could have understood licensing the Makefiles under CDDL and still license the whole package under GPL, to use the makefiles somewhere else, but no, he’s gone beyond…
Now, let’s get off the whole discussion about how ethical it is to do that, how legal and so on (for my opinion, Shilling is just a moron, but that is). What I would like to talk about is the difficulty of writing alternatives.
First of all, cdrecord is what it is since a long time now, so it has a lot of frontend softwares written for it, the first hard problem is to have a good support, that usually force in a compatibility of parameters. You can think that this is the least problem, but it’s actually a big problem if you want your software to get used.
Another problem is that if you don’t get users, you usually don’t get developers either. Small projects end up being self-contained, with a few users and just one or two developers, and that usually declares them as dead and so on. Rarely you can see a project getting some more users/developers after months of staleness, just because someone found the software interesting and tried it, but unless you can coordinate it well, most of the forks that can start with a couple of people are ready to die.
I actually tried looking for people in Italian LUGs a couple of years ago to start a cdrecord fork. I wrote a quite long post on the reasons I don’t like the way J.S. is playing chess with us, and what would be needed to start a fork, but I didn’t get much feedback, two people answered, and both not experienced in free software development and even less on ISO and CD/DVD recording. So I can tell you a few problems of this particular reimplementation.
All the work has to be done knowing well the ISO9660 standard used as filesystem, the UDF filesystem, and the MMC commands. For non-MMC compatible writers, you also need to find their command language. If you want it to be portable (I wanted it to be at least) you also need to know the interfaces of the different operating systems, and not all of them are at the same level, I can tell you that as I remained “in the field” with libcdio and unieject, the support for OSX for instance is entirely missing there, most of the operating systems lack complete documentation on these things.
The standards above mentioned don’t have public documentation, the documentation costs, and it’s not a low cost most of the times, if I remember correctly, 4⁄5 books on ISO9660, UDF and MMC commands were about $1000 to buy. This is a big issue and hard to workaround, you cannot always gather knowledge through sources (even if sometimes it’s possible, and that is a good example with MMC commands too).
A similar problem is present when working on implementing video and audio codecs, and FFmpeg developers knows that well enough. On one side, though, it’s simpler to work with those because you don’t have to waste material, and thus money, with tests, as you would do with CD-R, CD-RW, DVD-R, DVD+R, DVD-RW, DVD+RW to write a CD/DVD recording software.
So, Shilling probably did a great deal of work on cdrecord, and he was actually good at providing a working software for so many platforms, but his own methods are killing the project..
I’m interested, really interested, in seeing a reimplementation, but I won’t count on it too soon…
See libburn:It has a frontend which behaves (nearly) like cdrecord: cdrskin