Earlier quoted context omitted.
> At a Microsoft sized company I'd get it because they can basically blow billions on that sort of thing It also helps that Microsoft is in the business of selling IDEs.
Interesting question: why isn't Mozilla in this business too? They've got a cross-platform desktop app toolkit sat right there , and big enough developer mindshare to be interesting. There's room for a Firefox-flavour web dev IDE in the market, surely? Firefox dev tools, only with edit-in-place and live debugging for server-side assets. Seems odd to me that they've never gone that way, given everything else they've t…
"Much" of the Rust/Wasmtime team hit by layoffs at Mozilla
291–300 of 352 posts
Re: "Much" of the Rust/Wasmtime team hit by layoffs at Mozilla
#292From many of the comments in this thread, one might think that FAANG companies invented the concept of open source software or that software doesn't exist outside the context of a "profit model." Whatever is going on at Mozilla right now, the notion that a piece of open source software even needs to be profitable (let alone supported by a single large company) in order to continue existing is ridiculous. I'll concede…
> Whatever is going on at Mozilla right now, the notion that a piece of open source software even needs to be profitable (let alone supported by a single large company) in order to continue existing is ridiculous. Large FOSS projects requiring specialists (like Rust does) all seem to supported by companies paying, and often it's a large single company too, whether that's like PHP and Zend, RedHat and various projects…
Also I wonder if browsers really need to be large projects requiring specialists or they've become this way because organisations making them are happy with such an entry barrier.
Re: "Much" of the Rust/Wasmtime team hit by layoffs at Mozilla
#293Earlier quoted context omitted.
Firefox has development tools? Is there certain features that are missing? Because you can bring up a dev console and inspect elements and such. Genuine question from a not full-time frontend developer, not being snarky.
Firefox has had development tools from way before Chrome even existed. They started as an (awesome!) Firebug extension, which they later included in the browser itself (not that it matters, but it was Chrome that basically copied them at the time).
Dedicated work on Chrome DevTools started only in 2009 and before version 3 or 4 Chrome had only had Elements panel inherited from Web Inspector, Console and gdb-style command line debugger (perhaps basic Network don't remember). It was catching up with Firebug quickly though because web developer tools was stated as a priority for the project.
Re: "Much" of the Rust/Wasmtime team hit by layoffs at Mozilla
#294Earlier quoted context omitted.
Firefox is open source and it doesn't need to be tied to Mozilla. Maybe a fork is necessary.
There are already many forks of Firefox with separate development. See Waterfox, Palemoon, etc. None seem to get the kind of development needed to compete with Chrome/Safari/Edge.
Re: "Much" of the Rust/Wasmtime team hit by layoffs at Mozilla
#295Earlier quoted context omitted.
Not when conditions are attached to the payment or donation.
Even when it is. This should be obvious. Not even sure why I'm spelling this out. Say total amount of money an organization has is $X + $Y. Group A is assigned $X in funding. Group B is assigned $Y in funding. Group A gets $Z in donation with conditions attached so it only gets used by Group A. Then the organization assigns $X - $Z funding to Group A and assigns $Y + $Z funding to Group B. Group A is happy because it…
1. Limits. The above doesn't apply when $Z > $X, above which the attachment has full effect.
2. Reputation. The sources of recurring $X + $Y have decision making powers with a time lag. They may not be willing to give $X + $Y again if they know it was entirely spent on group B last time.
3. Anticipation. Organization decision makers know 2. Which makes donations with conditions attached into a signal with some effect, rather than something freely fungible with no pressure.
If we were to plot a curve of notional pressure and effect on the organization's budgeting decisions, I would expect a curve increasing with the ratio $Z/($X+$Y). A very shallow curve perhaps. But not a flat zero in the range 0..$X as you are suggesting.
Re: "Much" of the Rust/Wasmtime team hit by layoffs at Mozilla
#296Earlier quoted context omitted.
Firefox is open source and it doesn't need to be tied to Mozilla. Maybe a fork is necessary.
"Open source" doesn't necessarily mean "practical to maintain." Can an open source organization maintaining a fork of Firefox in their free time in addition to the obligations of their regular job keep up with the hundreds of webcompat issues being filed and over 3,000 open issues on the preview version of Firefox on Android alone? And there also is a fork of XUL-era Firefox already, called Pale Moon, which various p…
Re: "Much" of the Rust/Wasmtime team hit by layoffs at Mozilla
#297Re: "Much" of the Rust/Wasmtime team hit by layoffs at Mozilla
#298Earlier quoted context omitted.
For Apple, Microsoft, and Google, their open source activities are all loss leaders for their profitable ventures. Apple sells hardware, and most of their software offerings, like MacOS, their office suite, and Safari, and given away to convince people to buy that hardware. Also, it's not like they're spending a whole lot of time making Sarafi the best browser around. Microsoft's web browser was created (and bundled)…
Is open source a loss leader for Apple, really? Or is it something they mostly get for free, but have to contribute a little back to shape it how they want? The point I read from GP, at least, was that open source is cheap for these big corps because they get a ton of benefit for it, but non-profit (either orgs or individuals) are bearing the brunt of the cost.
Re: "Much" of the Rust/Wasmtime team hit by layoffs at Mozilla
#299Earlier quoted context omitted.
> " The actual reality of this is that they are still kept alive by a direct competitor for decades and haven't made anything to generate significant sources of revenue. Maybe they should turn into a Rust consultancy of some sort. I don't know. " The odds of them being able to build a business that that replaces the several hundred million they get from Google (which is essentially pure profit, not even revenue) are…
> The instant Google decides they're no longer useful, Mozilla is going to go poof. People keep repeating this but couldn't Bing replace Google as the default? The "default search engine" position is actually worth money.
By accepting the Google cheque, they directed people towards Google and may have indirectly funded Chrome and monoculture.
If they had directed people towards Bing when they had 30% market share, that may have resulted in a search engine duopoly instead, and a greater chance of Microsoft selecting and funding Gecko/Servo instead of Blink.
Re: "Much" of the Rust/Wasmtime team hit by layoffs at Mozilla
#300Earlier quoted context omitted.
> To be fair, the existence of open source software that is very expensive to develop has always dependend on big companies paying for it. I think you're getting the causality wrong there. A lot of the "open-source" (often barely) software built and funded by large corporations has a tendency of accumulating endless technical debt and complexity, and being inaccessible to outside developers. Not dissimilar to much pr…
A reasonable argument, and so I've upvoted. But even taking into account removing unnecessary complexity, a web browser that users will choose is still complex, and has a very high compatibility bar, which is also a moving target. You might say, does the browser need to much in it? Well, for users to choose it as a daily driver, it needs to work with web standards, formal and informal, and with nearly all sites. The…
While in retrospect it's understandable why it happened (economic forces etc.), it also means that the web-related specifications were never really designed with the consideration of "how could we build an operating system that doesn't highly centralize complexity". And so we're now effectively stuck with a huge pile of specifications that you pretty much have to implement to call yourself a browser.
But for most other software, this isn't true; because most software is implemented according to some pre-defined set of goals and/or requirements, 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...