Future of Nuke

[Droppers]

First of all, I would like to say that this is in no way an personal attack, because I really understand that maintaining an open source project next to your main job can be exhausting.

What we (our team) are looking for is a discussion about the future of Nuke, because for us the uncertainty makes it difficult to rely on Nuke. I think clear communication is a very important factor.

For us there a currently several issues with Nuke, especially since we heavily rely on it with 100+ Nuke pipelines:

• SLNX files are becoming the standard, they are easier to maintain and the only reason we cannot move to them is because Nuke is missing support.
• Tools are heavily outdated or are missing, for example Yarn, of which we created a pull request a long time ago. Docker tasks, Kubernetes tasks, etc...
• Major or minor breaking changes are not discussed with the community, some examples we ran into that resulted in a quite a lot of work:
  • Removal of (in our opinion) the better Arguments class.
  • Changes in tool resolving logic.
  • Major changes are made on private branches (correct me if I am wrong) and then merged into the develop branch, instead of pull requests, which would allow us to give feedback.
  • Outdated dependencies.

We see the following options:

• Allow additional maintainers and encourage pull requests and discussions about new features (best option, this would offload a lot of work for you, and make this project more active). Based on the the reactions on this issues there a quite a few people interested in the future of Nuke.
• Fork the repository. This is something we are considering, by making an internal fork and adjusting Nuke to our likings.

[jwfx]

Thanks for bringing this up, we are facing exactly the same challenges.

• We're also blocked by the lack of .slnx support. A feature contribution was already offered in Compatability with .slnx format #1520 and I would be happy to offer help with testing, even during PR phase.
• Tools are also an issue for us. We're already started maintaining things like dotnet package support ourselves, which could easily be contributed as a PR.
• Hidden breaking changes are indeed a problem. We held off upgrading to 9.x for quite a while and still ran into multiple issues, some of which are not even reported yet, which was discouraged by the lack of activity in the repo. Providing reports and PRs would also not be a problem on our side.
  In the long term, it would be good to see efforts to reduce these small breaking changes. Perhaps it’s time to start introducing changes with stricter adherence to SemVer?

Generally, it would be good if the discussion on this topic could remain constructive. In other projects, unfortunately, the gatekeeping crowd sometimes shows up and starts giving speeches about "how OSS development works" and that "everything is fine".
To be clear: Nobody is demanding from the maintainer to immediately do all the work and handle all the issues and PRs. It is absolutely normal that at some point maintenance fatigue sets in, or life simply demands attention elsewhere.

That said, it would be really disheartening to see this project continue to go stale as it has over the course of 2025. Forks are usually not the best option, because of the community fragmentation and duplicated work. Having more maintainers or even turning this into a community project (random thought: maybe even .NET Foundation), would be much preferred.

[Baune8D]

We are in the same boat in my organisation. We currently rely on NUKE for a handful of our pipelines and are blocked by 2 things:

• We are still using NUKE v8 because of this critical bug: PowerShell tasks applies wrong argument order in Nuke v9 #1508 which was closed as completed 10 months ago but never released.
• Missing .slnx support.

Right now we are in internal discussions about moving away completely from NUKE because of the lack of activity and communication. Also the temporary archival that happened earlier this year without explanation made us really nervous about the future of the project.

I was the one that advocated the use of NUKE in our organisation, and we have been extremely happy up until now. Would really hope to see the project gain some longterm support and/or transparancy 🤞

[avidenic]

We have tried to contact Matthias via several channels, but were not successful. We would love if this project would continue, preferably as OSS as it fills a niche in the community and has a great foundations.

[BrewingCoder]

While we are actively using (and loving) Nuke on several of our projects we started a few years back we haven't experiencing some of the breaking changes and support for newer features that others have voiced. With that being said we are being asked to replace Nuke for the sole reason that, based on some scoring metric by management, the package is now considered "at risk" due to the fact that the repo is not being actively maintained.

[ocean-orrick]

I think Nuke would be a great candidate to be a Dot Net Foundation supported project

[ocean-orrick]

Oh didn't realize that, good to know. Given the radio silence from Matthias, I was thinking more along the lines of the community applying with a forked version anyway, but this would seem to confirm that that'd have to be the direction

[Droppers]

