> Honestly, this shows why projects of major complexity need professional full-time developers.

I think the opposite, it shows why projects that care about the practical side of open source and free software should always have in mind their "hackability" from regular developers.

I remember a case where RMS didn't want to make some change in a project (i think it was Emacs) because it would make the project harder for people who didn't work on it to understand it.

And it makes sense, if you believe that what makes FLOSS good is that anyone could change and/or improve it, then it follows that you should try to maximize the pool of that "anyone".

I'd agree, and there are a number of little things which could improve hackability.

The last time I tried to contribute to Firefox, the first hurdle was that the repo contained over ten years of revision history, so it was gigantic.

Having an "archive" repo with a complete revision history would allow trimming the main repo to just the past ~12 months or so.

If you use git you can do this with the --depth n option when you pull it down

$ git clone --depth 1 https://blah.com/foo/qux

will pull down just one step in the history.

Unfortunately I believe that mercurial requires a large amount of the history to reconstruct the current version in the tree. Last time I tried to pull down firefox I was unable to because I was working on a system with 1GB of ram and the firefox repository requires at least >2GB to pull down properly -- I believe this is a fundamental defect in mercurial, but I might be mistaken.

Which then means that, as a side effect, you need to reject features!

Features bring side effects and complexity. If your goal of FLOSS includes allowing anyone to add a feature, that puts your goals in conflict.

And, to get back to the topic; I somehow doubt it's possible to support all major modern HTML, CSS, and Javascript requirements and keep the code immediately accessible to newcomers and casual coders. The only way to keep the goals out of conflict is to have a simpler version of the web.

You could easily make an argument that the same philosophy will benefit rapidly growing projects for full time devs. The less "arcane" knowledge needed to work effectively in the code base, the faster new engineers can onboard, the faster old code can have small changes made without breaking something else unexpectedly, and the list goes on.

Wouldn’t it be inversely proportional to the complexity allowed in the project ?

I imagine for instance a situation where for instance the project starts with a clear REST approach where GET requests are purely idempotent with no side effects whatsoever.

Then people start adding internal side effects (e.g. tracking, behavior scoring, suggestion building, and so on).

It’s harder to explain to a new dev that from some angle these requests are read only and nothing changes, and from another angle they change a lot of things.

But it would be counter productive to give up on features because it makes things less simple and brings a learning curve.

Sure, FWIW i wasn't trying to make an argument about keeping fulltime devs away. Trying to keep the codebase hackable for non-fulltime devs will also help fulltime devs too and even attract non-fulltime but otherwise dedicated (in their free time) devs. It is a good thing for everyone involved (assuming of course that the project does want others to be involved - there are projects that only release code but development happens behind closed doors).

Of course projects generally do not go with a goal of making it hard to have people contribute, it happens organically as the project grows. But i think after a project has realized they are in such a situation, they should make the necessary changes and improvements to get out of that situation.

The problem with assumptions is that no one knows they make them while they make them. It's a case of what's obvious to me isn't obvious to you.

It's also a case of things that aren't obvious on day one, but become obvious on day 3, or day 6.

Which is a very fair and valid opinion.

What I would then argue is that such an opinion limits where true FLOSS works and doesn't work.

> Perhaps the easiest way to encourage new contributors, who are assumed to be casual, is to encourage incomplete and partial fixes that the main team completes?

A better way is to reduce the complexity and, especially, tight coupling in your code base. Then it doesn't cost your own developers 15 hours to do something that should take one hour either.

If you look at the gnu utilities as a "project" then it's quite a lot of code, and in a sense it is a single project. To make ls(1) useful you need a shell, to make a shell useful you need things like readline(3), etc.

But if I have a contribution to make to readline, it shouldn't really affect ls, or vice versa. And if I want to swap out bash for csh or make my own toy shell that uses gnu readline, or use bash with the BSD version of ls, all of that is reasonably possible.

Browsers do that a little. Maybe the TLS library is a separate component, or the javascript engine. But how hard would it be to use the Mozilla javascript engine to create a toy browser to play with or to add javascript support to wget? How many external projects are actually using it?

Yeah 15:1 ratio of tech debt:domain work seems pretty bad. Although not abnormal.

GNOME and MongoDB at least use Mozilla's JS engine.

That's certainly better than zero, but those are each huge projects in their own right, with their own full time staff.

How many small external projects are using it?

Isn't the point of a pull request to submit code that functionally fixes a bug/adds a small feature, and then work on that patch until it's of sufficient quality to merge in? Things like style formatting, running tests among other things could be totally automated away here.

Bugfixes and small features need new tests.

The tests are often harder, and more time consuming, to write than the bugfix or feature.

Edit: And furthermore, when a casual / amateur creates such a pull request, it's not reasonable to expect that person to complete the pull request.

I would have to disagree, because there's a logical fallacy in your reasoning here. I agree with your point that in addition to fixing a bug, there's also the need to test, document, take account of maintainability, performance and coding standards and to do a lot more work that isn't quite so visible. And some of that burden is pushed onto the reviewers, testers and integrators of that work.

However, none of this is a justification for making the contribution process baroque and opaque.

I have noticed over the last 20 years or so that as a general rule the bigger the project, and the more closed the development process, the more baroque and opaque the contribution process is. Larger projects with more management layers seem to accrete unnecessary complexity and process, and generally behave in a more insular manner than smaller projects. I don't think things have to be this way. But I do think that keeping the processes simple, accessible and visible is important and that projects need to spend some effort upon keeping their projects open to external contributions. It's all too easy to adopt processes which work internally but deter and confound external contributions, and I think that should be something which project managers should be aware of and try to avoid doing out of short-term convenience.

A very insightful comment in another story worth repeating: https://news.ycombinator.com/item?id=20613520

Basically, you're advocating for replacing trust with bureaucracy.

I'm not sure how you drew that conclusion from what I wrote, when I said almost the exact opposite!

My argument was that bureaucracy, thoughtlessly imposed, was damaging for projects, and that it should be kept to the bare minimum...