RISC OS

I'm of course referring to the recent article on drobe. I wasn't going to comment on this originally, as I felt it was a somewhat shallow article, intended only to generate some journalistic controversy, without conveying anything particularly new.

However, some of the comments are worth responding to in detail, as there's still a huge gap in understanding by users, especially the most vocal ones, in what's involved in software development. This is despite numerous essays on the topic by myself, and endless demonstrations from various quaters on what does and doesn't work.

And despite Andrew Hill's objections, both NetSurf, and all my projects and several other RISC OS projects use identical development models. I won't go into the details of why - I've mentioned it enough before. But the model is open source, collaborative development, minimising effort by reusing systems. This is something we know works, and works exceptionally well - we only have to look at GNU, BSD and Linux for that. It is no accident that we use the same model, the same tools, the same software and the same libraries. Few other approaches are viable for such large projects in a market with so little cashflow.

Even if we look at Martin's developement of ArtWorks, despite being commerical, it is not so different either - skilled development, building upon years of development, and adding several years more. People seem to forget that NetSurf has now taken around 4 years.

Sadly once again, John Cartmell has insisted he has valid commentary on this subject, despite repeatedly demonstrating he has no authority or experience on things which he tries to demonstrate an opinion. Yes, the repetiion in RISC OS is unfortunate - but it's not the application level at which it is the problem. I refer you to my previous article on this subject. The only thing more discouraging when developing RISC OS software than the technical difficulties involved, are false prophets like Mr Cartmell and a small number of his cronies who actively seek to mislead and and misrepesent the real problems that RISC OS has and the work of the people who really are doing things to solve them.

Let's get real. Software development can be hard. Sometimes really hard, and even if it's easy, sometimes it takes a very long time. RISC OS users are often either unwilling, or unable due to numbers,  to provide sufficient funding for more than a very small number of projects. And RISC OS needs lots and lots of these projects to even be considered seriously by the outside world. Only druck's comments on the article in question reflect the situation in any kind of accurary or detail.

Historical RISC OS development has been short-term hole plugging. That's part of the reason there's so much repetition, and little focus on long-term development. We can partly blame Acorn for that, and partly the rose tinted spectacles worn when we view our "superior" OS, which even persists today.

I've said it before, and I'll say it again, because it bears repeating. Firefox wasn't a single project. It was a collection of related projects - GCC, UnixLib, porting tools, ChoX11, autobuilder - all projects under the above mentioned collaborative development model. Moreover, all projects designed to significantly reduce - I'll say that again: significantly (I'm talking orders of magnitude here) - the effort involved in developing new software, and especially to allow conversion of software from other platforms.

And why? Because that was the most practical way to achieve what users wanted - bringing high profile open source technologies to RISC OS that users are so good at going on and on about.  But not in the short-term way I mention above.  Not in a "port and forget" way that's been traditional of some conversions to RISC OS.  But rather in a way that means that any technologies developed or improved for the port could be reused for new ports, and reduce their "time to market".  And in a way that new versions could be generated very easily, in a predictable, repeatable fashion. 

Ultimately, we can only provide the methods and the means.  The motivation must be there also.  For developers, this means finding some reason to bother continuing - whether it be financial or otherwise.  Certainly it doesn't include putting up with the cronies.  For users this means getting involved and adding something positive to the process.  It doesn't mean the slacktivism that's sadly prevalant in the RISC OS community, where slagging off someone and having a strong but basless opinion is somehow considered a worthy contribution.  I don't mind strong opinions - I really don't.  And even if I disagree with it, I'll respect it as long as it has some kind of justifiable basis that you can point to.

Forget "ransomware" or whatever other term you want to apply.  That's not the point.  RISC OS needs focus.  If there's focus, then funding and the means to bring it about can be found.  At present, RISC OS doesn't have very much focus.  It and its users often don't understand  or can't decide what applications it needs, and even when it can, those answers are naturally reactionary, as it tries to match facilities found in Linux, Windows and Mac OS X.

As for actual development, bear in mind that the number of people able to do significant amounts of it due to time or skill constraints is very small, and isn't going to be replaced very fast if they decide to leave due to a perceived lack of focus, or being fed up with people talking our their arse.  Much of the specific technical work will naturally come from them, but I'll again repeat something I've said many times before.  Get involved.  Find ways to get involved.  There's a greal deal to do that anyone with a little imagination and some free time can do.  One irony is RISC OS users have a significant proportion of those who might in fact be expected to have free time - the retired.  I'll be providing something in the next few weeks which may be one step in this, but  it's really up to the users to  do this.

So, the moral?  RISC OS is in trouble - more than it has been in for some years, and 2005 may have been a peak in appication development unless there's an attitude change.  And that will need to occur first before we can talk about funding software, or development models.