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

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 (many!) 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

It's worth considering all those packages I created (linked above) are still up on GitHub but the agency I worked for no longer exists and no one is maintaining those packages. This is why customers invest in Kentico - guaranteed support, maintenance, security.

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.

• Author a community integration using our guidance and repo template.

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.

I feel like distributing code for educational purposes as a NuGet package can be a bit contradictory.

I think it's the responsibility of the consumer, not the author, to determine if they want to take a dependency on a package. It's related to that mindset shift I mentioned.

Some teams might be ok with it, even if the package has no guarantees around support or accepting contributions, because they acknowledge they can "vendor" it and bring it into their codebase if needed.

it would be ideal if a blog post and proper documentation accompanied the code repository as the main resource.

I completely agree with you!

I think I have a hat to throw in on this one!

What motivates you to create and maintain community nuget packages?

What often would motivate me was to help others who may need something that Kentico didn't have (or would have but farther in the future). I wanted people to stay on Kentico, and also to leverage it well. I hated how many agencies had their own solutions but no one ever shared. I get it from a business standpoint, but I disagreed with the mindset.

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

I have so many modules, especially in the Portal Engine days. I created what I created to make development easier, solve common problems, and help people stay on / stay up to date with Kentico.

How do you think about long-term maintenance, especially knowing that some projects rely on your package as a dependency?

Honestly, I try not to be "that guy" that builds a package and never maintains it - It frustrated me to no end on the occasions I used a 3rd party package.

So, when I built my systems, I built with a mentality of "Make it so others can use it." Often this would result in complex or complicated packages, which is the down side, it may be harder to use because the feature set is more wide.

I've spent considerable time over my tenure updating packages, and this was back when I had 5+ main custom modules and each Kentico version I had to rebuild, and if a bug came along often having to rebuild and fix older versions and republish. I know I can't expect others to do that, because it's a pain, but I did it.

Overall, I would like to think that my packages were known for being supported, and why in the Portal engine days many used my packages. But I may be delusional. But even if I can solve a problem so 1 or 2 more people can migrate or use Kentico earlier, then it's worth it.

I remember packages like the KX12 to KX13 Portal migrator were massive undertakings but helped a LOT of people (and now Kentico has its own migrator tool, which is awesome!)

I know the Media Library Migrator tool helped a lot of our clients (and possibly others) move from on prem to cloud based easier.

The Baseline project to help those with the "Do we build on KX13 or wait until Xperience is mature" decision back when Xperience was new.

The hardest part though is I put a lot of work into my modules, and often I have very little knowledge of how much they were actually used outside of my organization. I know they were, but I have no way of knowing how many people were able to stay on Kentico, Migrate to Xperience, use Xperience earlier, etc.