Open development bounties

I just came across the ‘USB stack’ thread from September, so this contribution is a little late, but I thought I’d start a thread anyway.

Something that’s always sat a bit awkwardly with me is that the bounty setup is not really designed with open source in mind, and in fact might discourage it. It seems there are a few different ways it operates:

1. Developer comes along with finished product, says ‘tada’, collects bounty
2. Developer approaches it a bit like a contracting gig: produces a workplan, milestones, etc. Ships a deliverable, collects milestone payment, proceeds to the next phase of the plan.

But I’m concerned that this is not a good use of resource in an open source project where few people are spread thinly. I wonder how many bounties fail – either the product was never finished or the milestone was not reached, and so their work languishes in private. There is also a risk of duplication, if either a project is abandoned or two people are working separately. Meanwhile, until the first deliverable is shipped there is no external progress.

I wonder if a revised bounty strategy might involve work being done in public (gitlab branches are perfect for this), with the payments based on the contribution of developer(s). For example, if developer A gets half the way there, maybe they should receive half the bounty. Perhaps developer B can then pick up from where A left off. Or perhaps dev X could accept pull requests from others, but would still get the bounty for doing 95% of the work. Devs would be encouraged to collaborate, eg receive bug reports, produce test builds, etc.

Basically change the incentive from shipping a finished product, with a very substantial chance the item doesn’t get finished and never sees the light of day, to shipping code in public and being paid for what they do achieve, rather than all-or-nothing results.

Thoughts?

I wonder similar things sometimes!

You hear occasional gossip that x or y is in progress, which is enough to prevent me from looking myself (don’t want to waste effort). So more visibility would be great. As you say, gitlab is built for this! A problem shared can also be much more solvable.

Suppose someone does just drop something, for example, a new Pinboard, a port to different hardware, improved USB, improved networking… How on earth would that be introduced into the source tree in any sort of nice and reviewable way?

Even smaller scale: I ponder LanManFS, but you just don’t know who is doing what. Could be a waste.

Having said that, I totally understand why people wish to remain free of public expose and implied commitments. I think that is easy – just don’t talk about dates. Anyone complaining is welcome to contribute their own labour or other resources.

Part of open source can be open development. Much still seems closed (but this is RISC OS, where it isn’t unusual to be 0.25 centuries away from the trend..).

A couple of related observations:

1. It’s common knowledge RISCOS Developments are working on the network stack yet the ROOL bounty remains “Open”. This notionally risks the sort of duplication referred to by Theo. I’m not sure you could necessarily expect devs to expose their work-in-progress in gitlab but why not in this case mark the bounty as “Underway” and provide updates the normal way (see Current Status)? If the intention is for the RISCOS Developments work not to claim the bounty (as has been intimated) then it can still be marked as “Underway” for clarity and the money redistributed when the work is done.

2. It’s also common knowledge that the Filing system improvements (step 2) bounty has stalled with no short-term prospect of it re-starting yet that bounty is still marked as “Underway”. What do ROOL plan to do about that? With approximately 10% completed, maybe there is a case there for the work done so far to be checked into a branch, re-open the bounty and encourage other devs to pick it up? There’s no compunction for other devs to build on that but it would at least demonstrate what work was done in an open source way.

One thing it seems to me, and I’m not sure if others get this impression, is that the bounty system can act as a disincentive to get involved. If a bounty is marked as under way, it sends a message a bit like ‘mine now, hands off’. It is possible this acts as a deterrent to others to work on that code, to avoid treading on the toes of the person who claimed it, and to avoid a potential conflict (eg if the bounty ends up discarding the existing code).

I know there are reasons why not to be entirely public (eg for proofs of concept and such) but it could be a condition of claiming a bounty. It’s also possible to have private repos on gitlab, so progress is always visible to admins even not to the public, and the admins have rights to make that public if things stall.

One thing that would be useful is to know what has been worked on and what hasn’t. For example ‘a new HForm’ is an element of the FS Improvements 2 bounty, but if there is no prospect of starting yet perhaps somebody else could have a go.

I realise the bounty system is intended to attract people to work on bigger tasks, but may also make the tasks appear more monolithic and less attractive to those who aren’t in a position to take on a large task.

