The features would break if they were built in.
You can’t know that and I can’t imagine it would be true. If the plugins many folks find essential were incorporated into GNOME itself then they’d be updated where necessary as a matter of course in developing a new release.
GNOME has clear philosophy and they work for themselves, not for you so they decide what features they care to invest time and what features they don’t care about.
You’re not wrong! This is an arrogant and common take produced in poor taste though. A holdover from the elitism that continues to plague so many projects. Design philosophy leads UX decision making and the proper first goal for any good and functional design is user accessibility. This is not limited to accomodations we deem worthy of our attention.
Good artists set ego aside to better serve their art. Engineers must set pet peeves aside to better serve their projects. If what they find irksome gets in the way of their ability to build functionally better bridges, homes, and software then it isn’t reality which has failed to live up to the Engineer’s standards. This is where GNOME, and many other projects, fall short. Defenders standing stalwart on the technical correctness of a volunteer’s lack of obligation to those whose needs they ostensibly labor for does not induce rightness. It exposes the masturbatory nature of the facade.
Engineers have every right to bake in options catering to their pet peeves (even making them the defaults). That’s not the issue. When those opinions disallow addressing the accessibility needs of those who like and use what they’ve built there is no justification other than naked pride. This is foolish.
Having a standardised method for plugins is in my opinion good enough, nobody forces you to use extensions. And if you don’t want extensions to break, then wait till the extensions are ready prior updating GNOME.
I agree! Having a standardized method for plugins is good, however; the argument which follows misses the point. GNOME lucked into a good pole position as one of the default GNU/Linux DEs and has enjoyed the benefit of that exposure. Continuing to ignore obvious failures in method elsewhere while enshrining chosen paradigms of tool use as sacrosanct alienates users for whom those paradigms are neither resonant nor useful.
No one will force Engineers to use accessibility features they don’t need. Not needing them doesn’t justify refusing the build them. Not building them as able is an abdication of social responsibility. If an engineer does not believe they have any social responsibility then they shouldn’t participate in projects whose published design philosophy includes language such as:
Their walk isn’t matching their talk in a few areas and it is right and good to call them to task for it.
Post statement: This is coming from someone who drives Linux daily, mostly from the console, and prefers GNOME to KDE. All of the above is meant without vitriol or ire and sent in the spirit of progress and solidarity.
Sure! That’s an SMTP Relay. A lot of folks jumped on the poopoo wagon. It’s common wisdom in IT that you don’t do your own email. There are good reasons for that, and you should know why that sentiment exists, however; if you’re interested in running your own email: try it! Jist don’t put all of your eggs in one basket. Keep your third party service until you’re quite sure you want to move it all in-house (after due diligence is satisfied and you’ve successfully completed at least a few months of testing and smtp reputation warming).
Email isn’t complex. It’s tough to get right at scale, a pain in the ass if it breaks, and not running afoul of spam filtering can be a challenge. It rarely makes sense for even a small business to roll their own email solution. For an individual approaching this investigatively it can make sense so long as you’re (a.) interested in learning about it and (b.) find the benefits outweigh the risks, and (c.) that the result is worth the ongoing investment (time and labor to set up, secure, update, maintain, etc).
What’ll get you in trouble regardless is being dependent on that in-house email but not making your solution robust enough to always fill its role. Say you host at home and your house burns down. How inconvenient is it that your self-hosted services burned with it? Can you recover quickly enough, while dealing with tragedy, that the loss of common utility doesn’t make navigating your new reality much more difficult?
That’s why it rarely makes sense for businesses. Email has become an essential gateway to other tooling and processes. It facilitates an incredible amount of our professional interactions. How many of your bills and bank statements and other important communication are delivered primarily by email? An unreliable email service is intolerable.
If you’re going to do it make sure you’re doing it right, respecting your future self’s reliance on what present-you builds, and taking it slow while you learn (and document!) how all the pieces fit together. If you can check all of those boxes with a smile then good luck and godspeed says I.