RISC OS is open for business!

O yes that is good idea to move the GPL discussion to another thread…

By the way, if anyone spots anything in the media picking up on this announcement, please post here so we can all enjoy!

Popular polish tech news website wrote about it today: https://www.dobreprogramy.pl/open-source-arm-risc-os,News,91666.html

“Experience tells me that the real “barrier to entry” is the complexity of the RISC OS codebase and nothing else.”
=> I think that is the real problem. With a lot written in assembler and that is harder to see what the structure is. Also looking where is what.
“then the lack of a competent debugger” => Yes or a proper Visual studio / eclipse like IDE
“If someone really feels that spending 50 UKP is beyond their reach, just ask me – I have sponsored DDE licenses before for poor developers.”=> Bugger I paid it can I have 50 UKP from you ;-). No just joking I paid it with a smile.
Since the start of open-sourcing RISC OS there has been talk about the whole toolchain issue time and again. But still, nobody has seriously tackled the problem until now, which suggests to me that it is likely that nobody with the necessary determination for OS development really exists (who is not able/does not want to spend a few bucks on DDE). => I also think it takes a lot of time. Microsoft can spend a shitload of money and hence time on Visual Studio and Eclipse also has a lot of developers I think. As said earlier on this forum there are not that much programmers on this forum.

Guys, could you take the discussions about GPL to somewhere where that’s relevant?

There’s a pub I know of that has the odd knifing/shooting and not on my visiting list. That sound suitable?

In terms of DDE if someone were to magically come up with the required developer time to magically transform GCCSDK then surely said developer time would be better spent transforming the kit that ARM provide?
You were all thinking there was a pot of money to finance the work weren’t you?

There are many things that are ‘Barriers to entry’, the license was one of them and has now been fixed, excellent.

Imagine a potential volunteer contributor coming to the project.

1) Uses the project, likes it, thinks “maybe I could add/fix X”
Currently very possible on free and very cheap RISC OS system.

2) Grabs the source
Easy, free, and now under a license that’s a lot less one-sided.

3) Builds the source
Ah, 50 quid for the DDE, “Why am I paying you to add/fix this for you?” (DanielJ, Jon Abbot, Simon Inns and well my point) currently the only part of new RISC OS development that has an absolute requirement on the DDE is building RISC OS itself.

4) Attempt their change
Could be hard (Steffan’s point), depends on the person and the change.

5) Send Fix/Add upstream to the project
Could well get accepted into the codebase, and there is much rejoicing.

https://www.riscosopen.org/forum/forums/8/topics/4004

The ball is in your court ROOL, if there’s a reason this can’t happen, could you explain why?

I summarised something in that thread that bears repeating. “as it stands at the moment RISC OS is in competition for volunteer developer time with millions of other open projects that don’t have a 50 quid ‘join the club’ fee”.

I summarised something in that thread that bears repeating. “as it stands at the moment RISC OS is in competition for volunteer developer time with millions of other open projects that don’t have a 50 quid ‘join the club’ fee”.

We hear you. This is the sort of on-topic debate and conversation that’s welcome!

I see another barrier which makes it hard to get started with developing RISC OS. I would like to see a guide on how to actually get started. Which describes what you need to do to build the sources on you own machine, how the sources are structured and how to commit changes etc. (Is there such a guide and is it up to date?)

I think what could also encourage new developers and what would be even better is a “How to get started” weekend where experienced RISC OS developers could meet people interested in starting development for RISC OS. Or this could be combined with a RISC OS Show when there are a lot of RISC OS interested people around anyway. So the show could be on saturday and a RISC OS developing workshop on sunday?

I think Michael’s idea sounds really good. If a workshop could be arranged then that would be great. Perhaps that could become a regular feature of the shows to build engagement with developers?

Failing that even a video how-to-get-started guide would be useful. But much more passive than an active workshop.

As of about twenty minutes ago, it’s on El Reg.

Best comment ever:

I remember buying a Viewfinder from you, Chris [Evans].

It’s amazing he found the time, between being on Radio 2, and being an Avenger.

There’s a whole pile of developer documentation in the wiki. I like the idea of a training workshop but doing that well takes a lot of preparation == effort. It also has non-zero running costs. Would people be prepared to pay for such an event?

One of the ideas ROD brought up at a recent meeting with ROOL was the idea of a (subsidised?) developer meet/conference session. Such a workshop would make an excellent part of that, I suspect.

It didn’t meet with a lot of round-table enthusiasm though, as I think there was a feeling that many developers simply wouldn’t want to be bothered gathering in a single location, as these days everything is very much online/IRC etc. Do people still IRC? I suppose its all face-stuff and insta-watsit now.

Personally, I can’t help feeling that there might be milage in bringing together interested people with the idea that then can join up into teams working on different things. For example, not everyone has to do tackle the “rock hard” bits – expanding and improving the desktop apps might be more accessible stuff for people, especially working together.