Finding the right maintainer for a fork is very difficult, I am pretty sure Nuke is mostly used in a commercial setting, and outside of that you will probably not use it much.

[Baune8D]

I use it for all my personal .NET projects and find it to be a huge improvement.

[candoumbe]

Finding the right maintainer for a fork is very difficult, I am pretty sure Nuke is mostly used in a commercial setting, and outside of that you will probably not use it much.

Same here, it's the build tool for all my personal projects and I was about to advocate for it inside my organization. I even started a project to further customize it using the component approach.
I still want it to be the default at my org (instead of plain YAML) but with the current state of the project, I don't know what to do.

[FlorianRappl]

I think Nuke would be a great candidate to be a Dot Net Foundation supported project

And what benefit would that give NUKE / you?

I am maintainer of some projects that are supported by the .NET Foundation. Honestly, besides a bit more PR coverage I could not tell you a single benefit from it. Luckily, there are no disadvantages either.

[BrewingCoder]

Before finding this thread; and doing some research to see if I could contact Matthias I ran across something he posted on LinkedIn about 9-10 months ago which was a link to an article about OSS which basically talked about OSS projects that get out hand for the owner (size, scope, burden, whatever) and the two choices being change the licensing model or just dropping it and letting it die on the vine:

This is the article he reposted:

https://www.linkedin.com/posts/aaronstannard_net-oss-projects-better-to-re-license-or-activity-7286449537521500161-vDV4

The timing on this is about the time this repo started to go stagnant

[SonnyRR]

This repository was marked as archived out-of-the blue sometime in May, but that was reverted after several weeks in mid-June. I wonder if at around that time Matthias considered to adopt a commercial model for NUKE, but saw the feedback from the licensing change announcement for AutoMapper & MediatR by Jimmy Boggard. There was (still is?) an enterprise access to a custom NuGet feed to re-use custom tailored components, but I suspect that the usage for that is low.

There was a similar thread in /r/dotnet, related to this decision: https://www.reddit.com/r/dotnet/comments/1l1noey/nukebuild_is_being_unarchived_in_1_week_thoughts/

I might have to move my pipelines to my local pastry shop.

[Droppers]

Communication may not have been the best in that situation. But it was communicated in the Nuke Discord that the archival was for personal reasons. So this is not the case and there is no reason to speculate.

[FlorianRappl]

The archive was temporary and it was announced like that. Likewise - and as promised - it was unarchived after a while. Should not read anything into that...

[jbogard]

Apropos of nothing, what I've learned from commercializing my popular projects is that:

• GitHub and Reddit commenters are not REMOTELY representative of the .NET ecosystem. The vast, vast majority of feedback I received was positive. When I realized and internalized this is when the anxiety attacks stopped.
• Everyone that I talked to that went a similar path of commercialization did not regret it. Except maybe one person/project (you can probably guess). I absolutely do not regret it either and I would have told Matthias the same. Successful OSS is commercial OSS. What exact form that takes, depends. What form it won't take, though, is GitHub Sponsors.

[patrickklaeren]

I sponsored Nuke for a little while - I was in conversation for getting my company sponsor the project as well, unfortunately this did not materialise due to the past year's activity on the repository.

I am incredibly unsure what to do with the projects using Nuke, because now there is no communication at all regarding any plan. Even if that communication were "I am no longer interested in maintaining the project."

A lot of confidence was knocked through a couple years worth of choices, and for me, personally, the current state of no communication whatsoever is likely the last time I will consider Nuke. It's a pity because it is a reliable tool and has served me so well over the years.

I have begun migrating to Cake and will ultimately deal with the frustrations of YAML.

All I would say, for any project maintainers, is that communication, even if it's "this project is now dead" is vital for letting dependents understand what they need to do. Otherwise, why build a tool for others to consume?

[FlorianRappl]

Besides @patrickklaeren who sponsored this project (from the people within this discussion)? And if sponsored - by how much (are we talking $5 per month, $50 per month or $500 per month)?

Just to be clear: It's not about the money, but using it in a commercial setup for free, then complaining is something I see a lot in the .NET space. It's just weird given that other ecosystems have a lot less commercial fire-power behind, but are the complete opposite.

