As someone who helped turn off the lights, I'm not entirely sure what project is being mentioned, though I have my suspicions and if correct it's a reference to a piece of hardware, not software. I'm unsure of the confidentialities by which I'm bound as an ex-employee, so I'll err on the side of caution. Suffice to say that this was certainly not the only problem or the whole reason the Tematic employees had to leave - not that this should be of much surprise to anyone here.
As I understand it Castle continue to manufacture, develop and support the Iyonix, though they do so with substantially fewer technical staff. Desktop RISC OS development will inevitably be slowed considerably in my opinion. Further, again in my opinion as, now, an outsider of the company, it is going to be extremely hard for Castle and RISC OS Ltd. to proceed in a profitable fashion without putting aside their substantial historical differences on both sides and both making compromises in order to attempt to produce a unified source tree - assuming either company has the engineering resources to do so.
The core of RISC OS 5 is well engineered within the traditional wider architectural constraints of the system. The implementation of the HAL is solid and has proven itself on several occasions in rapid ports to relatively alien ARM-based platforms. IPTV STBs based on the technology continue to be market leaders for performance, features and stability. It would be a crying shame for all the work, debugging, and carefully thought out APIs for 32-bit support dating back to some of the die-hard Acorn engineers working under Pace, to be thrown away in favour of an OS based upon the at the time work in progress pre-HAL RISC OS 3.8. Taking the RISC OS 5 base and adding in many of the good new features RISC OS 4 brings, such as any fixed bugs still present in RISC OS 5, Filer enhancements and the modular image rendering system, would be a sensible way forward.
Frankly, I think this is the only way forward. The current development of 32-bit capability in RISC OS 4 using APIs that differ from or even clash with RISC OS 5 equivalents is extraordinarily destructive in such a small market. Whilst RISC OS Ltd. even having to do this 32-bit work at all seems daft, they in turn must surely recognise that such technology cannot be handed over for free, because it cost a great deal of money to develop. The situtation is complicated further; RISC OS 4 on a RISC OS 5 foundation could even potentially help to produce 32-bit RISC OS platforms that would be in direct competition with Castle's offerings.
For my own part I really hope to work on RISC OS again in future. We were doing some great stuff with next generation audio/video architectures that were intended to work on Desktop machines as well as set-top boxes. It would be very rewarding to see all the effort and time put into such work evolve into something releasable. There are already components that I personally believe would be very valuable for people working on multimedia projects for RISC OS, and I hope that Castle recognise the value in their source tree and find a way to release some of these as upgrades in due course.
In the mean time I wish both companies good fortune with their respective businesses. I can only hope that they see a way to work together constructively in order to grow the market.
Right. That's the speech over with. Anyone want a RISC OS engineer? 10 years experience on web browsers, IPTV end-to-end and A/V architectures? Preferably based in Wellington, New Zealand?