‘a new HForm’ is an element of the FS Improvements 2 bounty, but if there is no prospect of starting yet perhaps somebody else could have a go.

Done and done

I’d also point out that OS level Partition support is already in the OS source via PartMan but hasn’t been included in main builds, so that bounty needs reviewing and the money potentially diverting elsewhere.

Back to the general question of bounties:

When a developer comes forward to take on a bounty, is a formal contract agreed? The fact money is exchanging hands implies either a contract is agreed, or is implied. This could potentially be an issue if several developers are working on one bounty and expect to get paid – how is the money going to be distributed fairly and what happens if someone outside of the original bounty hunter completes the work?

There’s a lack of public updates on bounties. Filing system improvements for example has been in development for years with no update and whilst developing Partition Manager I had to make assumption as the developer never came forward to answer questions.

Unless it happens in private between ROOL and the bounty hunters, there doesn’t appear to be much in the way of peer review of what’s being implemented until the final commit. Where is the RFC process? Why is the Code Review forum not filled with discussion around bounties in development? I suspect its due to my next point…

There are no names against bounties. I appreciate that developers might feel under pressure, but that is unfortunately something you have to accept when you’re going to claim a piece of work and expect to get paid for it. The initial contract should cover this, with the option for ROOL to remove anyone that breaks the law, or goes off-spec without agreement. ROOL should also be able to reallocate the work if its not proceeding in a timely fashion.

I still need to be convinced that developers should get paid for freelance open source development, its fraught with legal ramifications, discourages joint effort and puts undue pressure on bounty hunters. Would the bounty money not be better diverted towards making DDE updates freely available via PackMan and bundle DDE in the base images?

Done and done

Yep, I had you in mind when I wrote that – but wasn’t exactly sure of the status and didn’t want to tread on any toes.

I think the way bounties are structured feels much like traditional contracting: XYZ Corporation issues a tender, Jimbob Consulting Ltd replies with a bid, terms are agreed, etc. There’s no need for public scrutiny of this because the only customer is XYZ Corp. If Jimbob doesn’t deliver then they don’t get paid.

A different model might be Google Summer of Code. Here Google offers to pay students something like $5000 for a summer working on an open source project. Projects apply to the programme, and if they get accepted the project publishes a list of project ideas. Students apply, proposing the project they want to do, and are encouraged to get involved in the community pre-application. Projects allocate mentors to oversee the student’s work. Students publish their contributions as they go, having regular meetings with their mentors who provide guidance, but also interacting with the open source communities that work on the projects. At the end the project is completed and public.

I suppose the difference is one of expectations. GSoC is based on the idea of paying students to do engineering, but some GSoC projects fail – maybe the student struggled, maybe the idea didn’t pan out. That is fine, they did the engineering but the project didn’t work out useful – nobody can blame them for that and they still get paid.

Whereas it seems like RISC OS users typically have high expectations of anyone who sticks their head above the parapet, and things can get heated if they don’t deliver. This seems often down to scope: users don’t know how much work something is and, while they’re willing to pay for things, it’s never enough to do it as anything other than a hobby.

Which can mean that nobody wants to stick their head over the parapet because suddenly the weight of expectations descends and it’s not a fun hobby any more.

Up to this point I have just been lurking reading these comments, but it seems some people here either don’t take any notice of talks and comments made by the two pricipal organisations involved in this RISCOS Developments and RISCOS Open.

Both have actively encourged developers who are interested in ‘voluteering’ to work on a project / bounty to contact them, both organisations are in regular contact and work together on trying to get various projects done. So basically if you feel you can help or want to take on a project or even part of a project jointly with another volunteer developer contact them and they can co-ordinating the contactng the volunteer developer and helping get the work done.

Do also remember that both the ROOL and ROD people are also doing this in their very little spare time for free!

As far as I am aware their are no contracts involved people are ‘volunteering’ to do a bounty or other project – if this was being done commercially the amounts asked for in the bounty would almost certainly increase several fold in cost.

So Theo if you are interested in doing any work on a bounty all you need to do is drop either ROD or ROOL an email and then it can be discussed between the appropriate parties.

Fair points, Chris, but I still maintain that if the status of the bounties better reflected work that, in the case of the network stack, is being done by a close partner of ROOL and, in the case of the Filing system improvements, sounds like it’s already been done, then there would be a greater level of trust in the system from developers and donors alike.

