State of the NuGet Ecosystem
Over the last six months, the NuGet team has been busy running user surveys for NuGet and the .NET ecosystem. Recently, our team launched our first quarterly user survey for NuGet.org. With over 500 responses, we wanted to spend some time to share with you what we’ve learned in these last few months.
In this blog, we discover & dive deep into questions around NuGet’s ecosystem because we recognize that an active and healthy package ecosystem is crucial to growing the .NET community.
We are thrilled to see a consistent level of satisfaction with NuGet, with 81% of the respondents being satisfied for both NuGet.org & the .NET ecosystem.
We have also interviewed 100+ developers, which means that the community has spent over 50 hours teaching us how to be better. We deeply appreciate the time everyone took to provide feedback to us, and we want to share our findings with you. We want to be fully transparent about where NuGet is heading and how you can be part of our journey.
If you’re interested, read on!
In January of 2021, NuGet celebrated its 10 year anniversary with more than 1 billion downloads a week and over 230 thousand unique packages. We could not have gotten here without the .NET community – all of you!
Even though we are proud of our milestone, we recognize that there is still plenty of work to build an excellent ecosystem around NuGet. To better understand the needs and struggles of our users, we asked a number of questions related to NuGet’s ecosystem in this quarter’s survey. We’re sharing the results in this article to help package authors build more useful packages and help package consumers make better decisions. Below, we will dive in deep on specific problems and solutions.
Improving the Package Author Experience
When asked to rate satisfaction for various elements of the package authoring experience, the elements with the lowest satisfaction were “Understanding the best practices for authoring packages” and “Viewing package download statistics.” Many of the developers we interviewed strongly agreed and added that they do not understand how well their package is doing because there are little statistics and those available are hard to use. In addition, developers mentioned wanting to know which .NET frameworks to support, how to version packages, what metadata to include when creating a package, and others.
“What I really want to know as a library author is when I should be supporting new versions of .NET. Data about community adoption of new frameworks would be great.”
Documentation for package authoring best practices has been published here. In addition, the NuGet team is investigating ways in which we can build best practices right into the package creation experience – for example, providing package quality score/rubric that clearly outlines the best practices, or even generating a standard package metadata file that can be further edited to specifics.
Let us know about your thoughts in the discussion here. Are your problems reflected in our findings? What would be helpful to you?
Improving the Package Consumer Experience
Unsurprisingly, the top problems users faced as package consumers were linked directly to those experienced by package authors. They include “It is hard to tell if package is of high quality and actively maintained” and “Most packages have insufficient package info/docs”, which point to a need for more standardized authoring best practices and documentation. This feedback showed up frequently in our interviews with developers as well. When asked about their current process for choosing new packages to use, one interviewee said: “I just try all of the links. Trial and error.”
“Showing package documentation on NuGet.org would be very exciting. It would save me the trip to GitHub.”
We are currently investigating improvements regarding package quality metrics, vulnerabilities, and compatibility. Generally, we want to make that information easier to access for users looking for maintained, secure, and high quality packages for their project.
When asked about their top problems with NuGet’s ecosystem, the reasons selected by the most respondents were, “Critical packages I need do exist, but they aren’t maintained. (47% reported)” and “Critical packages I need do exist but they are not well documented. (45% reported).” This makes sense because at 10 years, NuGet has existed longer than most package managers and has an older package ecosystem, but the team is working with the .NET Foundation to better ensure that crucial packages are maintained.
There is an even better way to contribute to the ecosystem, if you’re interested in helping out. Note that all other reasons start with “critical packages I need do exist…”, meaning that package users were facing challenges even when packages exist. This tells us that we can improve the ecosystem by improving what is already there – by filing bugs, improving documentation, adding missing features, implementing support for the ‘other’ platform, adding tests, and so on. Consider finding a package that has potential but has not been loved enough and contribute towards it – with tests, bug reports, feature contributions, or examples!
- Include documentation on how to getting started with a package
- Include screenshots, animated gifs, or videos
- Include a link to the corresponding code repository
We want to convey a huge thank you to the more than 500 NuGet users who filled out the long survey. We learned a lot — some other highlights are listed below.
Transparency. We saw a lot of interest in open source and general transparency of information. Having packages be open source was a top requirement for many of the developers we spoke to, and developers overwhelmingly wanted access to additional data about package metrics and target framework compatibility.
“Automatically hiding certain things doesn’t sound smooth, it sounds confusing. Just show me all of them and give me the information I need to choose.”
NuGet Should Just Work. Many of the developers we spoke to voiced the same desire for a more efficient, fluid process where things work as expected. Common requests included additional automation, a smoother starting process for new .NET developers and veterans alike, and less clicks needed to perform tasks like unlisting packages.
“If my internet is down and NuGet tries to restore packages I have in cache, it should just work. But it doesn’t, and it just gets more complicated. I have to stop what I’m doing to run tests, and I really don’t want to do that.”
“If they’re the same steps every time, everything should be automatic.”
Tough Love. Last but certainly not least, we now have a much better understanding not just of how much and what more we need to improve, but of the amount of passion and energy within our community.
“I’m not bashing NuGet, I just think it has the potential to be one of the greatest.”
“There’s nothing wrong about NuGet in terms of technical architecture. It just doesn’t make me happy to use.”
There are many problems in the NuGet ecosystem that we know about but even more that we do not. We would love your feedback to define our next steps. We have enabled GitHub Discussions to allow you to do just that.
If you can, take a few minutes to open up an issue about anything NuGet that has been on your mind.