ama

ts, and there is no external specification to satisfy, other than for some internals that can be outsourced to a library. This allows for much, much more reduction of complexity. > Do you know of any "serious open-source software" of comparable scale, which does not require big companies paying for it, even taking into account the argument around unnecessary complexity? The problematic part in this question is "of comparable scale". To put it bluntly, pretty much all of the software that meets that description has an inherent complexity problem, either having too broad a scope or reinventing too many wheels. So no, I don't think that at that scale corporate funding is avoidable; but I also think that the scale itself is the problem. I do think that corporate funding is largely avoidable with a different approach to open-source development entirely; one that (re-)recognizes that open-source is about a shared public commons, not just freely downloadable software, and that prioritizes collaboration and modular, shared implementations over reinvented wheels. Unfortunately we have a lot of cultural issues to fix to get there, not the least of which is the recent-ish appropriation of "open-source" by certain companies-that-shall-not-be-named as a developer marketing tool, paying basically no mind to the "public commons" part and calling it open-source merely because it's under an open-source license and it looks good on GitHub. That's certainly not to say that this is entirely a corporation or commercial problem, though; there's definitely also an aspect of NIH culture and dependency avoidance among individual developers, where people have wildly inaccurate ideas about the costs and benefits of dependencies, and lacking knowledge in how to manage them effectively. One typical example of this is the JS ecosystem, which gets a lot of flak for one-liner modules[1] but was actually well on the way to addressing this problem - right up until Node.js started getting hyped up, and an endless stream of shiny reinvented wheels from startups started showing up, many of them poor copies of tools that already existed and worked well. Webpack is a notable example here, which really is just a worse Browserify in every sense. Ultimately, this is probably the only plausible solution to this problem that I can see. Modular projects with a well-defined scope, that actually have a reasonable chance to reach feature-complete status, where the implementations are widely available and reusable in a broad variety of different projects that can themselves become feature-complete. Where only one developer has to do the work and it is then forever done. Whether that's in JS or something else entirely. [1] https://github.com/sindresorhus/ama/issues/10#issuecomment-1...

ts from the collective testing and improvements made to these modules. I also wanted to add that widespread use of these small modules over inlining everything makes the new module-level tree-shaking algorithms (that have been gaining traction since the advent of ES6 modules) much more effective in reducing overall code size, which is an important consideration in production web applications.