I support the bounty system and look forward to the projects that are underway being completed and new projects being developed.

Both have actively encourged developers who are interested in ‘voluteering’ to work on a project / bounty to contact them, both organisations are in regular contact and work together on trying to get various projects done.

That doesn’t actually address any of the concerns raised in this thread, however.

I think the ‘drop us an email’ attitude is just garbage. Sounds like pointless gate keeping.

And what if someone volunteered help on, say, LanManFS? Is there an issue tracker? Technical discussion? PRs to rebase/review/merge? I bet it is more like being emailed a zip of source code. In fairness, I do not know that, and am only speculating.

Sending an email would lay some sort of intent and set up an expectation. I totally agree with the earlier comments that history shows that only a few brave souls dare raise their hand (and I bet some regret it!). On the other hand, I think Jon is right… Tougher skin is the solution to that.

And what if someone volunteered help on, say, LanManFS? Is there an issue tracker? Technical discussion? PRs to rebase/review/merge? I bet it is more like being emailed a zip of source code. In fairness, I do not know that, and am only speculating.

Are you sure that you mean LanManFS? I’m fairly sure that’s in ROOL’s Gitlab and I’d guess that the ROOL Issue Tracker would cover it.

Now, if you mean LanMan98, then you might well be correct.

Now, if you mean LanMan98,

Where the download contains the source, and the source includes what I suspect is an older¹ (and hence buggy)² version of StubsG

¹ 2003 seems about right for the original version

It also has comments to the effect of “this might also reference other header files, so you might need to comment stuff out to get it to build”.

Not sure if I was thinking more of LanManFS or 98, to be honest! I think my concern on either would be wondering if effort is being duplicated. I am sure I have heard whispers somewhere about those being looked at, but there is nothing public. Is it safe to stick your the in the water?

I wonder if a sensible first step would be to compare FS and 98, and see which is better from a features and maintainability perspective. If 98 looks good, it probably needs some tweaking to get it to fit into the ROOL sources. Then the tough bit… Modern security…

But hey, it is easy to speculate and suggest. For someone to actually have a bash and deliver something is another matter indeed. Hats off to those who have submitted MRs!

Maybe I was a little harsh with ‘garbage’, but it definitely smells of gate keeping etc.

but it definitely smells of gate keeping etc.

Seems to me that the primary concerns come down to two things.

Firstly, all this Git stuff is kind of new to the RISC OS world. I mean, I’ve never successfully checked out anything (CVS or Git). Probably “holding it wrong”, but still, zip files are just easier for me. I doubt I’m the only antiquated fuddy-duddy around here, though it can make shared development “interesting”. Not speaking from experience, I’ve had next to zero feedback on any of the sources I’ve released ¹. Wonder why I bothered…

Secondly, all of this potential extra development is happening in addition to everything else, and much of this is being done on a voluntary basis. We don’t have people whose sole job is to audit patches and merge them into sources, so even fixing fairly simple (in code size/changes) things like “doing this with a menu causes the Wimp to explode like a Pinto” takes time to trickle through to the nightlies.

if effort is being duplicated.

Yeah, it’s a bit of a double-edged sword. It would be good to have public notifications and updates, so we know what the status of things is and some of us could offer to help out.

But on the other hand, not only does going public bring with it some sort of expectations (it’s easier to walk away from a project you’re (note: third party use of “you”, not you you) stuck on or fed up with if you aren’t going to get crucified in a forum), but also you run the risk of spending half your development time answering forum questions, dealing with an ever growing list of suggestions and wishlist items… right up until you get to the “oh FFS, enough” part.

There’s no correct answer. It would be nice for everything to be discussed in the open, but I certainly understand why a lot isn’t.

¹ Dave fixed up USBMIDI which I’m thankful for, and, uh…….

I manage to hold two views on source control.

Professionally, it is essential. I need change history with visual indicators (diffs). The other developers need to contribute, and we need to review each other’s work. We also need to control when and where changes are released. So source control is brilliant. It is like using Zap or StrongEd compared to entering code at the BASIC prompt. And it still makes sense, even if there is only one developer.

