The ideal that the Web shouldn't be write-only is not new, either—it's been around around since the birth of the Web; Tim Berners Lee included features to publish pages in the first browser, WorldWideWeb. The idea of built-in devtools in Firefox also isn't new.
Firebug's predecessor DOM Inspector was shipping in Mozilla Application Suite and in Firefox up until Firefox 3. For Firefox 3, the team decided that DOM Inspector's utility to the masses didn't justify its costs. Mozilla Corp was a lot smaller then—150 or so employees. It was a common theme at that time to challenge every part of the browser both because of the QA involved and the ideal of shipping a light, focused product was still something that the team was aiming for. The DOM Inspector code was already mostly self-contained, so it was built and released through addons.mozilla.org as an extension.
The main reason the built-in devtools got included in Firefox aren't so much rooted in user-focused principles as it was convenience for the devtools team. Someone might appear in this thread to dispute this (I half expect Rob Campbell to show up), but it's truer than the idealism line. Bundling the new devtools into Firefox gave two advantages for the people working on it:
1. You're automatically given a big install base, i.e., you don't have to convince people to download your extension.
2. Maintaining features as an extension introduces some work that you don't have to deal with if you just shove your code into the mozilla-central codebase. In 2010, extension authoring sucked. If Gecko couldn't do what you needed or browser.js didn't have hooks for you, you just roll those things into the same patch that introduces (or fixes) the feature you're working on.
Fun fact: The number of years that Firefox has shipped with a built-in inspector actually outnumbers the years that it was without one. Firefox 3 was the first release that didn't include DOM Inspector. That was 2008. A couple years later the devtools project was announced, and it was slotted to ship in Firefox 4—which ended up delayed for 6 months or so. (If I recall correctly, devtools either ended up still missing the boat, or it shipped with parts turned off because they weren't mature/stable enough yet and they were reenabled within the next few releases after Firefox had switched to the rolling release cycle.)
EDIT wrt your comment about no distinction between "developers and users": Firefox Developer Edition's existence is a contradiction
I think you mean read-only, no?
https://en.wikipedia.org/wiki/Write-only_language
in this context it's about having the source code accessible itself, instead of only a binary/bytecode available (or some obfuscated/minified code)
> Firefox Developer Edition's existence is a contradiction
It isn't a contradiction. The only devtools that are in FDE but not in Stable are experimental ones that are on the path to stabilization. It's a testbed, not an enclave.You can make a userscript without any of that hassle, though.
It is possible, you've just chosen to disallow it.
To be clear: the Firefox team took deliberate steps to make sure that add-ons can't be tested or developed in the stock builds of Firefox downloaded from Mozilla.
See your sibling below: > Unsigned addons cannot be enabled on beta or release. That was only available for a limited time. Now they can only be enabled on alpha (aka developer), nightly, or special unbranded builds.
Not even close. Netscape had this in the late nineties, IIRC.
Those were the days