The Rules for Software Alternatives

2025/06/25



A set of rules/guidelines for people trying to develop alternatives to software, written from the perspective of a programmer and of someone who actually uses many of these alternatives.

1. Make it comprehensive.


If I'm going to switch platforms, I don't want to lose my favourite feature. If it's integral to the user experience, or even just a slight QOL thing, keep it.

2. Make it backwards-compatible.


There's a limit to what you can do here, but many users like to use scripts and other features. Make the APIs similar, and try to use the same language (If Program A uses Lua, yours should use it too. Doesn't matter if Javascript is easier to implement.)

3. Make it concise.


Keep all of the features that are people's favourites (see rule #1), but cut out all of the things people don't like. Remove the generative AI and the Web3 if it's not why people use the app. If people are leaving because of it, don't have it. This rule also has a second meaning: if your alternative is too complex, people won't use it.

4. Make it familiar.


Keep the same general layout. You're convincing people to switch what could be something they use daily. If it's too different, they won't use it.

5. Make it better.


It's one thing to be the best alternative, but where you really win is being the best thing. Don't just clone it, add your own take. For example, if you're making an alternative to Twitter (X), add something. Maybe make it decentralized like Mastodon. (Or be Bluesky and pretend to make it decentralized. Whatever floats your boat.)

6. Don't be evil.


If I'm trying to get away from (for example) Discord, I'm not switching to a platform owned by Roblox. Specifically, open source your code, respect people's privacy, listen to your users, and avoid cramming monetization down their throat. (See FUTO's section On Ethical Capitalism)


Return Back
 Home  Github  Mastodon 󰛮 E-Mail