Despite that,when I have my RISC OS hat on, I work from a directory which I periodically back up to a NAS. And I drop a zip on a forum thread. Terrible. I know I need to do it properly, but I don’t know where to start on RISC OS. I have been putting it off!

We both need to try it!

I have been putting it off!

Like a few others I am waiting for the “git source control client” bounty to be delivered

@ Rick

Dave fixed up USBMIDI which I’m thankful for, and, uh…….

If you would not be so “against” git I’d offer to host the source for USBMIDI on github, I am do the work for you if that’s ok and make it available to everyone who use github. In the end I am very much interested on the MIDI stuff on RISC OS, so not a problem at all for me to have to help maintaining it even if you both want to send fixes and patches via email. :)

@ Theo

Basically change the incentive from shipping a finished product, with a very substantial chance the item doesn’t get finished and never sees the light of day, to shipping code in public and being paid for what they do achieve, rather than all-or-nothing results.

Thoughts?

I don’t disagree with partial code releases, but it’s probably something that each specific developer has to decide. So more like on a per-case basis?

Also, I think there are two different worlds here:

1) The “professional” Open Source world, where we all work on multiple projects that we are interested in and provide help when we find some issue, or take part in discussions, code reviews and what not. That world, on the top side of it, is now fueled by standards in terms of workflow, testing, discussions, looking at the stats of contributions, is mostly a Corporate effort at this point. So I imagine you’re not referring to that form of Open Source, right?

2) The “hobbyists” Open Source world, where someone starts a project, does most of the work (at least initially), then slowly others join to help because they may have started to use that code in some form or shape and they have some extra need or they have found some issue and can provide a fix for it.

Now, the 2nd case seems to me very much applicable to the ROOL bounty schemes. So, I do not see necessarily a problem there. In the end the final work of a bounty gets added to the ROOL GitLab and from that point on others can start joining in and help improving things that may not be working as expected etc.

On the communication side I think you are correct, it seems to be a problem, but ROOL and ROD people have mentioned multiple times that they have very little time available for the communication side, so, it sounds to me like a “take it or leave it situation”.

I think the bounties have a clear audience in mind, they are for the ones that want to work on bigger tasks and may wish to have some money for their effort.

So, I don’t think bounties are necessarily a problem or deterrent, if someone want to do something for RISC OS (even outside the bounty scheme), they should just start sketching some code in their favorite programming language and see how it goes and if it gets to a point it may be releasable, then they could either contact ROOL or ROD.

If those two are too busy bringing bread on the table, then they can use github to publish their work (just add risc_os to the keywords) or they can contact RISCOS.info or my project RISC OS Community, we (we are now like 9 or 10 people) are happy to publish on github, review, help to add testing people’s work if no one else answers you :)

We can also help choosing the right license for your code, more info here:

https://github.com/RISC-OS-Community/RISC-OS-Community

(click the link, scroll down and read the README)

For the people that still are not familiar with git:

I have linked a full and totally free github video course on the contribution guidelines on the RISC OS Community.

Have a look here for more info, links and whatnot:

https://github.com/RISC-OS-Community/RISC-OS-Community/blob/main/CONTRIBUTING.md

I am sure we can add specific videos for RISC OS on our Channel on YouTube:

https://www.youtube.com/channel/UCaxRPTbwoB6IHo7vFLMm4Rw

And, if git it’s still not your thing or you still hate it after the easy course (made with very short videos easy to watch on every tablet), then we offer publication and maintenance “services”, please feel free to rich me out directly at this link (sorry no email address publication on forums): https://paolozaino.wordpress.com/contact/

If anyone wants to help, feel free to join. If you want to review all our material, code of conduct, provide feedback, help in any form or shape, please let me know, everyone is welcome.

For who cannot wait to start coding on something Open Source style

Here are some projects for who wants to join something that is being developed Open Source style:

https://github.com/RISC-OS-Community/uCLib

The Micro C Lib is a minimal C Library that can be used to build RISC OS Utils (transient) executables in C, it’s being developed open source, have a look at the Develop branch, since no one has joined, I haven’t published any specific requirements, but if it’s needed I can add the requirements.

