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.

Reply to this note

Please Login to reply.

Discussion

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 😂