RISC OS

Resuable Engineering

You know what I'm talking about, right?  How many IRC clients are there for RISC OS?  Web Browsers?  WIMP Libraries?  CDFS/IDE implementations?  USB?  Versions of RISC OS itself? How about the number of news sites? File repositories?  VNC clients?

The list is long.  The answer to the first one is the most outrageous - last time I did a count, there were no less than twenty IRC clients.  Sure, most of those haven't been updated in many years, but the attitude that brought so many about persists.  There are also around 10 web browsers, 6 VNC clients, and my hobby horse, the mess that is the ADFS/CDFS implementation forcing writing of a complete driver stack for any new IDE/ATAPI interface.

Other Platforms

Of course, such repetition exists on other platforms, but not, I contest, to the same degree.  I'm pretty sure you could find 20 IRC clients for Linux, but that's a platform which has magnitudes more users, and a greater proportion of developers.  I suspect you could easily find as many for Windows too - but the situation is different here.  Apart from having millions of developers, Microsoft has provided itself many of the important productivity applications, so from a user pespective, this type of repitition isn't as bad.

What about a more similar platform?  Well, there's AmigaOS.  I happen to know that it has a mere 3 web browsers (with a Firefox port on the way).  AmigaOS has more users than RISC OS, but not by a substantial amount, and many similarities in other areas, but does not seem to have had this problem.  Without knowing more about the platform, it's hard to say why, although perhaps its earlier exposure open source software has had an influence.  On the flip side of the coin, AmigaOS development has suffered very badly in recent years by its small number of developers being split between various new OS and hardware alternatives as well as bitter in-flighting.

SCSI

But back to RISC OS, and a specific example.  Let's consider the filesystem layering in RISC OS.  In short, it's a mess.  If you were to design one from scratch, you'd probably come up with something similar to what's used in Linux, NetBSD or many other systems.  The Linux one is actually quite complex, but that's largely due to the vast range of hardware supported - the NetBSD design is perhaps cleaner and easier to understand if you were seriously looking at such things.

Under RISC OS, the design is anything but orthogonal.  Pieces have been bolted on without regard to interoperabilty or future expansion.  To understand the precise nature of the problem, it's worth considering what precisely we're talking about.  The systems in question under RISC OS include ADFS, CDFS, SCSI, USB Mass Storage, ADFS filer, the plethora of CDFS hardware drivers, and the various third party IDE/SCSI cards which reimplement various of the above.  Without going into torturous detail, there's really only two types of devices that are talked to - those are IDE harddiscs, and those using SCSI or ATAPI command sets (the latter sits on top of the IDE ATA protocol) - which include all SCSI devices and other IDE devices like optical drives and USB mass storage devcies.  There are also a small number of parallel port devices which use ATAPI protcols like scanners and zip drives.

It's possible that there could be designed a system where all these bits were linked together properly and would have saved a huge amount of time. Even though in prinicple the code exists in RISC OS to allow you to plug in, for example, ATAPI ZIP drives, it's put together in the wrong way.  To allow them to work would need a brand new driver written by someone. Of course, the opportunity still exists for Castle to put this right - I hope they might see that such effort would ultimately save them time and hassle.

New Features

How about another example.  I'd like to relate something I was told by way of an example.  The details of this may not be strictly correct, and I certainly don't want to point the finger at the person involved (I don't know who it is, in any case), but it characterises what I'm getting at. It concerns the text editor, Zap.  Zap is currently gaining unicode support, which is great.  To go with this, someone proposed adding a Japanese IME (Input Method Engine) to Zap.  That sounds great too, but wait a minute.  If you are familiar with what such a thing might behave like, you'd appreciate that it would be very useful outside Zap - indeed, any RISC OS application which supports input - or at least, supports unicode input.  It would be far better to develop an IME which is a RISC OS application in its own right, and be useful to everyone.  This kind of development is encouraged by RISC OS, and there are plenty of mechanisms to make it straight forward.  The moral here is to think reusability - if lots of effort is going to be involved, how can it be leveraged to be useful for other projects or not be a one-off?  This is crucial when there are so few developers for RISC OS.

Resuability and Open Source

I'm not going to pretend that open source software is the epitome of reusability.  It isn't, but there are plenty of excellent examples of libraries and tools that are shared between many programs, and have gained from exsposure.  Let's take an example from RISC OS - NetSurf. Let's ignore for the moment that NetSurf itself as a RISC OS browser might be considered an example of this wheel reinvention, and consider the components that make up the application. Among other things, the NetSurf developers used many components that already existed to considerably reduce the effort they would need to go to - these include UnixLib (the Unix C Library), cURL (URL fetching library) and graphics libraries like libjpeg.  There were no practical options for some other items - Tinct (fast graphics plotting) and rUFL (Unicode font management) - and so they had to be written from scratch.  However, they were developed in a way to be reusable.  Tinct is now used in Firefox and some other programs and rUFL will in time be used in ported application include Firefox to handle unicode fonts.

One More

I'd like to name one more example, FirefoxI, the frontend which was developed to try and provide some of the RISC OS nicities to what remains a somewhat "raw" unix port. Now, I don't want to point the finger at Jon Ripley.  It's clear he was well meaning in doing this, but I'd like to examine the thinking that might have led to its development as again typifies RISC OS development, and what might have been a more satisfactory solution.

There's no doubt that the current Firefox incarnation is not very RISC OS friendly - I stated that this is how it would have to be to start with for it to be possible to do the port at all, and can hardly apologise for doing precisely as I stated.  I also stated that I would in time, make it work much better with RISC OS, and this is what am I now working on. 

Jon stated that FirefoxI was a "personal project" as so many of these things start out as - of course, due to its nature, it can never properly implement the features that it craves to - those must be built into the application or supporting libraries.  If it really was a one-off, designed to do just what the first version did, then I wouldn't have been so bothered - but it does look like there's a good deal of work planned for it. 

So what's the issue here?  Apart from Firefox itself being a huge application, and requiring a somewhat specific setup to do any development on it, what could Jon, or other developers,  have done instead?  Well, one example might be clipboard support in DeskLib, which I've spent some time on implementing, but isn't yet complete. If for example, Jon spent time on this, then not only it would it be there for native RISC OS applications to use, but then ChoX11 (my X to RISC OS interface library) would immediately be able to use it, and therefore it would beneift not only Firefox but also any other ports that make use of the RISC OS clipboard.  Plus it would have freed me to properly implement some of the other features which FirefoxI tries to add.  

Obviously, this requires a little bit of coordination, and it's all too easy for developers to want to do their own thing.  But surely you can see my point - a little bit of effort in the right place means code becomes widely used by many people, saving them time to do other things, and your effort doesn't become stuck in a potentially redundant project.

Conclusion

There's no firm conclusion here, but I hope my position is clear.  Before embarking on a new project, consider how your time may best be spent, how it might address many problems instead of just one, and how you might be selling yourself short if you decided what you're doing is "just a personal project".

I've also not touched upon many of the reasons such repitition comes about in RISC OS - I could make further hand waving arguments about why it might be the case - perhaps a sense of British pride is partially to blame here - but perhaps I'll leave that to you to consider.