It comes with automatic tests, so when you pull the code and run make it will also run the tests on your RISC OS system, in front of your eyes, so you can keep working from there, read the CONTRIBUTING.md Guide Lines to contribute and add your code. Right now Stuart Swales took leadership on that project and I have uploaded all my latest changes and may add more later this year.

We also have Testing libraries already released and many of you have already cloned them, so I don’t think I need to publish the links.

When uCLib will reach releasable state there is another one ready to start the ROCUtils (RISC OS Community Utilities) which is a bunch of utilities all rewritten in C that are waiting for the uCLib to be ready. If of interest I can upload the sources, but they should be built using uCLib.

I have another project for the BBC BASIC lovers: BeebLibs a curated collection of Libraries in BBC BASIC to be released as a single !Lib Via PackMan.

Anyone interested in helping on this one?

There is more…

I have another project for the BBC BASIC lovers: BeebLibs a curated collection of Libraries in BBC BASIC to be released as a single !Lib Via PackMan. Anyone interested in helping on this one?

Hmm. Had Acorn undertaken this it would have been a really worthwhile project, but I am afraid that ship sailed at least 30 years ago. ;-(

There have been numerous BASIC library systems published over the years and uncountable private ones, most of them mine by the look of my hard disc. ;-)

At one time I collect the published ones, and looking in my archives I found 28, with a good few more bits and pieces. The most comprehensive was Blib/Blib2, if you discount ArchWay (remember that?).

There is a handful of survivors and more recent offerings, but the number of people using them must be quite small now. I think it likely that many of us into BASIC are probably using our own libraries, tweeked over the years.

Your project might be aimed a newcomers, perhaps. If the documentation can approach that of AppBasic then it has my support, if it is of any value.

Dear Steve,

At one time I collect the published ones, and looking in my archives I found 28, with a good few more bits and pieces. The most comprehensive was Blib/Blib2, if you discount ArchWay (remember that?).

I do and I think they were all great ideas :)

There is a handful of survivors and more recent offerings, but the number of people using them must be quite small now. I think it likely that many of us into BASIC are probably using our own libraries, tweeked over the years.

I do not code on RISC OS for the “fame” lol. So, even if the users of this project is going to be just you and me, that’s awesome. I am coding on RISC OS just for fun and nostalgia. Now that the ROOL guys have worked the magic of making it Open Source, to me it’s the best of times to have fun with RISC OS.

Your project might be aimed a newcomers, perhaps.

All my RISC OS projects are first and foremost aimed at building the RISC OS I always wanted (now it’s Open Source, so I can make this happen) and then to whoever share the same desire and wants to have fun with it. So, old comers, new comers, whatever in the middle.

If the documentation can approach that of AppBasic then it has my support, if it is of any value.

Sure, AppBasic is another cool tool and eventually why not packaging also Basil, so other projects can use it as a dependency?

What about creating a new BASIC that has the Microsoft syntax, so also other retro users can code on RISC OS in a way they already know? (some news on this maybe during this year).

Oh and speaking of programming languages, last week I have finished the first step on porting a Prolog compiler to RISC OS 5, it works now, and it’s built using DDE, so very light wight and so is its VM, I shared a picture on twitter and people went bonkers for it :D

Hopefully I’ll be able to finish it soon, then there will be the work for the RISCOSLib for it… (lots of coffee and donuts needed lol), but I have a lot of other things going on too, so we’ll see.

Again, IMHO, whoever wants to code something for and/or on RISC OS, just start doing it. Start from sketching something you’d like to work on and do not worry too much about bounties and/or other stuff, just enjoy the journey for what it is, it’s a puzzle to solve, if you get stuck, post a question on here or on a mailing list, see what people say, there will always be someone who wants to help, keep going until it’s “releasable” or work enough and then share it and the source in whatever way you like, just remember to make it easy to find (please do not hide it!) :)

Share the sources guys, we are all getting old here, none of us will be around for ever, oh and if you think people are not coding on RISC OS anymore or stuff like that, let me share something beautiful with you:

https://github.com/topics/riscos

and

https://github.com/topics/risc-os

More than 186 repositories and they are growing by the day, people ARE coding on RISC OS and many ARE sharing Open Source code, I am so happy to see that, thanks to everyone who’s sharing their work and enjoying coding on RISC OS in 2022 :)