Interview with a ROS Open shareholder

Published: 16th Jul 2006, 16:08:10 | Permalink | Printable

Andrew Hodgkinson talks of his time at Tematic

Andrew Hodgkinson is a shareholder of the mysterious new company RISC OS Open Ltd, having previously worked as a RISC OS software engineer at Acorn, Pace and Tematic before it lost its developers. In an illuminating interview, he reveals his thoughts on the OS divide, what the teams at Pace and Tematic were working on, and where their work could take RISC OS if released.

Andrew Hodgkinson is a 30-year-old programmer who worked at Tematic as a software engineer right up until Castle closed down its embedded engineering team in October. An enthusiastic rower and musician, he previously worked at Pace Micro for three years, when the company used RISC OS in set-top-box platforms, and before that, three years at Acorn. As someone close to the development of RISC OS, he has seen the work done by fellow staff and is aware of how these technologies could possibly surface as features for desktop users, particularly if RISC OS 4 and 5 were to be combined.

"In my opinion now as an outsider of the company, it is going to be extremely hard for Castle and RISCOS 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," said Andrew.

"I really hope to work on RISC OS again in future. We were doing some great stuff with next generation audio and video architectures that were intended to work on desktop machines as well as set top boxes."

He argued that RISC OS 5, as used in the Iyonix, features a "solid foundation" and engineers have been able to port the operating system to numerous ARM processor powered products; the most successful platform being IPTV set top boxes which can provide television programmes and other multimedia content to viewers with broadband Internet connections.

"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," he added.

"For my own part I really hope to work on RISC OS again in future. We were doing some great stuff [at Tematic] with next generation audio and 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 that can be released.

"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."

Castle, Tematic logos

A merged OS, if it were to happen, would essentially be a combination of features from RISC OS 4 and 5, including the enhancements released via the Select scheme and the developments promised for Select 4. Core system components, such as CDFS, TaskWindow and MessageTrans, will enjoy bug fixes contributed from each source code tree. This comparing of notes between engineers over the various faults they've found and addressed will lead to a boost in the operating system's stability. Gaps in the functionality of applications and software libraries, from Paint and Draw to the Shared C Library, will be similarly filled in with contributions shared by either side; the overall effect would be a synchronisation of efforts and progress made so far by the independent teams at Castle and RISCOS Ltd.

A common interface for writing USB and PCI drivers could be devised, bridging the gap between the Castle and Simtec hardware stacks, thus opening up a greater range of supported hardware. The RISC OS application programming interfaces (APIs) are the blueprints that show how software should communicate with the operating system to get work done. Differences in APIs in RISC OS 4 and 5, such as in DragAnObject module, would have to be ironed out in order for a source code merger to take place whilst ensuring that no existing compatibility is broken.

It will also be eye opening to see how RISCOS Ltd. and Castle will reconcile their incompatible policies on documentation for programmers: RISCOS Ltd. believe in charging people for copies of the Select APIs, in the same way Acorn put a price on their reference manuals. Castle, on the other hand, publish their documentation notes for free on their website, an effort subsidised by the sales of their Iyonix hardware.

Andrew is in favour of providing programming resources and application plugins for free via the Internet. He said, "If anyone at Castle ends up going through the source tree they should find lots of things that they could consider releasing.

"What about all the Browse fetchers? Solid bits of code, not outdated; several bits of the STB video path could be useful; but it would have to be shared for free on the web site. This way, more developers can code to that interface, which means more software for Castle to use to promote its own hardware and more people that want to use that hardware in the first place.

"Selling OS extensions separately is troublesome because developers can't rely on them being there - that's ROL's whole problem really, and indeed, they recently realised it themselves and started on that push to get 'everyone' upgraded to RISC OS 4."

RISC OS 5 technologies such as Unicode, USB, and large wimpslot support would greet RISC OS Select headline features, such as the image file renderer plugins, the latter of which allows the Filer and other pieces of software to handle graphics files in a more flexible manner. Keyboard shortcuts in the Filer, as demonstrated in Select 4, and proper cut'n'paste facilities in icons on the desktop would be available to all users. Features and updates present each side of the printing system would be joined too

