Is Microsoft managing OSS initiatives well? The case of issue #3324

How does it make sense that Microsoft’s NuGet, an important platform development tool, won’t stop using 35-year-old technology even when it’s negatively affecting developer productivity?

Why has this problem been known about and put on the back burner since 2016, even when straightforward solutions are available?

Is Microsoft managing OSS well? In many cases it seems not, at least from a process perspective. It’s not a blanket indictment. Some projects are clearly run well. However, anecdotally many projects have problems that might never exist under better stewardship. Following is one example of what appears to be an OSS misstep that has a significant impact on developers.

Before judging, let’s be fair: over recent years OSS has clicked more and more with Microsoft, resulting in some shrewd strategic decisions and significant investments. They deserve much credit for having people like ScottGu and many others, who can see the world changing and adapt effectively. Many large or older companies are never able to do this. Also, we should recognize the difference between OSS management and internal work. There is an amazing amount of world class software engineering that gets done at the company. None of that withstanding, the problem described here is a real and unforced management error as well as a developer relations error.

How does it make sense that Microsoft’s NuGet, an important platform development tool, won’t stop using 35-year-old technology even when it’s negatively affecting developer productivity?

Why has this problem been known about and put on the back burner since 2016, even when straightforward solutions are available?

Maybe you’re thinking, surely there’s a misunderstanding. It can’t be that important. Projects have thousands of bugs to triage and no company can fix them all. Issues must be prioritized. There must be a rational explanation, right?

I wouldn’t blame you for thinking that. In fact, I hope I’m missing something. Any corrections are welcome. But look at how it appears from the outside:

• Microsoft’s NuGet package manager can’t handle paths with length > 260 characters, just like MS-DOS. The path, including the filename, can’t exceed this, yet the need is very common in development scenarios. The problem is described at GitHub as issue #3324.
• NuGet is important. It’s important not only as part of the tool chain, but also strategically. The way it modularizes and simplifies software component use has made package management crucial to growing any ecosystem.
• Other popular package managers that run on Windows, like NPM, don’t have this bug or limitation. This is not a technically difficult problem to solve.
• This bug wastes time in many ways. For example, some teams end up redoing or reorganizing large development hierarchies. Besides hurting productivity, this is an error prone operation that could easily cause unexpected DevOps problems in unrelated areas.
• Ironically, the root cause of the problem was actually a design Paul Allen (Microsoft co-founder) helped work on for 8.3 filenames, which he wrote code related to ~35 years ago. Microsoft has long since added alternate APIs and techniques that NuGet could easily use to fix the problem, but has chosen not to. Even if fixing the issue came with any backward compatibility concerns, there’s still no reason a switch, option, or alternate executable couldn’t be used.
• Is F word development a new programming style? This issue has recently driven developers to start using the F word in the bug comments. It’s somewhat easier to make sense of the profanity when you realize the bug has existed since back in 2016. What percentage of issues within Microsoft’s GitHub projects contain the F word? I’m guessing it’s a small percentage, a signal this issue is not in a good situation.
• How does it make sense that a bug with zero upvotes about improving verbiage of an error message (#6630), gets a Priority:0 label (higher priority), while the NuGet issue (#3324) has 39 upvotes with no Priority:0 label, and has actually had its priority reduced over time?
• Why not provide at least one detailed status update? A rough sketch plan to fix, or a roadmap milestone (only estimating) when the bug might be fixed? Why not say a few words explaining why the priority is not higher? Maybe there’s a reason that rewording the text of error messages has a higher priority, who knows? Communication itself is part of good OSS management. Lack of transparency and communication by themselves can drive frustration, and leave people unable to plan efficient work-arounds to the problem.
• The community has offered to help with anything needed. Why couldn’t writing code, providing a pull request, maybe even debugging or testing be helpful? Most development teams are working damn hard, often near their capacity limit, and maybe this is the case with the devs involved here. That deserves empathy not criticism. But how does it make sense that help offered would not be accepted? If it’s too much overload to even manage the help offered, maybe it could just be acknowledged with a “thanks but no thanks”?

Whatever the case, I propose the priority of issue #3324 be increased, and a little information on its status be provided.

If you agree, it would be great if you wouldn’t mind helping to bring attention to the issue by:

• Click a social link here to share. You’ll help raise awareness with Microsoft and/or developers who care about the Microsoft development platform and tool chain.
• Upvote issue #3324 on GitHub here.
• Write a comment below. If you want to write your own post let me know and I’ll upvote and link back to you.