6 ms·

> Honestly, this shows why projects of major complexity need professional full-time developers. I think the opposite, it shows why projects that care about th

by Crinus 7y ago

> 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".

levythe 7y ago
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.
- gwbas1c 7y ago
  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.
- Crinus 7y ago
  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.
- hrktb 7y ago
  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.
gwbas1c 7y ago
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.
cellularmitosis 7y ago
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.
- fao_ 7y ago
  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 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.
gwbas1c 7y ago
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.

by Crinus 7y ago

levythe 7y ago

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.

gwbas1c 7y ago
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.
Crinus 7y ago
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.
hrktb 7y ago
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.

gwbas1c 7y ago

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.

cellularmitosis 7y ago

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.

fao_ 7y ago
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 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.

gwbas1c 7y ago

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.