The main advantage of a unified operating system is that all RISC OS users, whether they own an Iyonix, RiscPC or A9home, can upgrade to the latest available version, which will have the same features and quirks regardless of the underlying hardware platform. This should minimise the amount of time spent by third party developers and dealers on supporting various different RISC OS releases as everyone moves towards the same concurrent version. RISCOS Ltd. are close to achieving this by supporting the A9home and RiscPC with a single version of RISC OS 4 that is compatible with 26-bit and 32-bit ARM processors.

"It's very frustrating as we were watching people developing things like the RISC OS DVD player software and thinking, 'what we've got solves all the problems they're talking about' - but we weren't ready to release it."

To achieve all this, it's estimated that both Castle and RISCOS Ltd. will each need to commit one programmer to the task of bringing the two separate streams of the operating system together. How the eventual coalesced RISC OS will work is up to the engineers; ideally, the system will work in the same manner as Adjust, RISC OS 5 and earlier ROM based versions of the OS in that it loads and runs as a self contained entity. Future updates could be softloaded or copied into Flash ROM depending on the host hardware platform.

It's expected that one side must compromise in order for the merger to happen. RISC OS 5 and 4 each have their own approaches to hardware abstraction, a technology that means the majority of the operating system is oblivious as to whether the computer is an Iyonix, A9home, RiscPC or some ARM9 embedded kit because the hardware abstraction layer takes care of supporting the specific electronics. The two streams of the OS organise their memory and handle translucent sprites differently too, which will need resolving.

Currently, Castle and RISCOS Ltd. each believe their implementation of 32-bit RISC OS is superior, so at some point the engineers will have to negotiate a settlement on what aspects of the underlying system should stay and what should be altered. Fortunately, both teams use CVS, a popular software management tool that tracks changes made by programmers to a repository of source code, which will assist in producing a combined operating system.

"There are a wealth of features at the core to RISC OS 5 that RISC OS 4 simply does not have, and since the big ones lie at a fundamental architectural level - notably, the memory map, HAL, and 32-bit technical approach - you can't just 'port them' to RISC OS 4. You'd be redeveloping RISC OS 5 as RISC OS 4, which is pointless. The higher level functions are more portable, and in merging it would probably depend on which component had the greater set of changes as to which you started from," said Andrew.

"For example, it looks as if the RISC OS 4 Window Manager has more changes than RISC OS 5, so you'd probably merge the RISC OS 5 extensions and fixes into the RISC OS 4 module, not vice versa. You'd probably more or less replace the RISC OS 5 Filer with the RISC OS 4 version."

"You'd probably more or less replace the RISC OS 5 Filer with the RISC OS 4 version."

Ultimately, especially for those users who have kept up to date with the latest versions of RISC OS 4 and 5, the united operating system would not appear to be visibly different to previous releases. Familiar desktop concepts, such as the iconbar, Filer and context sensitive menus, would remain largely unchanged, although RISCOS Ltd. have proposed adding an optional toolbar to Filer windows in Select 4.

Published Select features that allow the user to customise the look and feel of the desktop would be included; for example, the placement of window furniture, such as close, iconise and the scroll buttons, can be configured, and rectangular buttons like the 'OK' and 'Cancel' icons found in dialogue box windows can be replaced with more aesthetic looking buttons.

"The Desktop wouldn't look very different, though there is support for 180 DPI screen modes for very crisp high resolution displays that could be useful particularly for more embedded applications like digital signage or public information access terminals," commented Andrew.

Some pretty networking cable

Nonetheless, recent work carried out internally by Tematic could pave the way for greater modern multimedia support on RISC OS, which may appear with or without a merger. Codenamed Prism, Andrew had been working on a project to develop a system that controls and manipulates multiple streams of data. This system could aid the development of new software that supports so called voice-over-IP, a technology which allows modern computer uses to hold cheap or free telephone conversations over the Internet.

