Let’s Talk About Building, Sharing, and Maintaining NuGet Packages

2026/01/13 2:20 PM

Based on my article “Community Packages in Xperience by Kentico: Balancing Convenience and Stability”, I’d like open a discussion, primarily with existing Kentico community contributors:

  • What motivates you to create and maintain community nuget packages?
  • How do you expect other developers to use your work, and what is your approach to contributions or collaboration?
  • How do you think about long-term maintenance, especially knowing that some projects rely on your package as a dependency?
Tags:
Community members Integrations

Answers

2026/01/13 3:14 PM

A couple things I want to mention to start:

  1. Fantastic post! I really appreciate how you covered this topic from multiple perspectives.
  2. Thank you for opening the discussion for it here on the Community Portal 🙏

Now, to respond to your thoughts and questions from the post:

I would love to hear from these contributors directly:

  • Could you share your thoughts on what motivates you to create and maintain Community packages?

  • How do you expect other developers to use your work, and what is your approach to contributions or collaboration?

  1. I share code publicly on GitHub and here on the Kentico Community Portal in blog posts to educate and inspire.

  2. I do not expect developers to grab a NuGet package I create and use it in their projects. If they want to do this - great, but even when I created Xperience packages while working for an agency I was sharing solutions to my problems with no intention of solving other people's.

    I do expect developers (or their AI agents) to review the code I share to get ideas on how they can solve similar problems or for their projects and stakeholders.

However, as potential consumers of these packages, we should be aware that there is no guarantee of long-term maintenance, direction, or support.

This isn't considered by developers nearly enough!

There are several other CMS/DXP products that rely on a giant open-source plugin ecosystem to fill in product gaps. This has benefits and drawbacks:

  • ✅ There are lots of off-the-shelf packaged solutions to pick from.

  • ✅ Open-source can be customized or contributed to fit your needs.

  • ❌ Open-source very rarely comes with security or maintenance guarantees.

  • ❌ No promises of support - you might not even know who to contact!

  • ❌ Quality if measured by something like stars, usually from a non-technical end-user.

Kentico's customers almost always select Kentico in part because of security and support guarantees. The exact features that open-source plugin ecosystems don't provide.

Developers usually make decisions to adopt open-source libraries without getting stakeholder approval. They want a solution to their problem, find one in a package, and add it. Job done! At best, they consult an architect who uses their own judgement to decide if a package is healthy enough and make sure the package license is compatible with legal requirements.

Veteran architects realize that when you take on a 3rd party dependency that doesn't have a paid support policy, it is now your code and your responsibility!

Do agencies or digital marketing teams realize or think about this? Very likely no! This is a developer mindset that needs a bit of a reality check, in my opinion.

A GitHub repo with active PRs and resolved issues is no guarantee of:

  • Current security

  • Willingness to add support for your specific customizations

  • Future maintenance

A final note - in the age of AI assisted software development and an AI agent's ability to generate, reproduce, or transform open-source code to fit your solution significantly lessens the value of using these packages for a turn-key solution. But, in my opinion, it doesn't lessen the value of using them for education or inspiration.

To wrap up:

  • Keep authoring open-source for Xperience by Kentico 👍👍

  • Sharing ideas through open-source code benefits the community and helps fellow developers, even if no one ever uses your package in production.

  • Decide the level of commitment you are making to the community when you open-source code and consider communicating that in your repository README.md.

    • For example, at Kentico we have 2 types of open-source projects - fully supported and labs. Fully support repositories are intended to be used by partner agencies and customers. Labs exist for education and clearly marked with no guarantees of support to help set expectations.

  • Review the list of open-source integrations here on the Kentico Community Portal to get inspiration.

2026/01/13 4:08 PM

I feel like distributing code for educational purposes as a NuGet package can be a bit contradictory. Sure, it’s easy to add it to a project and see the results. But it’s also tempting to just drop it in, hope for the best, and never actually explore the underlying repository or adopt it properly. So when a NuGet package author creates a Community package for Xperience by Kentico, it would be ideal if a blog post and proper documentation accompanied the code repository as the main resource. The NuGet package could then serve as an extra tool to see it in action, with a strong recommendation not to use it in production.

To response this discussion, you have to login first.