You know we have Amber, Citrine, Pokey and Zap.Store
But our goal is to have 10 Ambers, 10 Citrines, 10 Pokeys and 10 Zap.Store apps.
You know we have Amber, Citrine, Pokey and Zap.Store
But our goal is to have 10 Ambers, 10 Citrines, 10 Pokeys and 10 Zap.Store apps.
BRB forking and renaming.
Having a variety of options with different takes and implementations fuels a vibrant ecosystem.
A few thoughts here:
While having more options is good, it can also increase the amount of time it will take to onboard. Take Hick's law: "...the time it takes for a person to make a decision as a result of the possible choices: increasing the number of choices will increase the decision time logarithmically. "
Furthermore, similar to microservice vs monolithic server architectures, debugging can become quite complex as the number of interconnected services increases. There can be a gain in modularity, however there is a tradeoff. Take the Linux kernel compared to something like GNU Hurd.
Got one Amber-like thing design wise (not done / not sure when it'd be done, since it's aiming to be expand on Amber currently does. Looking forward to sharing it when design ready =3)
Bring it on
The success of open source is in how many times they are forked .. cuz each fork is a paying customer - either in #sats or in recognition!