I find myself wanting to give some final thoughts on RISC OS as a whole, but I am not sure if I am going to merely be repeating previous comments and frustrations and just come across as griping. In the end, it doesn't really matter as anyone who disagrees with my viewpoint can disregard it, or voice their views on their own soap box.
Without a user base, RISC OS dies. That was one of the foundations of the work I did on the OS. Where early on I wanted to do the things that were of interest to me, I became focused on trying to keep the current users happy. When we (at RISCOS Ltd) were told to discontinue work on any portable systems, it was a clear sign that bringing new people in was not the focus. Without new hardware, the OS remains stuck in the past.
Much of the work which was done within RISC OS tried to retain compatibility, and to try to work with third parties to ensure that this remained the case. In many respects, this willingness to retain compatibility at all costs caused the OS to be held back.
It took a long time for the situation for new hardware to change - and unfortunately it changed due to actions by Castle that I cannot condone. I always felt that, whilst I tried to do everything properly, and to ensure that other groups were kept informed and happy, Castle were far more inclined to do whatever they wanted, and clear up with bullying from solicitors later. Their attitude and actions caused much resentment from other developers, and many difficult meetings between the parties involved, I believe. It is frustrating to me that whatever I might do, Castle were always the golden child in the eyes of many people.
I have voiced the view previously, that the Iyonix should never have been, and the flagrant GPL violations which caused that issue to come to a head were a blight on the RISC OS world that should never have happened. Sadly, those events ended up with Castle obtaining license agreements that would never have otherwise come about, and which further split the RISCOS Ltd/Castle relationship.
There were stupid things with the !Printers source - which RISCOS Ltd had made open source with Pace's agreement, and subsequently Castle wanted removing. The plan - which had been working - was that third parties could develop this component quite easily, and without using the valuable resources (that is, Matthew and myself). The application was isolated and could be enhanced without impact on the rest of the system quite easily. Unfortunately, by that time, the maintainer had died (sadly), and it was difficult to do anything with SourceForge.
The fact that these first steps to try to grant greater access to isolated components were quashed meant that there would be no further attempts. Obviously any integrated component was going to be even harder to work with, so there was no hope of any movement to open source them.
There were attempts to try to reconcile, but these never really went anywhere, and Castle certainly showed they were never intent on working with us. On top of the general disagreements, I remember a conversation with Castle where I was told that the only good things about Select were the changes to !Paint and !Draw, which both pissed me off, and made me question what they thought I did every day. I accept now that their view was that I was a code monkey who churned out whatever I felt like and most of it was in their opinion pretty crap. They are entitled to have the view, and I will leave anyone else to decide whether that is right or not - I am certainly not going to deny it, I will let the body of work and its quality speak for itself, whether to confirm that view or not.
Castle's final act, 'licensing' the source to ROOL, was a final insult to the people who had put money into RISCOS Ltd for OS development, or a statement that the OS development by RISCOS Ltd had failed. I am not going to argue either way and I have not followed their developments since I left, other than in passing.
The problems that I had over Castle's broken squeezer, were the last of many straws for me - intentionally breaking the workaround for their previous breakage after I informed them of the problem, without any other communication, just convinced me that either they were being malicious, had no respect for my explanation and competence, just didn't give a damn or all of the above.
In retrospect, selling my shares to Castle probably wasn't the best of plans, but the money was nice to have, and I thought I would be staying out of RISC OS in the future.
To go back a little, MicroDigital had failed the market in equal measure with the Mico and Omega. I think that is pretty much without doubt, really, given the press and user comments of the systems. My own experience of the Omega was only about a day and a half of playing with it, trying to get parts of Select 2 to work on it because the machine suddenly refused to even boot. The Mico ... oh good gosh. I remember meetings where I just could not believe what I was hearing. Obviously I cannot repeat much of it, but I can say that they wanted us to supply the OS to them blind - we would not have access to a machine to test on (this was a requirement of the hardware manufacturers agreement). I believe we did get a machine eventually, long after its 'release'.
At one of the share holders meetings, early on, we spoke to them and they expressed difficulties they had had in one particular area - we were unaware of the problems - and which they were very concerned with. We went home, and spent the Saturday building a custom version that would address their problems and mailed it to them so that they would have it available for their very important thing they needed for Monday.
Wednesday rolled around, and we asked them whether they had managed to get everything they needed, only for them to reply that they hadn't looked at what we had sent and it wasn't that important. That sort of thing annoyed. Whilst I do not mind doing things for people in a rush when they need them, it's pretty insulting to find that the urgency they've expressed is a complete fabrication.
STD's projects were more successful, and I found myself working more closely with them. However, attempts to ensure that they were involved in the work, and supplied the relevant bits to make working hardware were generally unsuccessful. The last working A9 image I had was based on a system that was about 9 months old and still didn't support NVRAM configuration or audio. Whilst things were better, it still didn't work out.
With RISCOS Ltd themselves, I have always said that I am annoyed that they did not do enough to enforce their licence agreement and quash the Castle's 'do what they like' behaviour, early on. That mistake meant that both the investors lost out, and that the market as a whole fragmented significantly. I personally found it incredibly irritating to discover that the things that I had demonstrated as 'this is some of the direction that these things are taking, which are confidential', would turn up in discussions at shows or on news sites.
Dealing with some people was difficult at times. People like John Kortink, who is incredibly clever, but who I often had disagreements with, were more difficult because neither of us tended to back down. I regret that he has never really forgiven some of those disagreements, but there is enough to feel guilty for in my life so I try not to let that one bother me - though clearly it does, or I wouldn't mention it.
But that is only a symptom of a far larger problem. Trying to cater for every user, even in a small user base, was never going to work. For every little thing that changed, and an application or tool broken (usually because the behaviour had been broken or discontinued) people were lost. Keeping everything the same meant I might as well not do anything at all - and some of that comes across in the completely cosmetic things like the Icon Borders or the ImageFileRender stack which couldn't break anything that went before (ok, the Icon Borders changed the presentation but you could put everything back the way it was before).
Essentially people wanted to upgrade but wanted everything to be exactly the same as it had been before. Trying to reconcile this meant that I was constantly tied in knots. Components like thecouldn't lose support for APCS-A because some users absolutely relied on applications that only had APCS-A versions. This should have been alleviated by the system being softloaded, but in general it was viewed that the latest version should keep everything the way that it had been.
In many cases I should have been more forceful about things, but I was bitten by this problem when I decided - and stuck to my decision - that Absolute files must have AIF headers, as had been declared 10 years previously in an application note before the StrongARM was released. If nothing else, this reminded me that unless you break things developers won't do anything. And if you break things, developers will make your life hell, whether you have a good and well argued case or not.
In all of the above complaints there are a whole load of reasons that things played out the way that they did, and I can see the reasoning that caused them. I understand some of Castle's actions; I can understand the technical obstacles which thwarted MicroDigital; I can see the reasons behind some of RISCOS Ltd's actions. I even understand that users have different needs and some are less important than others. But all around, these things are what they are, and have led to the place that RISC OS is now.
I took some very different routes in my architecture of the OS than some of the ex-Pace employees would have done, I think. I favoured a significantly more modular Kernel, and wanted to hardware drivers to be implemented through RISC OS interfaces with less specific support provided by the OS, so that hardware authors just had to write a module that did the job. Pace's general direction was that the HAL would solve the main abstraction problem, and by moving Kernel dependencies outwards, away from RISC OS - whereas I wanted the dependencies to move inwards, within RISC OS itself (with the exception of the absolute minimum that had to be specific to the system start up).
I believe that my solution made it possible to develop hardware drivers and to re-target the OS without needing to understand (or work with) any part of the core Kernel or other OS modules - all of which was a requirement of the license. I don't think that this was a bad thing, and I don't believe that any hardware developer should have to delve into the Kernel in order to provide any implementation of their code, and that goes for everything from interrupt drivers upwards (see my earlier rambles about IRQ handling).
This is quite opposite to many other systems, and you can happily argue that I am crazy and reducing the system to modules in this way is a detriment and that is why many other systems don't work that way. Some do, though. I understand the viewpoint, but just disagree with it. Not only does it fit well with developers, but it also makes for a more stable system in terms of ABI compatibility, and makes the maintenance of the system much easier if you have strongly defined interfaces on one side of the system.
Architecturally, the system must have strongly defined interfaces. The entire OS is predicated upon that design. Developers expect that their interfaces will continue to function. Where I had broken them, these were almost always for good reasons. If you are going to provide architectural direction for the OS, you have to understand where the changes need to be made and make them.
Things like that are a technical challenge and decisions of that type
can be seen to have advantages and disadvantages depending on what you are
trying to achieve, so I don't mind in the slightest that such differences
exist. I do mind that, as I watch
I see people complain about bugs that were fixed years previously. It
bothers me. The Image File stack was a large undertaking, which had the
potential to spin off many other things for developers and users, but
which was underused.
The problem there is that now Select is viewed as the poor cousin, despite being (obviously in my own opinion) significantly more advanced. The ROOL branch is a RISC OS 3.7, made 32 bit and to work on some other hardware. That isn't to be sniffed at, but it is still RISC OS 3.7 (yeah, you can argue that it is closer to 4.0, but that's not a whole lot better really).
I made a big deal out of trying to get out change details for the OS, so that developers (and users) could see what went into the system, and to provide some release notes on what went into the releases from a user and an API point of view. The release that went out with the preview version of Select 4 included both reasonable change notes and API details (look, it isn't a PRM - that is an insult to people who wrote the PRMs), but no user documentation, as the system was not ready yet.
I do not know if similar things had been produced for other releases - I never saw anything comparable from Castle or ROOL, but then I never looked that hard.
The community shrunk significantly and from the look of things, I do not think that it has really got any better since then. Certainly there is very little of note that has been produced. There are a few systems, as far as I can see, but I've not really seen much in the way of software. Maybe I am not paying enough attention, and that is probably fair comment, as I really only watch 'comp.sys.acorn.programmer' in passing, but I am still baffled by things on there at times. When one of the longest running threads of late is a log about someone's conversion of a version of Moria (a C application) to BASIC and ARM assembler, I think it really says something about how low things have fallen in quality.
I know it is just me, but my recent attempts to help (albeit, I am a bitter guy) when people asked how to do things have been responded to with advice that tells them to use the APIs that were added in Select - only to get the response that they are not available to everyone. Fine, there is nothing that is going to change that, and if you want everything for free then all the best to you.
Ok, so I have whinged about other people (and a little about myself), so where did I go wrong ?
The 32bit and hardware abstraction work should have been done earlier. Partly this was because I did not feel comfortable launching into it earlier on, but mostly it was due to a continuing belief that re-doing that work was going to just waste time. In retrospect, it could have been done far sooner, as there was never going to be any merge.
We should have defined, up front, what was going into each release. The principle of releasing whatever was ready at intervals did not work, despite being themed around particular areas (networking, graphics, etc). The development time-frame was too long, which increased user unhappiness. A lot of that was that features were not ready, and you can attribute that to my stacked attitude to development - as a need is found I would move on to addressing the need, and when it was finished return to the original task. Poor user relations did cause problems at some points - I stayed away from users in the end because I had to focus on getting things written.
I do not believe that anything could have been done to improve the situation with Castle, as I believe that I did everything I could to try to make things work, and got back a slap in the face.
I do consider in many respects that the work that I did on RISC OS was wasted. That is a pity, but that's the way that things go sometimes. Other people take over and they do their own thing, whether I feel it is right or not doesn't matter; I am not involved and I have got no rights to critique.
At the end of the day, RISC OS was always the system I enjoyed working with, and I certainly felt that I could work with and talk to anyone about any part of the system with confidence. I cannot say that about much else, and it is still sad to have that end. On rare occasions that anyone talks to me about RISC OS things, I have been reasonably happy to answer questions, but it left me financially strained (as with many in the market), and emotionally drained (again, as with many others).
Towards the end, I was very frustrated with all the politics and groups involved. I felt that the failings to retain users for Select were my fault, and that Castle were making the market completely impossible to work in, not to mention the disdain that had been shown by many people for the things I had done. That, coupled with some personal issues, in 2005 left me unable to do much at all for a couple of months without bursting into tears. Rearranging some things helped for a while, but ultimately I could not stay doing something that was upsetting me so much.
I have never been good at letting go. I hope that these rambles would make it a little bit easier to do so. I don't know if they will, but I hope that the many rambles that I have written about my time working with RISC OS gives some idea of how much I cared about the system, and a little insight into what it was that I did for many years. Thanks for reading.
<parting type='Adams'> So long, and thanks for all the Fish </parting>.