Good point @bold_omi.

I was playing with Linux back in the kernel 2.0 days. The tech was mostly ready for us geeks, but not for everyone else. Switching meant new habits, and “it’s free and open” was never a strong enough reason for most people.

People use big tech products for convenience: already installed, works out of the box, compatible with everything their friends use. Microsoft knew that playbook very well.

No matter how much we argue and explain, if it isn’t more convenient, most people won’t switch.

The silver lining: building small alternatives has never been cheaper

I see a lot of useful replies here.

I prefer to answer to 4 simple questions, helps me have a clear idea without overcomplicating:

• What success looks like. Be concrete: “in a year I want X”. If you can’t say it, probably it’s not the right time for the decision.
• The risks. What could go wrong, and how bad would it be? Money, time, people affected.
• The known issues. The problems you can already see today and are choosing to accept.
• The way back. If it goes wrong, how do I undo it, what would it cost, and when will I check? Put a date on it, like “in 3 months I review this”.

The fourth point helps you to determine how “big” the decision is. If it’s easy to reverse, decide fast. If it isn’t, slow down, sleep on it, and talk to someone who has already done it.

I get the appeal of a self-hosted tool, but my suggestion is to do the important ones in person.

When I ran a Linux group years ago, the decisions that mattered were settled around a table. For a big decision, the dialogue and the discussion that lead to a common agreement are the real work, and in my experience no software does that part for you.

For small stuff, a simple poll (or no poll at all) is fine: the core team decides and shares it as information. Save people’s attention for the decisions that need it.