Other applications of Prism would be video players, provided the host hardware can deliver the processing power required, supporting MPEG 2 and 4 formats as found in Quicktime and Windows AVI files. It also handles 'metadata' within a multimedia stream, or in other words, information stored within a video that is relevant to the content being shown, such as subtitles and programme details.

This also covers interactive information typically used on cable TV set top boxes to display programme listings and other on-screen features. This technology is still work in progress as the Tematic team were hoping to overhaul multimedia support in RISC OS 5 for their set top box manufacturer clients; the goal being to create a system where a broadcaster can pump video and audio data 'on demand' from a single server source to multiple set top boxes.

Andrew explained, "At the very least playback from file, and much more besides, is possible with DVDs. The trouble is getting MPEG decode fast enough - really, hardware assistance is needed, so you'd try to do something with the Iyonix graphics card.

"It's very frustrating as we were watching people developing things like the RISC OS DVD player software and thinking, 'what we've got solves all the problems they're talking about' - but we weren't ready to release it.

"We could've said, 'wait for us' but since confidentiality means we could not give specific details, all this would've done is cause frustration over vague vapourware promises. There are some components that would help and are fully written and tested already, but I'm no longer responsible for their development or release.

Some pretty DVDs

"If the lights went back on at Tematic, you'd be looking forward to a really neat audio-video architecture in 6 to 12 months time, other project time pressure permitting."

Technologies found on other operating systems, such as pre-emptive multitasking (PMT), were ruled out by Andrew because they wouldn't suit the embedded electronic systems that Castle and AdvantageSix are trying to sell to clients; PMT forces applications to multitask by allocating them set blocks of time with the processor, whereas RISC OS currently allows applications to have as much time with the processor as they like - effectively, programs must cooperate with each other in order to achieve a multitasking desktop. If one application stalls, such as ChangeFSI or Oregano, then the whole desktop slows down as a result.

Andrew summed up a merged RISC OS as, "a 32-bit portable OS supporting over 1GB RAM, PCI devices, Unicode, a decent printing subsystem, modern Filer, flexible Window Manager, and robust native support for various 'foreign' graphics file formats.

"Get it running the likes of Ovation Pro, Artworks, Photodesk, MelIDI, as I'll assume someone will have worked out how to drive a USB MIDI interface and preferably the eMagic AMT-8 for my own selfish reasons, then add some kind of DVD and VCD player using an open extendable audio-video framework, plus Netsurf, Firefox and Oregano 3, with multihead graphics support. It's really not far off if you could just get the OS merge done and finish Prism.

"Whilst it's depressing that the RISCOS Ltd., Castle and Tematic situation makes this next step so hard to take, it's amazing to think how close the RISC OS market is to at long last having these sorts of facilities."

This interview was conducted in mid-November, last year, for Qercus magazine before we knew anything of RISC OS Open Ltd. The article however never appeared in print, and has until now remained collecting dust on a hard disc, because the magazine's editor has yet to publish a new issue since October 2005. Send your Qercus-bound articles to us today.

Links

Andrew's personal website

Previous: New RiscLua book online
Next: Blogging helped me code says developer

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

As an addendum, I must stress that Chris asked me various questions as an interview for Quercus many months ago, as mentioned at the end of his article. Therefore absolutely nothing that I mention has anything to do with RISC OS Open Ltd because it wasn't even a glint in a milkman's eye back then! IMHO the article's title is technically accurate, but perhaps a bit misleading, because the article itself has nothing to do with shareholdings and I wasn't a shareholder when interviewed.

When reading, please remember that the article expresses my personal opinions of the time. It contains a certain amount of paraphrasing and extrapolation based on what I said, particularly in speculative areas like the multimedia mechanism that is mentioned. You will note I give no details on *how* that mechanism is meant to work - I'm sorry to be vague, but that's Castle's confidential IPR so I will not discuss it. You'll just have to engage in idle speculation about it if you so wish! Personally, I'd contact Castle if I had serious commercal enquiries.

