I think I'll be clear about this: I am not anti-Mozilla.
(Though putting Pocket in their addressbar rather than an RSS/Atom subscribe button does go against my design principles for encouraging a more decentralized web)
I think they are a positive influence, but they have too much influence to loose to be as radical as they pretend to be.
At the same time we do need a truly radical browser engine to help get us out of the sad software development we're in. I hope to be that!
I think I'll expand on what that design principle I have is: I do not integrate specific websites into my browser, whether it's my own or others. Always allow integrating multiple webservices into homepages, searchboxes, etc rather than just one.
I haven't managed to fully adhear to this yet, and I did make an exception to discourage reliance on YouTube.
But Mozilla doesn't know how else to make enough money to implement a "modern" browser engine. Neither do I.
Might be answering a rhetorical question
You should've asked earlier
The main problem is that browser design has always been a loss leader for web-based services. (1500 characters deleted) That doesn't mean you can't find a business model that will work, but having loss leaders in your target market means rethinking fundamentals about markets. In this case, for example, both for profit and nonprofit vectors are saturated, so you'd need a thoroughly postcapitalist approach
Distributing a browser that arrives on the end-user's desktop with a default configuration that approaches decisions they would make for themselves might be easier than attempting to eliminate any bias
But let me know if you're interested in a run down of the core ideas
@yaaps My approach so far is to tackle a poorly addressed niche, illustrating the benefits that have been discarded in the rush for webapps.
But I'm open to all ideas!
You're an artisan. Occupying niches too small for economies of scale is how this precapitalist pattern survives and how it spawns new businesses under capitalism. It relies on a certain amount of privilege in that you need free time, skills, and personal/professional connections to succeed. in addition, the artisan is vulnerable to their own success. Replacing artisans with commodity labor is how capitalism grows
To scale up while maintaining autonomy, you need to establish a worker's collective. That provides a model to distribute income for skilled labor, as needed, without selling equity. Then you can crowd fund, if needed, while building a distributor network
Developing an independent distribution network is how you avoid becoming dependent on key donors. Your browser product will be customizable and unopinionated, with strong privacy defaults, which is not so friendly to most who would use it. Distributors will provide opinionated customizations to end users who share their opinions, without disabling privacy defaults or removing the ability to modify customizations. Your ideal distributors would be those providing community-owned alternatives to profit-driven content platforms - looking at internet access co-ops, user freedom CAPs, student government, clubs and hobby organizations. The general shape of the relationship looks something like the Linux distro marketplace, but maybe a different ratio of financial donations to code contributions going upstream. The idea, however, is to make it easy to repackage your browser with their settings and worthwhile to preserve your user-centric features and contribute
@cy Absolutely the stance I take!
It's achievable for me to build a web that work absolutely anywhere, it's by no means achievable nor worthwhile for me to build a web that does everything.
I need others to implement what should have long ago been discarded as out-of-scope for the web as native apps.
I'm attempting to change the rules!
Reasoning from lesser to greater, if I don't want to run arbitrary code in a web browser to read news, look at grocery sales papers, or report a broken dryer in the apartment laundry room, then I certainly don't want to install a native app for these things. Doubly so if "native" is actually rebranded Chrome with the web app baked in
So I think it's important to have a definition of document that includes forms, but to draw the line at executing arbitrary code or sending any information to the server that outside of that specifically requested of the user. In order to accomplish that, there would need to be a browser engine that is not designed by those working for publishers
As a bonus, such a browser engine might actually be useful to render HTML documents within a native application without the bloat of an engine designed to cope with the web as an execution environment. Thinking ActivityPub client and game clients, here
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.