From a company using it (and wanting to see the project actively maintained / moved forward) I'd expect O(100) USD per month. It's the least - I mean that would be somewhere between 1 to 8 hours of development (per month), which is like nothing (and usually a lot more hours will need to be invested). From a private person much less is expected. Here, it's the gesture that counts.

If people are wondering why OSS projects die - it's mostly because maintainers don't see the recognition that they deserve. Being in arguments and discussions (partially even personal attacks) about certain decisions in the project is not helpful. All those things will certainly add towards a mental blockade to contribute further. Therefore, there has to be a way to say "thank you" to the maintainers of a project, which is usually done by direct contributions, e.g., in form of PRs, or by sponsoring the project.

[patrickklaeren]

I'm not sure I have seen anyone attack anyone else.

Some people are not in the position to give back, others are. If the chief concern on the maintainer's part is monetary compensation, that should be communicated.

I have seen a lot of issues and pull requests where people do seem to want to offer their time/energy/resources, but they're now at an impasse because the maintainer(s) have not communicated any plans.

If people are wondering why OSS projects die - it's mostly because maintainers don't see the recognition that they deserve

I'm not sure this is necessarily the case. Recognition is there. I think you can scan the various social channels and see that, from in person talks to online.

With the scope and reach of Nuke, there are certain responsibilities that are suddenly acquired - no different than any tool that goes into use in the real world, but it is always important to communicate. Whether that be "use this tool, but I don't expect to update it" or "I want to do it my way". This does not require eight hours in a day.

[Perksey]

There’s a lot of this that comes down to the fact that this is effectively a one person project. It could be argued that this is a failing to bring on new maintainers, or a failing on the community for no one stepping up. However, everyone here chose to rely on this project, and a very small number of the parties involved did anything to mitigate this supply chain risk. If you’re taking on a dependency on a project like that, this sort of thing should be expected, because ultimately one person cannot be expected to dedicate as much life as this sort of project requires forever with little benefit. In fact, threads like this just drive the knife in further, because not only are you writing code with no material gain, you’re also never getting any positivity from the community back - that’s just a terrible situation all around that any reasonable person would walk away from. Yes I hear everyone’s point about “if it’s dead can you just say that,” but even the reaction to the explicitly temporary archiving a while back (it was clearly communicated that the project was not dead) resulted in similar dramatics to those found in this thread, so I can see how even just communicating with the userbase could be seen as a chore at best.

Ultimately as an open-source consumer you’re entitled to nothing. Even if you’re donating a cup of coffee’s amount per month, that’s not an automatic entitlement - there’s no support contract in place (though I can see how one would be peeved). Open-source sustainability is a game that not many people have figured out, and one that the C# community especially seems to reject any attempt at (e.g. ImageSharp). So why would you bother?

I hope these factors form part of your supply chain risk assessments in the future.

[patrickklaeren]

I'm not sure anyone particularly has an issue or is attacking - it's the supply chain risk that people are trying to assess by asking the question of "what is going to happen?", which I don't think is unreasonable if you're building a tool you want others to use in the first place.

Operating on assumptions (as already apparent in previous comments) is dangerous.

I think there's a fundamental misunderstand that people are out to be angry or demand "blood", whereas people are unsure how to reach out or offer support if it's required or desired, which is impossible to ascertain without any kind of response from maintainer(s).

[Perksey]

I don't think anyone in here is angry, this is one of the more tame threads of this class, and I commend everyone involved for not letting it devolve into the comments that I'm sure the other forums (Reddit) will undoubtedly come up with in response to this thread.

Ultimately I can't speak for Mat's intentions, it could well be that he actually doesn't want this project to be used because of it possibly growing past the point of manageability, I genuinely don't know. My point in my reply is more to illustrate that the issue at hand isn't a transactional or financial one, simply just a human one. The suggestions in the original post are quite constructive, but my point is that there shouldn't be an expectation that they'll be actioned, or that any comms will come out at all - the flow of time and energy that an individual maintainer can dedicate to this sort of thing very easily runs dry. Again, assess the supply chain risk accordingly.

[macsux]

