There’s value in both approaches. The former as you stated, but it also helps to get feedback early to see if you’re even going in the right direction. I personally prefer to see something shipped fast because it forces founders to be honest with people and gets them sobering feedback quickly.
As a kid, one of the things I hated most was seeing people release half-completed projects. They generate all of this hype and momentum, get people interested, and deliver something that's barely usable. Just like the ICO hype of 2018! Whereas, the best games that blew people's minds were masterpieces upon launch — like Halo 3.
That’s the philosophy we're taking with #GitNestr. It will be a working product at launch, and we'll work through the kinks as we go, but it's not going to be an empty shell or barely a product. It'll have a real release date and near-complete functionality at launch — that's why it's taking so long.
nostr:npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:note1csnqtjcxvhh556rjc2p5cyfle2krjrxuq4nu20urf2ym2n00tl3s0epspw
Discussion
Democracy doesn’t determine quality, principles do. I’m confident our principles are sound & in alignment with trust-minimized/cypherpunk ideals. You can be the judge of that when it’s launches. 🚀
That works when you have your funding secured but with a bounty I feel like several teams might be flying blind.
Wouldn't it be sad to have some 8 projects work behind closed doors for years when one of them decides to release to claim the bounty. Now the other 7 rush to get in line with whatever they have to offer as there is no deadline to the bounty, so as soon as any project looks half promising, any team with a perceived better product will have their hands forced or miss out on the reward for good.
I would prefer to have all teams work transparently and I would trust the bounty to get split fairly if some project with great ideas and devs abandoned their code to work on another project.
Maybe a bounty isn’t a good strategy? Maybe it’s good for the news but after a while you start damaging your devs until no one remains.
Bounties can discourage those who would have done the work anyway as people work a lot behind closed doors and when it fails to attrackt good mercenaries, it can be a net negative overall. This is why I'm trying to push people into the light and to collaborate instead of just racing towards something nobody knows if it's a valid finish line.
In this case here, a bad outcome would be a "polished" product where the mercenaries themselves couldn't be bothered to dig back into the mess they left on the code side of things. Therefore I think protocols are more important than products and don't quite understand why fiatjaf disregards nip34's importance for the bounty.
For us the alpha release is really the starting line. That's when the real discussion begins. Before that any public discussion on the specs would just slow us down like it did when we tried to go fully open & FOSS from the beginning with the NostrGit project (now merged with the GitNestr project). I hope we get the bounty soon after we release but that doesn't mean we're going anywhere. That's when people can start making actionable proposals and not just hypotethical suggestions which reach consensus very slowly before anything is actually built.
I'm just saying that when we have something working then it becomes a much more meaningful conversation. Public spec discussions work when maintaining a project, not so much when building one from scratch.
But I also hear you, it would be nice to have efficient collaboration with all of the teams which have already given a lot of thought to these problems. I hope we'll get there after we release. Don't get too hanged up on the wording "polished product". It's really just a starting point for a healthy FOSS project.
*hung up on, damn 😂
Cathedral vs bazaar