-
|
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:
We see the following options:
|
Beta Was this translation helpful? Give feedback.
Replies: 13 comments 52 replies
-
|
Thanks for bringing this up, we are facing exactly the same challenges.
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". 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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
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 🤞 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I think Nuke would be a great candidate to be a Dot Net Foundation supported project |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I use it for all my personal .NET projects and find it to be a huge improvement. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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: The timing on this is about the time this repo started to go stagnant |
Beta Was this translation helpful? Give feedback.
-
|
This repository was marked as There was a similar thread in I might have to move my pipelines to my local pastry shop. |
Beta Was this translation helpful? Give feedback.
-
|
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... |
Beta Was this translation helpful? Give feedback.
-
|
Apropos of nothing, what I've learned from commercializing my popular projects is that:
|
Beta Was this translation helpful? Give feedback.
-
|
@jbogard thoughts on OSMF? |
Beta Was this translation helpful? Give feedback.
-
|
OSMF for me means "Old Settler's Music Festival", a very chill music festival here in Austin TX. My thoughts are I'd love to go again! |
Beta Was this translation helpful? Give feedback.
-
|
In my company it is hard to get buy-in to spend money on sponsorship (viewed as optional), but getting money for a (not "call us" priced) commercial license is comparatively easy. Maybe that is a common scenario? Also wanted to say thank you for all your hard work @matkoch it is much appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
Generally, either:
In neither of those cases does the maintainer gain any value (emotional or financial) from having "dependents" or having people "consume" their work. In 1, it's very unlikely that reviewing issues, spending time reviewing MRs, onboarding other maintainers, etc counts as fun. Why is it vital for some in either of those two scenarios to do anything for dependents? Aside, you might think there is a third, "People build things as a self-employed venture in order to turn it into 2". But until they have enough income to do it full time, it's 1, not 2. And seeing as I can count on one hand the cases where 3 becomes 2, it's pretty odd to suggest that any contributions below thousands of dollars per months count for much. If someone isn't earning enough to do full-time, they can't provide proper support. |
Beta Was this translation helpful? Give feedback.
-
|
I think this oversimplifies the reality of maintainership and a tool you actively want to give to other people. There are public talks, videos promoting, sponsorships from big companies. Communication is not the same as support. A maintainer saying "this project is no longer maintained," or "I’m stepping back," or "I don’t know when I'll return to it" doesn’t require issue triage, PR reviews, or onboarding new maintainers. It's a single act of transparency that prevents users from being left in limbo. Yes, many projects start as someone's hobby or internal tool - but, and it's a big but: once a project is deliberately published, documented, promoted, and positioned as a solution for others to adopt, the dynamic changes. No one is asking for round-the-clock support or free labour. What users do reasonably expect is clarity, especially when the project reaches a level of adoption where its absence can block teams, CI pipelines, or release processes. It's horrific hearing that there have been personal attacks. I have not seen that and cannot begin to imagine what actually goes on in those situations, mentally or physically. No one deserves that, and it should never be part of open-source work. Disagreement about project direction is one thing; targeting the person behind the project is completely unacceptable. |
Beta Was this translation helpful? Give feedback.
-
|
"and it's a big but: once a project is deliberately published, documented, promoted, and positioned as a solution for others to adopt, the dynamic changes" -- No, it doesn't IMHO. The author owes you nothing. The code is a gift. It isn't a new problem, long ago I remember people who gave away public domain software that ended up on Fred Fish disks would get letters/calls demanding help. No good deed goes unpunished. |
Beta Was this translation helpful? Give feedback.
-
This is where you say "Sorry, not providing help." If you're publishing something online, with the intent to get people to use it, that is the situation created. |
Beta Was this translation helpful? Give feedback.
-
|
Not everyone views open-source as that transactional. Large open-source projects such as this one are born from passion, maintained from achievement, and die from exhaustion - these are all inherently emotional things and are quite hard to mentally simplify to "I'm giving you X, as a result you are only entitled to X". The open-source projects that are made with the explicit expectation of mass adoption are the exception, not the rule. Most of the time it's just sharing a cool thing you've made, then growing far beyond that original intention before you even clock how unsustainable being driven by that passion is. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
While I thought this was headed in a different direction it seems like you really are done with this and you're just doing a last update for a few items. Unfortunately, we won't end up taking it, because changing the targeting so that Nuke requires .NET 10 requires a non-trivial amount of work to update everything in our build infrastructure to use .NET 10 just so we can use a tool that is dead after this. Hopefully people realize the value in something like this and a well maintained fork can result. I wish you well @matkoch and I thank you for your work on this project. |
Beta Was this translation helpful? Give feedback.
-
|
@Rhialto74 somehow this comes out as you wishing someone doing some free work for you maintaining a fork (instead of Matt). If you see a separate line/branch valuable, maybe you should maintain one? If you have chosen to use modern NET, NET 10 is inevitable. |
Beta Was this translation helpful? Give feedback.
-
|
@lahma you and I and everyone else here that used this tool used it because it made our lives easier and we either didn't have the ability and insight to create it (I count myself there) or we didn't have the time to create it. We all knew we were using a tool where we weren't contributing at all since it was a single maintainer, so don't pretend I'm the selfish one here for wishing this project could continue without my direct intervention. That said, I wouldn't be averse to contributing to a project like this if I felt I had something worthwhile to add. |
Beta Was this translation helpful? Give feedback.
-
|
Hey Matt, Just want to send you kudos and appreciation. We've met in one of the conferences in Oslo or Sweden (still got your stickers around), I dont even recall at this point what country it was. I've been using Nuke for last 5ish or so years with great success and have adopted it greatly. I dont know what future for it holds, and it doesn't matter, just wanted to say I appreciate all the work you've done on it throughout the years, and whatever you'll decide, we as community (I am speaking for myself a lot here) will support it. Mental health is important and if this takes a toll to a net negative, please look after yourself. You are a great guy, and you made a great project. I hope it continues on going, if not, it was a great journey and we'll adapt, that's what we do best. |
Beta Was this translation helpful? Give feedback.
-
I already offered helping with the slnx Support. Let me know if I can step in and help. |
Beta Was this translation helpful? Give feedback.
-
|
Let's crowdfund all opensource .NET project that we want to see live. Commit to a monthly amount and give. @matkoch what you are doing with this project is simply amazing. I don't use it but I know what open source has enabled me to do and achieve. Stars are not enough, talking about this isn't enough. Let's all give a little something every month and encourage everyone working on opensource .NET and any open source projects you are benefitting from. |
Beta Was this translation helpful? Give feedback.
-
|
I’ve been following this thread because many of the concerns people have brought up resonate with what I’ve experienced as well: long-term maintenance, keeping up with newer .NET tooling, and the risk of depending on a project maintained by a single person. For what it’s worth, I’ve been working on a build and automation tool called Moonlit. It started as a .NET-based engine, but we are currently moving it to Rust to get better performance, easier cross-platform distribution, and a more stable long-term foundation. One of the design goals is to avoid vendor lock-in and allow users to write plugins in multiple languages. Right now C# is supported, and we’re actively working on Rust, TypeScript, and WebAssembly plugins as well. The scope is not identical to NUKE, and Moonlit is still a work in progress, but the motivation overlaps with what many here are expressing: a modern, extensible, actively maintained build system with clear long-term direction. If anyone is exploring alternatives or wants to follow the progress, I’m happy to share more details. This isn’t meant as a pitch or to pull people away from NUKE. The project has been incredibly influential. I just wanted to offer another option given the concerns raised here. |
Beta Was this translation helpful? Give feedback.
and others
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.
…