Squirrel.Windows - Reboot Proposal

[shiftkey]

I wanted to provide an update to this situation that will hopefully address some concerns.

First off, many thanks to @anaisbetts for her hard work over the years on creating and maintaining Squirrel.Windows. As issues like #1466 and #1469 show, there’s a lot of love for the project and a lot of interest in keeping this going.

For those who don’t know me, I work at GitHub and have been around since the early days of Squirrel.Windows. I’m not an active contributor, but I’m a happy user of it due to its adoption in the Electron ecosystem and want to see it continue.

I had a chat with @robmen yesterday about how we might be able to help keep things going, and we agreed upon some short-term goals. These goals are rather modest, but they feel achievable over the coming weeks and months:

• Review the outstanding open issues and get the issue tracker into a state that reflects the current situation
• Hold a regular fortnightly meeting to discuss the project with contributors and users
• Investigate whether there is some low-hanging fruit that can be worked on
• Get the project to a place where we could potentially ship an update

We’re only two people with plenty of other things on our plate currently, so we’re looking for others to help with this work to build a more vibrant community around the project.

If this sounds like something you’d like to get involved with, please comment in this thread so we can gauge the interest.

If you have any questions, feel free to comment here - or you can reach out privately to shiftkey@github.com if you don’t feel comfortable asking here.

[patrickklaeren]

I was saddened to see Squirrel.Windows be deprecated - just last month we managed to migrate most of our work apps to use Squirrel after having started using it late 2018. We've had a good experience. Upon the announcement me and a friend embarked on building a "spiritual-successor", if you will, that caters for our needs, both in "enterprise" and for personal applications.

I'm glad to see Squirrel.Windows still has life left and would love to contribute where possible if you elaborate what help you're after.

[shiftkey]

I'm glad to see Squirrel.Windows still has life left and would love to contribute where possible if you elaborate what help you're after.

The first thing that comes to mind is taking stock of the issue tracker. If anyone is able to spare some time, I'd love help with reviewing the open issues and seeing what we can close out.

Things to look out for in open issues, and my suggested action:

• Has the issue been resolved?
  • Helpful: Comment in the issue that you think this can be closed and mention me
• Is the issue not clear? Is something missing that you think would help out?
  • Helpful: Ask a question that would help with understanding the problem and ensure that you @-mention the submitter so they're aware of it
• Is this an old problem or a problem with an old version of the library?
  • Helpful: Ask the submitter if they are still able to reproduce the issue with the latest version of the library.
• Is the issue asking a general question something the maintainers cannot really help with?
  • Helpful: Ask the submitter if they are fine to close out the issue, and ensure that you @-mention the submitter so they're aware of it

I can come through and help with sorting/closing issues, but having many eyes scanning over the open issues here would be a great help to get things moving...

[anaisbetts]

I'm glad to see that some folx found Squirrel so useful that they want to revive it :) I wanted to take a moment and share A few Guiding Principles that have served Squirrel.Windows well over the years.

• Be as Dumb As Possible - since the beginning, Squirrel.Windows has always tried to do literally the simplest, least clever thing that could possibly work. Simple things are great, because it means that people can build their own more complicated / niche things on top of it that only make sense for their scenario. Let Developers who Use Squirrel be the clever ones.
  
  Another extremely good reason to avoid complexity is, reliably installing and updating software on Windows is already walking a tightrope on a windy day while people throw tomatoes at you, complexity will end up creating more failed updates and users getting left behind. Which leads me to....

• Be extremely Conservative - Squirrel.Windows routinely turns down features, moreso than other projects that I've maintained, because breaking the updater is Catastrophic. Slack broke the Mac updater shortly before moving to the Electron-based version of the app, and it took them years to remediate this mistake, it sucks really bad. Anything that touches the core path of updating the app should start off in your head with -5 votes. It sucks to turn people down, especially when they've already put in some work for their idea, but complexity adds up, and every feature you add will make it harder to feel confident that you haven't broken the updater.

