Skip to content
This repository has been archived by the owner on Jan 24, 2021. It is now read-only.

Nancy is not being maintained. Close the project down and communicate it to the community. #3010

Open
damianh opened this issue Mar 14, 2020 · 28 comments

Comments

@damianh
Copy link
Member

damianh commented Mar 14, 2020

She's dead Jim.

Nancy was one of the leading projects with respect to her interactions and communications with the community. We owe it to them to communicate the current status clearly.

We need to:

  • communicate that it is not being maintained (and won't ever be) by updating the readme in all the projects (and with a big "Thank You" too).
  • closing all open issues & PRs
  • archiving repositories making them readonly
  • announce on twitter (with a big Thank You).
  • close the slack org

We should not seek new maintainers due to security and trust implications. Instead we can link to (but not endorse) any independent forks or alternatives (i.e. Carter).

Personal note: am very thankful for my journey with this project and the friends that I have made along the way ❤️

@danielmarbach
Copy link

Dear Nancy, you did serve us well. with love, daniel

@cocowalla
Copy link

I've been building web apps with Nancy for years, and I'm genuinely sad to see this after it kept me on the super duper happy path for so long.

In years past, ASP.NET just wasn't extensible enough to support a lot of scenarios elegantly, but Nancy was unopinionated and had an extensibility point for every occasion. Now, ASP.NET Core takes extensibility seriously (the fact Carter even exists is testament to that), and is finally in great shape - this has undoubtedly played a large part in the decline in popularity (and maintenance) of Nancy, but ASP.NET Core also undoubtedly took some inspiration from Nancy.

Nancy has been a prominent and much loved library for something like a decade, but I'm glad the maintainers are at least finally coming out and saying something to end the uncertainty.

Thanks Nancy, it's been great ❤️

@daveaglick
Copy link
Contributor

E37B40AC-65B6-40D6-A3BC-C2E702C82E43

@DenisBalan
Copy link

Nancy was really a "feature-traveler" in time, being beyond ASP.NET, but now Core superseded almost all features 😐

@SeanKilleen
Copy link

This was a fantastic project, and I hope that everyone involved is really proud of what you did here. ❤️👍

@davidfowl
Copy link

Nancy has been one the most influential frameworks in the .NET ecosystem. It was also one of the first frameworks (AFAIK) that worked well and was tested on Mono!

I always enjoyed working with @grumpydev and @thecodejunkie throughout the years. The OWIN days were some of my fondest memories of the involvement and influence of this project. Ideas from Nancy have influenced lots of the design decisions that went into OWIN itself and also ASP.NET Core (especially frameworks like Carter)

I want to thank all of the contributors over are the years of contribution to the .NET ecosystem and I hope to you stay engaged as we move forward with .NET Core!

@jeffdoolittle
Copy link
Contributor

jeffdoolittle commented Mar 15, 2020

I learned so much about open source, web development, and clean coding practices by participating in this project. I got to collaborate with some great people as well! Sad to see it come to an end, but I'm so grateful I got to be part of it. I'll keep rockin' my NancyFX shirt like a boss!

@jonorossi
Copy link
Contributor

Thank you to all contributors, but especially the small core team, I've really enjoyed (and still do) using Nancy. As a fellow maintainer I really do appreciate it and know just how much work has been put into this project.

Being involved with Castle MonoRail over a decade ago when everyone was doing WebForms, I think Nancy is another defining period in the .NET web development timeline, the evolution of tools where great ideas make their way through to the masses and everyone is the better for each incremental improvement. I'm glad that ASP.NET Core improves on Nancy in many ways and that as a community we can all contribute to it.

@glennblock
Copy link

glennblock commented Mar 15, 2020

An excellent project that challenged .NET bringing Sinatra ideas from Ruby. I will never forget when I was a PM on Web API and Andreas sent me a code sample showing the first Nancy spike. It really pushed the bounds of a declarative and terse-style. When it first came on the scene a lot of folks dismissed it, but @thecodejunkie @grumpydev etc knew they were onto something and so they kept driving forward. From the get-go it was an open and welcoming project which spurred on a vibrant set of contributors and a healthy community of adopters. It was really amazing to watch its growth over the years. Congratulations, long live Nancy!

@JTrotta
Copy link

JTrotta commented Mar 15, 2020

@nancy Goodbye!
You was simply great!

@chrissie1
Copy link

It even worked with VB.Net, snif, snif. At least I still have Carter.

@NateKomodo
Copy link

Can ASP.NET be used in a similar way to nancy self-hosting? I've seen OWIN is a thing but it looks more cumbersome compared to nancy

@nancy
Copy link

nancy commented Mar 19, 2020

Hi there! I see you guys have been tagging me, a real person, on accident. :)
(Sorry to see your Nancy go.)

@serialseb
Copy link

Thoughts and prayers.

@nkosi23
Copy link

nkosi23 commented Mar 30, 2020

Just to add a different voice: as far as we are concerned we do not plan to migrate away from Nancy and are still using it for new projects and plan to do so for the foreseeable future. We run it under mono and may migrate to .NET Core within 5 to 10 years if we really have to.

As far as Nancy is concerned, the last commit was in September 2019, I personally do not see what's wrong with a project being updated as little as once or twice every year. I wanted to point that there are people like us who are not seeking to be on the cutting edge every time. If we have a way of doing things that works, we carry on with it.