If we ever manage enough coders, I see a “dream situation” of having an Apps team, a UI team, a porting team and a core-os team. What we really need is a Jeffrey cloning factory! Ben, does !CloneDisk work on people yet?

Also, regarding toolchains and cost, if anyone is interested in the idea of contributing money to a pot to fund aspiring developers, perhaps get in touch with me at the andrew@riscosdev email address. I’m having ideas. They may not go anywhere, but it might be something ROD could help with.

“Would people be prepared to pay for such an event?” – I would.

Would people be prepared to sponsor the creation of a video guide to “getting started developing on RISC OS”?

We had this discussion on stardot with regard to a cash pot to help develop hardware. What came out is that people generally (this is anecdote, not scientific) don’t want to take money from elsewhere – it makes you feel obligated and that’s when the procrastination and bad feeling monsters take up occupancy.

Yes I’d sponsor a video guide for general development on RISC OS and also video demonstrating how to build the OS.

Steve has covered the Wiki docs. I can confirm that the guide to building RISC OS works beautifully. I used it myself (and I have barely used the DDE) to build my own LanManFS a while ago.

As a slightly more general point, we need people to try these things, and use their experience to refine the documents. I would open this even further… What do we have about using RISC OS, and things like where to get software? We could do with a supply of fresh new users who we can observe.

5) Send Fix/Add upstream to the project
Could well get accepted into the codebase, and there is much rejoicing.

I find this to be a fairly interesting one. At the moment ROOL are the official gate keepers to the OS source, and although it’s good to have quality control, a lot of it seems to take place behind the scenes, so it’s hard for other people to know what’s going on. The “send your changes in as an email attachment” procedure is also starting to feel a bit dated, and I imagine that it acts as a time drain for both the developer and ROOL.

So although I think CVS is fine from the perspective of “it gets the job done”, I think that git (or something like it) would help make the workflow for non-trusted developers better (I’m in the position where I can submit directly to ROOL’s CVS, most people aren’t). I.e. the workflow improvements of:

1. The ability for developers to click a button / type a command to open a pull request (instead of faffing around zipping changes or producing patch files and then forgetting to actually attach them to the email)
2. The ability for ROOL to review that pull request and (if accepted) merge it into the code base with another click of a button (instead of faffing around making a clean copy of the component(s) and merging in the changes)
3. Continuous integration hooks for the glorious future where RISC OS actually has a test suite (or at the very least, it could check that the modified components still build in all the relevant configurations) (saves developer time + ROOL time by letting computers do some of the mundane testing)
4. Transparency and openness during the review procedure because the pull requests and feedback are hosted on a publicly accessible website (helps avoid the problem where multiple developers might implement and submit their own versions of the same change, because with the old system it was impossible to see into ROOL’s submission queue. And it gives potential future developers a look into what’s expected of them if they decide to try submitting a change)

We’ve also got the related problem that bug fixes, changes, etc. frequently pop up on the forums – which means that even if a non-ROOL person with CVS write access (like myself) spots it and OK’s the change, they still have to mess around patching it into a copy of the sources from CVS and committing the result. If those bug fixes appeared in an issue tracker that was integrated with the source control then it would be much better for all concerned.

Essentially we just need “pull requests for CVS”, but I’m not sure if such a thing exists.

Related to the subject of open sourcing, is there a definitive list of closed-source binary ‘blobs’/components that cannot be built from source and are thus a potential maintenance problem down the line?

Sounds like a thin-client to help with source submission and continuous integration would be useful. Thoughts:

• Add a shim to provide a thin client (could even be a web front end and a script that makes patch files) that is RISC OS compatible (where there is no native alternative)
• Automate current manual submission mechanisms to save time for ROOL.
• Replacement of the source conrol mechanism could be achieved by using a shim & mirroring source.

@adrian – I think (off the top of my head) the list is MBufManager, ShareFS and MIMEMap (correction: Resolver).

There’s a MimeMap in CVS but it seems from the comments that it may be a rewrite of an earlier closed-source one. I haven’t checked which one is actually included with the OS image.

There’s a MimeMap in CVS but it seems from the comments that it may be a rewrite of an earlier closed-source one.

Correct (and yes, it is being used in place of the closed one).

MBufManager, ShareFS and Resolver are the closed-source ROM components that I can think of. Possibly there’s something in the disc image too.

MBufManager, ShareFS and Resolver are the closed-source ROM components that I can think of.

Three items which I know have featured in problems many people have had both relatively recently and, in the case of Resolver, a decade or so. When problems with a module are as prominent as those with Resolver (hey, if someone like me tinkering with small items finds the problem¹) you know it needs a re-write.

¹ Frank d. B. wrote an alternative method of doing certain aspects in order to get DNS Blacklist working for AntiSpam after I’d been experimenting with a small port of a tool and made lots of noise on the subject. It is not a replacement for Resolver, just certain aspects.

you know it needs a re-write.

Maybe on Saturday these remaining black boxes will be opened up too? Here’s hoping… ;-)