Open Sourcing RISC OS
No, this isn't an ill-defined rant about why Castle ought to open source RISC OS - there's little advantage for them to do so commerically, no matter how much people might like it to happen, even if they were in a practical position to do so - and I don't believe they are.
What I'll instead argue is that certain parts of RISC OS ought to be open source. Crucial parts that affect all users, even if they don't realise it, parts that can be created from scratch and made much better than the Acorn original, and parts which can managed by specific developers who already understand them well.
Additional parts which form other parts of RISC OS include various applications and utilities in the boot sequence such as the confiugration application as well as other various bundled items. These are of lesser concern in this article, but still relevant.
In practice, this particular issue seems to now be all but resolved, however what if it had proved to be commerically impractical? This might have called for development of a "SharedFreeLibrary", which provided the crucial functionality of Castle's SharedCLibrary in an agnostic way to all versions of RISC OS. Such a version could have code contributed by several parties for the benefit of all. Indeed, most of the code already exists in UnixLib for such a project to be put together in a relatively short period of time.
What I'm not proposing is an all-out replacement of RISC OS functionality with random bits of code, like the ill-fated and poorly considered frx project. Rather, a more structured approach, making good use of limited developer resources and choosing carefully components that might add value to users and RISC OS companies by having an open source implementation. With such components, both third party developers and RISC OS companies - Castle, ROL, A6 and perhaps others could contribute code and then be able to freely use the result (subject of course to licensing). Users would enjoy a homogenous version across versions of RISC OS (although perhaps requiring a base version of RISC OS like RISC OS 4) and developers would benefit from being able to rely on features which were certrain to be present.
I appreciate that this is something of a utopian view, and in the real world is constrained by time, effort and commerical concerns. Nevertheless, I'd like to propose some projects that might benefit from this approach.
To at least start to address this, as well as RISCOS Ltd's apparent reluctance to persue Iyonix developement, there's no reason why at least some Select features couldn't be provided in part by open source implementations. To start with, some of the new APIs, especially those dealing with graphic effects, would only need to dummy functionality. I appreciate too, that Select on the Iyonix does require some kernel-level changes, but given code that is "ready-to-go" and the correct information, there's no reason Castle couldn't be convinced to make these changes.
Allow me to stress that there's some degree of speculation in what I've named above. I'm not familiar with most of the specifics of the Select changes, and am not in a position to name features which might be suitable for such treatment. But there's another side to this theoretical situation:
Instead of ROL's existing subscription scheme, they could instead contribute and open source code (it would of course have to be code that they had full ownership over) to this project. This could be done on a bidding/pledge arrangement where certain elements were made available piecemeal when the required level of financing was met.
And is this situation realistic? Perhaps it is a bit too egalitarian for the sometimes conservative RISC OS market. I'll let you decide.
look like they're all moving in the same direction.
What I'll instead argue is that certain parts of RISC OS ought to be open source. Crucial parts that affect all users, even if they don't realise it, parts that can be created from scratch and made much better than the Acorn original, and parts which can managed by specific developers who already understand them well.
Freedom and Software
I'm not going to evangelise about free software or about the meanings of free - if you want that, then I suggest a visit to the Free Software Foundation webpages and perusal of their essays. What I will say however, is that certain aspects of software development may be too important to leave to specific companies with traditional closed-source methods, especially in a small market. I've argued this before with RISC OS web browser development, where RISC OS has seen a string of commerical browser development which has then stalled or stopped when the company changes focus or vanishes - and we're sadly still waiting for Oregano 3. Contrast with the open source browsers on RISC OS - NetSurf and Firefox - which although both have some way to go before becoming fully polished products, remain accessible for anyone to have a go at improving, even if the original developers move on.RISC OS and its components
As you probably know, RISC OS is built from numerous components, or modules which together form the core of what we know as RISC OS. Other modules may be loaded providing additional functionality such as drivers (networking for example) or other general functionality (toolbox modules are an example here). In some versions of RISC OS, these modules may replace versions in ROM with newer soft-loaded versions.Additional parts which form other parts of RISC OS include various applications and utilities in the boot sequence such as the confiugration application as well as other various bundled items. These are of lesser concern in this article, but still relevant.
Open Sourcing
So what I am driving at? A real example will help. Recent discussion on usenet revealed that the SharedCLibrary bundled with the A9 version of RISC OS as supplied by RISCOS Ltd. lacked various features included in the 32-bit version supplied by Castle and was required to run a variety of modern applications. There were suggestions that for political or other reasons Castle might be reluctant to make such a version available.In practice, this particular issue seems to now be all but resolved, however what if it had proved to be commerically impractical? This might have called for development of a "SharedFreeLibrary", which provided the crucial functionality of Castle's SharedCLibrary in an agnostic way to all versions of RISC OS. Such a version could have code contributed by several parties for the benefit of all. Indeed, most of the code already exists in UnixLib for such a project to be put together in a relatively short period of time.
Following in Footsteps
It might not surprise you that there are precedents for this suggestion. Examples include free versions of DDEUtils (DDEUtilsCy), Acorn stubs (GCC stubs), Window Manager (Wimp2), the Freenet internet stack, as well as a handful of items that were made available before some of the utilities in RISC OS were converted to 32-bit. Also don't forget things like Justin Fletcher's multi-tasking error boxes and a long list of desktop hacks that overrode or augmented existing behaviour. On the other side of the coin, we also have the Printers+ project, which had contributions by the late David Marston.What I'm not proposing is an all-out replacement of RISC OS functionality with random bits of code, like the ill-fated and poorly considered frx project. Rather, a more structured approach, making good use of limited developer resources and choosing carefully components that might add value to users and RISC OS companies by having an open source implementation. With such components, both third party developers and RISC OS companies - Castle, ROL, A6 and perhaps others could contribute code and then be able to freely use the result (subject of course to licensing). Users would enjoy a homogenous version across versions of RISC OS (although perhaps requiring a base version of RISC OS like RISC OS 4) and developers would benefit from being able to rely on features which were certrain to be present.
I appreciate that this is something of a utopian view, and in the real world is constrained by time, effort and commerical concerns. Nevertheless, I'd like to propose some projects that might benefit from this approach.
Select Features
The current raging RISC OS debate is the availability of Select/Adjust features on RISC OS machines, particularly on the Iyonix, especially since the latter is what it appears that a considerable proportion of active RISC OS developers now have (on which Select presently only has a small subset of features and which aren't publically available) versus RiscPCs which many have stopped using (on which Select is a full version of RISC OS in its own right).To at least start to address this, as well as RISCOS Ltd's apparent reluctance to persue Iyonix developement, there's no reason why at least some Select features couldn't be provided in part by open source implementations. To start with, some of the new APIs, especially those dealing with graphic effects, would only need to dummy functionality. I appreciate too, that Select on the Iyonix does require some kernel-level changes, but given code that is "ready-to-go" and the correct information, there's no reason Castle couldn't be convinced to make these changes.
Allow me to stress that there's some degree of speculation in what I've named above. I'm not familiar with most of the specifics of the Select changes, and am not in a position to name features which might be suitable for such treatment. But there's another side to this theoretical situation:
Instead of ROL's existing subscription scheme, they could instead contribute and open source code (it would of course have to be code that they had full ownership over) to this project. This could be done on a bidding/pledge arrangement where certain elements were made available piecemeal when the required level of financing was met.
And is this situation realistic? Perhaps it is a bit too egalitarian for the sometimes conservative RISC OS market. I'll let you decide.
Not Done Yet
What else could benefit from this treatment? How about fixing the CDFS/ADFS/SCSI mess I named in a previous article? I suspect this could become complex with the addition of USB in RISC OS 5, but it could be done. This would also mean people could freely add support for various optical drives (and adding DMA support), instead of reinventing the wheel. FileSwitch too, perhaps - addressing the 2GB limits. This is all very easy to get excited over, but remember that often there are sobering interactions between various parts of RISC OS that may not be at all obvious from external examination.Summing Up
I don't have to point out that Open Source is a powerful tool - there's plenty of evidence for that already. I don't think either that it's silver bullet for the multitude of RISC OS woes - many of which still come down to lack of applications and application features - but there might be common ground using it for developers and RISC OS companies to at least start tolook like they're all moving in the same direction.