Chris' condensing of my original text was needed because I'm a permanently verbose person (!) but it's possible to lose some of the details in that kind of process and paint a more black and white picture than I'd perhaps intended. So long as Drobe readers recognise that this is a historical expression of personal opinions, I would hope that they will see where I was coming from back then. In the months that have followed, times have changed and my opinion with them, but that's another story...

I must thank Chris for finally getting this aired, even if it's a little out of date now.

adh1003 on 16/7/06 5:29PM
[ Reply | Permalink | Report ]

Most of it still seems very relevent. What most people still one is one 'unified' OS (even if it has different code for different hardware) and multimedia support.

MArkee

markee174 on 16/7/06 7:42PM
[ Reply | Permalink | Report ]

Great article and there was I getting excited about what to look forward to and as usual someone bursts the bubble!

Still if only Castle and ROL could see the way forward as Andrews personal opinion outlined then it might just give a further shot in the arm, begging the pun, for our platform.

Personally I would like to see Select 4 for the A9, RISCPC and Iyonix being the last of the add ons and then ROL and Catle working together on a plan like Andrews.

It might still happen in the meantime I still await Select 4 for my RISCPC let alone for the Iyonix

bluenose on 16/7/06 8:25PM
[ Reply | Permalink | Report ]

Wow, somebody talking sense, without the usual vitriol and FUD that usually follows in a discussion of the future of RISC OS. Is there a "Z" in the month?

JWCR on 16/7/06 10:27PM
[ Reply | Permalink | Report ]

Has anyone thought about making a pertition or campaign to try and get the two RISC OS companies to merge the OS. Maybe by creating a website and getting people to 'sign' it to try and pressurise the two companies to merge, as they would then see how many RISC OS users would want the companies to merge. If the merge was to happen it would move RISC OS forward vastly as Andrew has already said.

OliverB on 16/7/06 10:28PM
[ Reply | Permalink | Report ]

It's been tried (or more specifically, a petition to merge Select features into RO5): [link] Results? Well, you tell me...

Until both companies collectively remove fingers from behinds, or someone else forces them to, nothing will happen to move the OS forward in this way.

tamias on 16/7/06 10:42PM
[ Reply | Permalink | Report ]

"Fortunately, both teams use CVS, a popular software management tool that tracks changes made by programmers to a repository of source code, which will assist in producing a combined operating system."

How on earth does both sides using the same sourcecode repository get over the incredible problem of merging operating systems? You might as well have said "programmers from both sides breathe oxygen, which will help the OS merge process".

krisa on 17/7/06 8:54AM
[ Reply | Permalink | Report ]

Excellent article, very informative and relevant. With Tematic gone, I hope that Castle are still able to release their exciting multimedia developments for desktop RO. What barriers exist to prevent / slow them from doing so (apart from manpower/funds)?

timephoenix on 17/7/06 9:32AM
[ Reply | Permalink | Report ]

A very informative article and I'm also glad Chris was able to publish it on Drobe, seeing the delays in getting Qercus to press.

"Maybe by creating a website and getting people to 'sign' it to try and pressurise the two companies to merge, as they would then see how many RISC OS users would want the companies to merge."

I'm afraid that may only serve to 'advise' them on desktop users' general opinion on the subject. This little desktop market is, at least for Castle, not its primary concern regarding RISC OS. There's simply not enough money in it for them to continue developing and grow. I'm unsure as to how dependent ROL is of the desktop market at the time, seeing Advantage Six uses a version of RO4 (Embedded Adjust32?) for purposes outside of the traditional desktop market.

In other words, the desktop market would need to grow tremendously for them to seriously consider the merge. Furthermore, like Andrew mentioned in the article;

"Currently, Castle and RISCOS Ltd. each believe their implementation of 32-bit RISC OS is superior..."

Meaning there would have to be a great, mutual advantage for both companies to consider this merge. I'm not saying it won't happen, just that there are some serious obstacles in the current situation.

hEgelia on 17/7/06 11:33AM
[ Reply | Permalink | Report ]

hEgelia:

"Furthermore, like Andrew mentioned in the article [...]"