I feel it may be a little harsh to request a shutdown of the project, and I do not feel it is necessary. Even if issues and features are fixed and added slowly for a couple of years, why not just let the project move at its pace.

@jonorossi
Copy link
Contributor

@nkosi23 I can't speak for the maintainers but the last release was in July 2018 and my guess is that they no longer have time to contribute to the project. I do agree it would be much easier to make fixes over the next few years with a single codebase rather than maintaining my own fork.

We should not seek new maintainers due to security and trust implications. Instead we can link to (but not endorse) any independent forks or alternatives (i.e. Carter).

@damianh rather than shut the project down, would you consider new maintainers under any specific conditions? e.g. evidence of proven OSS contributions. I have personal and client projects using Nancy and know of a few defects already I was planning to fix, so they'll just have to go into a personal fork to be able to maintain projects using Nancy for the medium term until/if migration happens.

@adamralph
Copy link
Contributor

I feel it may be a little harsh to request a shutdown of the project...

It's more a case of embracing the reality. The project is already shutdown. It's just that the repo doesn't reflect that, and sends the incorrect message to people. And that can easily result in people wasting their time.

@nkosi23
Copy link

nkosi23 commented Mar 30, 2020

I feel it may be a little harsh to request a shutdown of the project...

It's more a case of embracing the reality. The project is already shutdown. It's just that the repo doesn't reflect that, and sends the incorrect message to people. And that can easily result in people wasting their time.

I understand your feeling but I feel there is another way to address this kind of situations. For example, if I had your concern, I would have suggested: since the pace of merges and updates is currently slow, could we commit to a release schedule (and/or pull request review frequency) and highlight it on the Readme to set expectations. Even something as slow as "about 2 pull requests are reviewed for merging every year" would make it until contributions pick up again. This is the kind of solution I would have suggested if I had your concern, not a shutdown.

I really do not think it is necessary to make it an all or nothing situation. I personally do not even feel there is something wrong right now. Not every project needs to be updated every week. Some projects have been developed for 20 years and continue to be, and stalled for a couple of months or years here and there during the journey.

As far as not reviewed pull requests are concerned, there is definitely value in having people post their patches in a single place, if people really need it and the need is deep, someone in need is able to pull it easily.

@snavarropino
Copy link

Hi everyone, please don't forget that we can fork the repo in case we would like to go on with the development

@adamralph
Copy link
Contributor

@nkosi23 the maintainers have abandoned the project, and the chances that anything is going to happen are vanishingly small. Setting any other expectation is likely to be misleading.

Hi everyone, please don't forget that we can fork the repo in case we would like to go on with the development

Indeed. I suggest pursuing this course of action if anyone wants something to happen here.

@damianh
Copy link
Member Author

damianh commented Mar 30, 2020

rather than shut the project down, would you consider new maintainers under any specific conditions? e.g. evidence of proven OSS contributions.

As mentioned in the opening comment, the team are not at all comfortable with handing over the project to anyone due to the security implications.

The project's source code is available under a permissable licence. Anyone wishing to launch and maintain a fork are not restricted from doing so.

That being said, @jchannon and I have been discussing the possibility of offering commercial support options. We realize that there may be existing applications
in production that will continue to require support. If you are in that situation and would like to discuss options, please reach out to us at nancyfx.help@gmail.com.

Thank you.

@thecodejunkie
Copy link
Member

Just to add what @damianh said

If anyone wishes to fork (please do) the codebase, then please understand that you should not be putting our nuget packages or binaries using the Nancy name. Doing so would likely cause some confusion about the origin of the new version and perhaps also cause some implicit trust believing they originated from the team.

Also, while the source code has always been MIT, the name and logo have not. These have never been part of the public domain. We have no intention of changing this for several reasons, which aren't really important in the whole fork-and-evolve discussion 😄

@jonorossi
Copy link
Contributor

Thanks @damianh and @thecodejunkie for the clarification, the opening comment had "We should not seek new maintainers", so wasn't as explicit as we will not accept new maintainers.

I knew about the logo, I remember reading the Nancy portfolio guidelines when we created a new Castle logo around the same time Nancy was kicking off.

Thanks again

@Loongle
Copy link

Loongle commented Apr 21, 2020

It's like a whale sinking into the ocean,

@zwcloud
Copy link

zwcloud commented Apr 21, 2020

That's really a pity.
Consider creating a guide on how to convert a NancyFx project to a ASP.NET app?

@chanibal
Copy link

chanibal commented Apr 23, 2020

I used Nancy as a simple way to add a web api to standalone console or desktop projects - which direction should I migrate to? AspNetCore doesn't seem like a good one because of added complexity and writing a HTTP server myself seems like overkill.

I would like a small, opinionated, fairly modern framework that does just the basics. Linux support required.

@jchannon
Copy link
Member

@chanibal does Carter fit your needs?

@chanibal
Copy link

chanibal commented Apr 23, 2020

@jchannon, never seen it before today. Looks ok, but isn't it just a wrapper around AspNetCore?

I'm leaning more towards embedio, but haven't researched it well yet.

Edit: maybe kestrel would be enough?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests