[thenerdhead]

Title should be "Developer yells at .NET MAUI team and expects to talk to the manager because their bug hasn't been fixed in two years".

I hope people can see the hostile working conditions that many in open source have to experience daily. There is no possible way for a small team to scale with the thousands of issues they get and give every single one the same amount of attention. That is why it is so important for people to upvote and engage in issues. It gives the product and engineering teams a way to gauge priority.

There are much better ways to go about ranting about product defects though. Doing it in this way just encourages people to pitchfork. We all know that pitchforking isn't productive at all. In fact, it hurts more than you think it helps.

[MrGilbert]

I agree that it is usually useless to rant about an issue in the first place.

In this case, I can see that they were really neutral and understanding in the very first issue. After two years with little to no progress, I'd say it is natural to vent. Especially if they cannot get out of the situation they are in.

It looks like the original poster needs to use MAUI in their production environment. So they are already dependent on it. Which is to be expected, because MAUI already comes with a go-live license.

Also, I'd like to point out that this is not the pet-peeve of a small indie team. It is the future UI framework of a multi-billion company. If the team is understaffed, there should be something done about. The resources should be available in this case.

[thenerdhead]

The latter part should really be looked closer at. You cannot simply attach a company’s market capitalization to how funded a team actually is. People constantly overlook that. That’s true at many big tech companies too. The assumption harms just as much as pitchforking.

[physPop]

While true, I think the point is a mismatch between MS business strategy (marketing MAUI and the next big thing and officially supported) while not properly staffing. As an end user, you might make tech decisions precisely becuase of the market cap, assuming support and proper implementation. This fundamentally is the biggest issue with MAUI, no one can trust its not just marketing and going to be dropped...

[lopatin]

I think the developer is justified in his self-described rant. He has gone through other channels and engaged with the project leaders directly. He has waited years for the bugs to be addressed.

Microsoft is in the wrong here for selling this as the future and not dedicating the resources necessary to fulfill that promise.

[thenerdhead]

Maybe they were busy fixing other issues?

https://devblogs.microsoft.com/dotnet/announcing-dotnet-maui...

[willcipriano]

If you go to a resturant, order the soup and it's cold do you really give a crap about issues with other menu items that they are resolving instead?

"Yes the soup is cold, but we no longer give people botulism with the salads surely that counts for something"

[ratg13]

Shame can be a motivator.

Also you’re implying that MAUI does not have serious problems, which is not true the case.

It’s good to bring this to people’s attention so that others do not make the same mistake choosing MAUI as this guy.

The MAUI team should reflect as well about the reasons people need to stay away from their product.

Your “everything is fine, this guy is just overreacting” makes me think you haven’t worked much with MAUI.

[biorach]

This is not a typical open source project. The developers are all Microsoft employees who, in theory, are paid to work on MAUI

[thenerdhead]

How does getting paid change things? Many big tech companies "sponsor" OSS in this way and they have project backlogs bigger than the allowed limit on GitHub. https://github.com/orgs/community/discussions/9678

[biorach]

Damn right getting paid changes things

[JustLurking2022]

Because it implies these are people have far fewer excuses for the seeming lack of care about user feedback than some unpaid volunteer.

Considering many companies have contacts ranging from millions to hundreds of millions with Microsoft, and developer tools are a major selling point for the ecosystem, it's certainly reasonable to be upset that when your organization can't depend on them. It makes planning a nightmare - it may take a month or 5 years to deliver your feature, depending on when the bugs get fixed.

[rightbyte]

Oh it is very much possible to scale. Just drop the agile process, give the devs agency and fix the bugs.

Easely like 100x the efficiency fixing small bugs.

[MrGilbert]

Dev with agency here. There is clearly an issue, but "agile" is not it. "Agile" doesn’t mean "ship unfinished products and never care for issues".

In fact, it means quite the opposite: Start with as little as possible, as polished as possible and improve from there. It's actually quite nice to work with, if every role is on the same page.

[zihotki]

I wonder where you've found that definition of "agile". The agile manifesto says that they have come to value:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

There is no direct quality/polishness in there.

Edit: formatting

[MrGilbert]

Well… I guess Number 2 leaves room for discussion here.

[deafpolygon]

But 0x efficiency developing new features.

[rightbyte]

That is debatable.

[Angius]

> small team

Yes, we need to be more lenient on Microsoft. They're a tiny little startup after all, they barely have 10 employees and three of them are cleaners.