That was something Chris said. Whenever he quotes something I said, he puts it in between quotation marks.

adh1003 on 17/7/06 1:36PM
[ Reply | Permalink | Report ]

For the sake of clarity, would it not pay to italicise Andrew's words in the above article?

jymbob on 17/7/06 11:12PM
[ Reply | Permalink | Report ]

adh1003: Indeed, I should've looked better. I apologise. I hope my point did not lose its relevance.

hEgelia on 18/7/06 11:51AM
[ Reply | Permalink | Report ]

So the question remains unanswered - what role can Risc OS Open play in the market when there is limited amount of co-operation between ROL and Castle?

nx on 18/7/06 12:55PM
[ Reply | Permalink | Report ]

An excellent and thought provoking article; I'm glad drobe has rescued it while it remains relevant.

With regards to the forked OS, I personally, and with a sad reluctance, still don't see where the realistic commercial motivation comes from that will drive either Castle or ROL to devote resources to merging the diverging branches.

Not that it bothers me as much as it used to; my Iyonix and RiscPC are networked together and I've become used to running applications where speed is an issue on the Iyonix and hoping back to the RiscPC to use the vastly improved !Draw, !Paint and !Edit, for example.

( What continues to seriously irritate is the lack of a competent RISC OS web browser. )

martin on 18/7/06 11:09PM
[ Reply | Permalink | Report ]

ABC

PeteWild on 19/7/06 4:42AM
[ Reply | Permalink | Report ]

> With regards to the forked OS, I personally, and with a sad reluctance, still don't see where the realistic commercial motivation comes from that will drive either Castle or ROL to devote resources to merging the diverging branches.

Surely the answer to that is: "Because the OS will die otherwise, leaving both companies in trouble"?

I'm not a major asset to the RISC OS community really - my time is spent doing other things in other communities. About the best you can say about me is that at least I bought an Iyonix. But I use Mac OS X for pretty much everything these days. And why? Because I can't see the major companies *doing* anything to bring things back together. And that makes my enthusiasm pretty much zero for the platform.

I was told in at the Guilford show a couple of years ago that RO4 and RO5 *would* merge. This has not happened. And then Castle and ROL did not explain *why* what was agreed there didn't happen - which just makes me feel I've been lied to. And if the main two companies are going to lie to me, why should I care about the platform any more?

moss on 19/7/06 4:51AM
[ Reply | Permalink | Report ]

In reply to Andrew Hodgkinson:

Perfectly said about this RISC OS matter !!!

The PERFECT solution is to merge RISC OS 4 and RISC OS 5 together in one RISC OS version. This is making RISC OS into a RISC OS TURBO version. It is about time, that both RISC OS versions are getting an overdwelming Turbo Boost !!!

datawave on 19/7/06 5:39AM
[ Reply | Permalink | Report ]

John Hoare has hit the point for me. After years and years my enthusiasm for RISC OS is waning severely due to the appalling attitude of both Castle and ROL. Please don't defend either of them, they are both to blame for a situation that will destroy RISC OS.

I suspect that both companies have enough (or more likely larger) non desktop business that they believe things can carry on as they are. This would be incredibly short sighted by both of them. A "turbo charged" (to quote datawave) RISC OS with the relevant upgraded applications could provide a viable alternative to the world of XP. That in itself would boost the embedded demand for both Castle and ROL products way beyond anything they currently have.

mripley on 19/7/06 8:26AM
[ Reply | Permalink | Report ]

PeteWild: "ABC" - the Basic Compiler? Can you expand on that a bit?

jms on 19/7/06 8:40AM
[ Reply | Permalink | Report ]

Thanks to Andrew and Drobe for a superb article giving a clear and rational engineering perspective on RISC OS issues, rather than the somewhat emotional views often seen here.

However, as Andrew was keen to point out, this contribution was actually made many months ago and the situation has changed substantially since then. I’ve been heartened to read the healthy discussion that has been provoked by speculation about RISC OS and RISC OS Open Ltd. I’d like to contribute to this with my thoughts on the future of RISC OS, driven by embedded applications. Apologies for a rather long "comment" but I hope Drobe readers will find the following of value, or at least thought provoking.

