Questions about organising a NoScript fork

[Mæstro]

I have been trying to move the discussion in the current NoScript thread in a more cordial direction, which has motivated me to enquire on topics raised in my reply to Athenian:

• What would an appropriate model for hiring a programmer be? Intuition suggests to me that it would be on an ad hoc basis, raising a new bounty to mend an incompatibility whenever a new one happens to arise, perhaps after an initial push to replace NoScript’s invasive method of blocking scripts by one that resembles µBlock’s without affecting other features.
• What would a fair bounty for patching NoScript be?
• How would the NoScript community organise the pool whereby this bounty should be paid? The most relevant sites I know for this purpose, crowdfunding sites, can collect money over a limited window (possibly a few months), whereas I am imagining a fund that would accrue however long we need until the target is reached and a programmer found.
• How would we find a programmer who can patch NoScript for us once the funds are adequate?
• How would we find an artist who can create branding that would look like it belongs in the mid-00s like Jesse the JavaScript worm does?

[moonbat]

How would we find a programmer who can patch NoScript for us once the funds are adequate?

It would have to be someone already active on this forum (I heavily doubt there is anyone left outside the PM community with good experience on XUL/XPCOM and pre e10s Firefox unless you can magically get hold of one of the original developers who have long since moved on by now), who has a great understanding of browser internals as well as extension development, and is interested in upgrading NoScript vs sticking along with eMatrix, so it narrows the pool down considerably

[vannilla]

One issue with NoScript (which extends to a lot of old toolkit extensions, actually) is that the code is written like ass. Some I wrote also have questionable quality, but at least they are small and still manageable. NoScript is both big and unwieldy; even if you get a team it'll take a long while before you get to actually work on making the required fundamental changes.

Regarding what moonbat said, if you actually hire a programmer instead of relying on volunteer work, it doesn't really matter if they have experience before working, their pay depends on it so they are bound to learn.

[moonbat]

the code is written like ass.

Sadly true of several other extensions as well - one of the worst things they do is not keep view (XUL) and control code separate. Adding 'onevent' handlers directly in the XUL file instead of assigning them within the Javascript even when that is one of the better practices for maintainable code. Or one big monolithic code block without splitting into separate logical functions. Of course, not that Mozilla ever made any comprehensive documentation (most of what's there is external volunteer contributed) let alone enforced coding standards.

[Mæstro]

From the conflicting information above, I should ask. Which model would be more appropriate? This would inform further proceedings.
In a volunteer model, I could pay a €250 bounty out of pocket and would fain post the precise conditions, for which I have already got a draft in mind, here after asking permission. I am using the official bounties as reference. Other NoScript users, if they wish, could offer to augment this bounty with their own contributions, but I am not sure how to form a pool of funds fed by several people.
In an employment model, I would attempt to find a random programmer, though I would not know how to do this beyond checking the local Yellow Pages on the table for Programmierer and calling whichever numbers appear. Presumably, after making contact with one, he would estimate how much it should cost, but the same question as above arises if the cost happens to exceed my individual resources.

[Shadow]

Since I either got overlooked or ignored, like an actual shadow, I'll link here what I put as a temporary workaround as well.

First discovery then in the other thread.

[moonbat]

Since I either got overlooked or ignored, like an actual shadow, I'll link here what I put as a temporary workaround as well.

First discovery then in the other thread.

I'd say this thread is more about a long-term solution to fix NoScript so it works without causing problems; not just the current crash. As time passes there will only be more such problems cropping up.

[Moonchild]

Since I either got overlooked or ignored

I don't think either was the case, but having to disable core functionality in the browser isn't really a solution to anything; it's a trade-off at best.

[geraldh]

I've been using NoScript since its early days on Firefox before I switched to Palemoon. Over time NoScript, like a lot of applications, became more complex and added features that I never used or fully understood and this may have been the case with other users? If a Palemoon NoScript fork were to be developed, could some of these more peripheral features be removed to simplify the codebase, reduce the potential for conflict with the browser and make a fork more achievable? Although I did write a piece of obscure public domain software for the Amiga decades ago, I readily admit I'm out of my depth on this

[Mæstro]

As far as I know, NoScript’s auxiliary features, such as the ABE, were present before 2009, when Pale Moon began its development. There has been one instance of such a feature spinning off into its own extension: NoScript’s HTTPS enforcement ultimately became HTTPS Always. One could decompose NoScript into further modules like this. As long as all of them (including an independent JavaScript blocker!) have agreeable UI, I would not mind this approach.