• Stick to The Principles and Say No - If you buy Fix the folder layout so we can have more than one project under src #2 above, you're already sold on this, but for this project in particular, it is so important to Say No. People want Squirrel.Windows to be a lot of different things, and Squirrel.Windows has stayed a reliable product because it is willing to tell people, "We just don't solve that problem. Sorry." Ideas like making Squirrel an NT Service to do updating would definitely mean it would apply to more scenarios, but it would also make Squirrel much much more complicated and prone to leaving users stranded.

• Focus on the User Experience - Another reason to Say No is because Squirrel.Windows has drawn a very strong Line In The Sand around user experience. The goal of an installer is, from the second the user double-clicks Setup.exe, we want to get the App in front of them, as fast as possible, and do nothing else. When the user uninstalls? Our goal is to remove ourselves, as fast as possible - that's it!
  
  And in terms of updating, our goal is to be like Chrome - you open it and it's the latest version. No prompts, no UAC dialogs, no Wizards or Progress Bars. Every time we show an update progress bar, we say to the user, "What you're doing isn't important. Look at Me instead". Any feature that tries to do this should be met with "That's Not What We Do Here"

Hope that helps explain some of the Zen of Squirrel.Windows. Excited to see what folx come up with in the future!

[peters]

Thanks for all the hard work you put into this project @anaisbetts 🎉

Yes, thank you for your work, @anaisbetts, and the best of luck on your journey!

And thank you for taking control, @shiftkey. What a relief 😄

[TonyValenti]

Hi All,
I just saw that aparently squirrel is deprecated? If so, was there an announcement?

I'm very interested in keeping the project alive and well, especially with .NET Core 3.0 coming out soon, however, a lot of the way that code was written makes me feel fairly uncomfortable. I'm more on board with a rewrite over maintenance. Thoughts?

[shiftkey]

@TonyValenti

especially with .NET Core 3.0 coming out soon,

This is an interesting potential audience, and I'd love to hear more thoughts about this and how Squirrel.Windows might affect them.

however, a lot of the way that code was written makes me feel fairly uncomfortable.

Can you elaborate on this? I'd love to understand these concerns and how we can mitigate them.

I'm more on board with a rewrite over maintenance. Thoughts?

There is a lot of existing usage of Squirrel.Windows in the wild currently, and I'm very reluctant to contemplate rewriting things (and introducing breaking changes and potentially breaking these users) without more explicit goals and a plan to go about it.

[TonyValenti]

@shiftkey -

1. With .NET core 3.0, desktop apps are now a supported scenario and I think that Squirrel.Windows makes a ton of sense for it. If you deploy a desktop app, you're going to want a way to update it. Also, I believe that the self-contained nature of .NET core is great for Squirrel.

2. Here's a really good example. Take a look at :
   https://github.com/Squirrel/Squirrel.Windows/blob/master/src/Squirrel/Utility.cs

There is a ton of code in there that isn't documented and should really be broken out into multiple classes. Additionally, you'll see things like Tuple returns and methods like this which make me shudder:

  public static Task ForEachAsync<T>(this IEnumerable<T> source, Func<T, Task> body, int degreeOfParallelism = 4)
        {
            return Task.WhenAll(
                from partition in Partitioner.Create(source).GetPartitions(degreeOfParallelism)
                select Task.Run(async () => {
                    using (partition)
                        while (partition.MoveNext())
                            await body(partition.Current);
                }));
        }

When I look at the code in general, it works but it needs some good love to start looking maintainable.

[robmen]

Yeah, we can definitely improve Squirrel.Windows but we don't need to start with a "rewrite". Small, iterative steps that bring along everyone to a better and better experience will work out well. A big bang rewrite would require significant backwards compatiblity verification and not allow us to see improvement along the way.

[aaronstine]

Hey guys, my company (Identifi) recently adopted squirrel and wouldn't mind investing in its future. Our current product plan keeps our devs busy for the next few months. But after that, we could free up some folks to contribute.