During the last three years I’ve been presenting RISC OS to large consumer electronics companies, mainly in the Far East, for use in their products. Several things have become apparent:

RISC OS’s biggest plus is also its Achilles heel - it only runs on ARM (obviously). With 70% of the OS kernel being hand optimised ARM assembler it has an enormous performance benefit in its core functionality over compiled OSs such as Linux, VXWorks or Nucleos, as frequently found on embedded devices. But it is not processor independent. OK so use an ARM is the obvious retort; but you have to consider the range of ASSPs that are available for use in certain embedded applications. Whilst some use ARMs, many more use MIPS, as well as other solutions, PowerPC, or more proprietary processors such as STs or Hitachi’s. Consumer electronics is a cost sensitive business and software development is expensive; usually more so than hardware. OEMs want to see their investment in software being as future proof as possible, with the ability to reuse the solution on other ASSPs being a key requirement that RISC OS cannot meet.

OSs for use in embedded devices are generally perceived as being free! Linux is a prime example, no matter how badly suited it may be to embedded use, its perceived zero cost and the benefits of an open source solution often win out. Indeed it is frequently mandated by Telcos/Service Providers in their specifications for STBs on the grounds that its open source and the Telco will have access to a system it can work with an modify independently of the hardware manufacturer. In emerging markets without clearly defined standards this is considered essential for future proofing.

Even where the OS is not free, the revenue that can be derived from the OS itself is small with expectations for royalties being in cents per unit rather than dollars. Given the cost/effort in moving RISC OS into some embedded arenas its hard to form a realistic business case for using it.

To have confidence in using a new OS, the OEM wants to see numerous examples of where and how its being used already (by other OEMs), what the learning curve is for working with it, what tools and resources are available and what other risks and issues will be encountered. RISC OS is sadly lacking against these points.

The range of suitable ASSP’s using ARM cores is another limitation for various reasons:

1. Most ARMs are in mobile phones, we are too far behind, and there are too many barriers to entry in this market for RISC OS to stand a chance.

2. PDA’s – Win CE rules the roost – without integration with the office applications etc there is little prospect here. Whilst we could compete on price (CE is expensive) the cost of playing catch up would remove this advantage. A leading ASSP targeted at PDAs is Intel’s PXA255 (or rather was Intel’s…) Significant work has been done on getting RISC OS 5 to run on this platform – and a number of hardware solutions are available off the shelf from different manufacturers. However, its graphics architecture is not compatible with RISC OS; this is a perennial problem which has been fixed in different ways in the past, usually by swapping RGB in the Analog or Digital domains. However, the PXA255 is designed to drive LCD screens directly making such a fix very difficult.

3. IPTV STB – here RISC OC has had some success, though the ASSP options running ARM are limited. Indeed, RISC OS 5 has shipped, and is continuing to ship in 10s of thousands of STBs. Moreover industry players are starting to promote the technology e.g: [link] In the STB field we have clear references we can point to running RISC OS with more than 100K boxes operating reliably in the field, even so growing the business is not easy due to competition, primarily from Linux.

4. Media players. These would be an excellent opportunity for RISC OS – but suitable ASSPs are currently lacking. Some new silicon is emerging with ARM cores that may have applications in this area, time will tell if the opportunities here are real. The mobile phone sector already has a significant foothold – growing with the move toward 3G, so the opportunity may have gone.

5. Other embedded applications. Here RISC OS has a chance – but would need a different business model. Take for an example a company wanting to develop a hand held terminal for a specific application, say running on a PXA255 (and where certain OS graphics limitations didn’t matter). Hardware is available almost off the shelf but using it with RISC OS under existing licensing arrangements would be too torturous given the effort and skill involved in porting the OS to new hardware; Castle no longer has the engineering resources to do this – and the solution is not sufficiently developed for a third party to easily build the OS itself.