There’s a lot of this that comes down to the fact that this is effectively a one person project. It could be argued that this is a failing to bring on new maintainers, or a failing on the community for no one stepping up. However, everyone here chose to rely on this project, and a very small number of the parties involved did anything to mitigate this supply chain risk. If you’re taking on a dependency on a project like that, this sort of thing should be expected, because ultimately one person cannot be expected to dedicate as much life as this sort of project requires forever with little benefit. In fact, threads like this just drive the knife in further, because not only are you writing code with no material gain, you’re also never getting any positivity from the community back - that’s just a terrible situation all around that any reasonable person would walk away from. Yes I hear everyone’s point about “if it’s dead can you just say that,” but even the reaction to the explicitly temporary archiving a while back (it was clearly communicated that the project was not dead) resulted in similar dramatics to those found in this thread, so I can see how even just communicating with the userbase could be seen as a chore at best.

As someone who has previously tried to be heavily involved in the project I found it incredibly frustrating because the decision making process on what went into the project took no consideration on how people actually wanted to use it. Much of the code was deliberately made "internal" to encourage people to contribute to the main source code vs adding in private extension points and never sharing, yet PRs constantly got rejected as not aligning with "vision" or not having broad enough appeal This put us in a bind unable to effectively add code to the main stream when we wanted to nor extend it because things were deliberately made non extensible for no good technical reason. Code that has been merged previously that we were relying on got ripped out without any communication under justification that it was too "niche". Attempts to obtain a commercial license or support were also rejected under justification that it would open up to liability. PRs sit indefinitely without review. Unfortunately the founder's insistence on retaining control while at the same time unwilling to spend the time maintaining it seems like the death knell of the project until someone decides to fork it and take over and put in the time to migrate the community there.

[matkoch]

Hi everyone.

It’s sad news for those in the community who have been responsible OSS citizens, some of whom I consider close friends and trusted peers, but my inactivity here is the direct result of the well-known OSS sustainability problem. There are enough talks, discussions, and posts about it, so it makes no sense for me to rehash them here. However, the final straw was when some individuals chose to attack and accuse me during my most vulnerable times. The overall experience has shifted to a net negative, making further dedication difficult to justify, regardless of how many may feel quietly appreciative. I hope we can accept this reality and value the more active years of the project.

Going forward, I will attempt to handle a few requests that align with people, companies, and fellow projects I’m connected with (contact me on Slack/Discord). A few folks offered help in recent months, but unfortunately, it was already too late to devote more time or establish onboarding with uncertain outcomes. For security and reputational reasons, I do not intend to transfer the repository to a successor maintainer. The community is free to fork it under their own name and on their own schedule.

Though uneasy about the community’s response – as most maintainers when they make uncomfortable decisions – I feel largely resolved about the situation. I still enjoy experimenting with build-automation ideas privately. The C# and .NET landscape has evolved considerably, so I'm not ruling out the possibility of a spin-off that takes advantage of it and provides a level of compatibility. Let me know on Slack or Discord if you'd like to be part in shaping or using this. Understandably, some may interpret this as a matter of reliability, but considering the sentiments expressed in this discussion — "we are loving it," "it is a reliable tool," "extremely happy up until now" — maybe it’s worth reevaluating what becomes possible under a sustainable model that preserves the motivation needed to challenge the status quo.

—Matt

[sirredbeard]

If you are interested, my company has an Open Source Sustainability Fund. We have $20 million USD set aside to fund open source infrastructure tools. I strongly encourage you to apply, I would very much like to see more .NET ecosystem tools/libraries in the fund.

[michalsteyn]

Hi @matkoch,

Could you help us to understand a little more explicitly what you are telling us. Is this effectively a notification that Nuke will be discontinued? Are you recommending we migrate back to Cake? Our enterprise is also actively in the process of migrating from Cake to Nuke, so this is incredibly sad news.

"For security and reputational reasons, I do not intend to transfer the repository to a successor maintainer." - Seems like it would be a huge badge of honor for your reputation?

There may be a real opportunity to bring new life to Nuke if it was donated to .Net Foundation. But I think that would require the original author, not a fork.

"The C# and .NET landscape has evolved considerably, so I'm not ruling out the possibility of a spin-off that takes advantage of it and provides a level of compatibility." Are you suggesting here to start something else in stead of Nuke?

[FlorianRappl]

There may be a real opportunity to bring new life to Nuke if it was donated to .Net Foundation.

Can you elaborate?