This leaves the desktop market. Regrettably I see no commercial motive for any company to spend money here, the potential return is just too small. Nor do I see any sign of co-operation between the main protagonists that would be necessary to let this happen. The only way the desktop market will advance is in parallel with an active embedded market. This has advantages for both areas if cross fertilisation of technologies and developments occur. This could in turn bring about new hardware for the desktop, and new application software.

So what is the solution? A complete change of approach: make the Operating System Open source and encourage users to contribute to it, use it and drive its ongoing development. This is the only scenario I can see in which the solution might prosper – short of someone investing a few million quid to fund further development.

Open sourcing RISC OS 5 (or at least, the majority of it) would have the following advantages:

- Stimulate use of the OS in new products/hardware (embedded and desktop) - Grow the user base - Develop a community providing references of the use of RISC OS as examples to others - Allow others to contribute to its development allowing it to move forward rather than stall as it is now - Permit some unfinished developments to be completed by others, or catalyse other projects - Provide a single public repository for the OS sources driving and enforcing a merger back to a single source tree. - The ultimate goal is to make RISC OS the de-facto standard for use on ARM (rather than Linux) but this maybe wishful thinking.

What would be the benefits of this?

A. To Castle. The initial reaction would be why would Castle do this? But, it opens new opportunities for Castle which is essentially a product business. By allowing others to contribute to the development of the OS, they have the opportunity to develop new hardware at lower cost which ultimately is to the benefit of all involved. Castle also provides the tool chain – which would see an uptake in demand, and, if successful other value added opportunities for Castle, such as consultancy work would emerge. Allowing competitors access to what has hitherto been core IPR could pose a threat, but my belief is competition is healthy for the market and will ultimately be of benefit.

B. To ROL. ROL would have to make a decision, in my view a simple one: continue on the road to nowhere or come back and join the party. ROL could contribute some of its sources (not necessarily all) to the open source repository stimulating the community to start looking and discussing the issues of remerging the OS into one. ROL would then also benefit from a number of users working on the development, rather than its own exceedingly limited capability. Rather than trying to deliver an OS as a whole entity, ROL could remodel its business to deliver a set of premium desktop extensions running on the core OS provided by the Open Source project. If the Open source project provided a base OS that would run on Iyonix and other platforms, with select compatibility, ROL gets an immediate increase in its customer base for a more limited effort, and the OS cores get reunited. In essence, this approach is actually what was envisaged in the agreements between Castle and ROL to merge the OS versions anyway.

C. To OEM users. An actively developed OS in the public domain with everything being visible and accessible (i.e not under the control of a single supplier company). This should remove many of the barriers to entry we see currently. An example might be Advantage 6 (And this is pure speculation). They may see an opportunity taking the RISC OS5 sources and HAL (proven in the field in 10’s of K units and known to be reliable) and merging them with higher level work of their own to complete their solution. I know of several other OEMS who would be more attracted to using RISC OS under these circumstances.

D. To the desktop user. An OS that’s been actively developed, moving back towards a single source tree and stimulating others to generate both new hardware and improved applications. And further benefits arising from its development and use in the embedded field. There maybe other attractions, e.g. if !Browse sources were made available to stimulate browser development maybe as an adjunct to the Netsurf activity.

In conclusion, I can’t see a better option than making the entire OS open source as a way to resolve the current issues and problems associated with perpetuating the use and development of RISC OS. There are of course many details and mechanisms that would need to be considered in an open source project, but I’m not going to comment on what those might be. However, I’ll be interested to know what others think of Open Source as a reality.

I should point out that the above views are my own, and not made in my capacity as a director of Castle Technology or Pattotek Ltd. Furthermore, whilst I know the people involved with RISC OS Open Ltd, I am not connected with the company but wish them well with their new venture, whatever that maybe.

PeteWild on 19/7/06 9:34AM
[ Reply | Permalink | Report ]

PeteWild: thank you for that assessment.

Personally, I agree with your conclusions 100% and I'd add: if open sourcing RISC OS *doesn't* happen, and the only viable business is the embedded/STB market (as you outline), that's fine for companies such as Castle and Advantage6 - but the desktop side of the business will shrink further and further, meaning it's a nice success story people can point to, but there'll be no RISC OS on desktop computers.

I'd be very surprised (pleasantly), however, *if* the entire source tree were open sourced and an effort made to garner an enthusiastic development community around it.

Jaffa on 19/7/06 9:51AM
[ Reply | Permalink | Report ]

I would just like to thank Peter Wild for his thought provoking comments.

I can cetainly understand his reasons for beliving that open sourcing is the best way to procede and I have a some simpathy to that opinion.

However I am sure there are many good arguments to the contrary.

Vic

vshears on 19/7/06 11:08AM
[ Reply | Permalink | Report ]

If Castle are really interested in selling RISC OS, as has been reported on Drobe, then maybe a fund could be set up to raise at least enough money to persuade Castle to allow open-sourcing of some, or all, of RISC OS?

Even if that were possible, the question for me is whether that money would that money be better spent on funding new software. For example, a finished Cineroma would be a major step forwards for media compatibility, offering RealAudio, etc. ([link])

Or maybe both strategies can be encouraged?

Stewy on 19/7/06 11:27AM
[ Reply | Permalink | Report ]

PeterWild:

Which OS license are you thinking of? If it was a joint GPL/dual there would still be licensing fees.

As you say, Castle still offers the tools and could add in commercial extensions, migrating then down into the GPL over time.

The question for ROL/Castle is whether they have a better plan. Otherwise, the value of the code will decline until it has no real value and it is too late to GPL it and achieve anything.

markee174 on 19/7/06 1:49PM
[ Reply | Permalink | Report ]

In reply to Stewy:

The question is what sort of figure would it cost. 30K, 300K, 3M....

If you were looking at 30K and you could get 1,000 people to join up, you could make them founder members and setup a foundation to buy it and release it as GPL.

It might even tempt Peter to reconsider leaving the market...

markee174 on 19/7/06 1:53PM
[ Reply | Permalink | Report ]

I can see a few problems with Peter's model, and one is transitioning Castle and ROL to use this model, both from a financial and operational perspective.

Operationally Castle could certainly continue producing its hardware and STB's, they appear to have an established and reliable revenue stream here (especially from STB's)

ROL would would most likley require the repository to be well established before shifting it's development to support this. As OS sales are ROL only major revenue source, the would be taking a much greater risk than Castle. The repository itself would require constant maintenance and support, a potentially significant financial and resource commitment. They would certainly have to have some rock-solid assurances from Castle that it is going to support this business model for the long haul.

In summation, my admitedly limited view of the current relationship between these two key players precludes their ability to co-operate that closley and that relationship and business model is as important as open sourcing RISCOS is.

All I would say to ROL and Castle at this juncture, is prove me wrong. Agree to plan for this eventuality, see how viable it is commercially. You both have a good deal to gain (especially ROL, with its eggs all in one basket) from a cooperative play like this, it could grow both companies another significant source of revenue.

JDC on 22/7/06 6:54PM
[ Reply | Permalink | Report ]

JDC:

There would be huge risks. The question is whether they are greater than the current situation.

markee174 on 22/7/06 7:27PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

Manchester RISC OS Jaunt
Martin Hansen does Northern dealers

21 comments, latest by Anon on 3/1/04 9:06PM. Published: 21 Dec 2003

Random article

Further details of RiscCAD on CD

Discuss this. Published: 28 Feb 2001

Useful links

News and media:
Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • Drag'n'Drop • GAG-News

Top developers:
RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn

Dealers:
CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster

Usergroups:
WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • WAUG • GAG • RISCOS.be

Useful:
RISCOS.org.uk • RISCOS.org • RISCOS.info • Filebase • Chris Why's Acorn/RISC OS collection • NetSurf

Non-RISC OS:
The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign

© 1999-2009 The Drobe Team. Some rights reserved, click here for more information
Powered by MiniDrobeCMS, based on J4U | Statistics
"I must take exception to the publishing of my private email to Drobe. But then they are renowned for bad form"
Page generated in 0.4304 seconds.