Hacker News new | ask | show | jobs
by AdmiralAsshat 2454 days ago
I would've preferred he phrase it something like "using something like GNU Taler," so that it doesn't look like he's shilling for his own product.
2 comments

I've been in the too-awkward position of suggesting a solution "like" one that I have made, knowing already that there is some specific reason why my solution won't ultimately be the one that is accepted. Arguing this way results in a stunted discussion, giving away the foregone conclusion that my specific solution is obviously unsuitable for some reason or other, and is therefore not worthy of our consideration at all. (But we have a lot to learn from it, and we should have this discussion before putting it aside.)

It's better to not go down that rhetorical road. If they haven't heard of your solution, let them evaluate it and come to their own conclusions about whether this specific solution doesn't meet their needs for some reason or other. Don't plant that seed, especially if you would consider it a favorable outcome for your particular solution to be used.

I don't know anything about Taler, but I assume he didn't say "something like GNU Taler" on purpose, for just the same reason that he doesn't work on some other project like Taler, because there's no specific alternative that he can recommend which is at least as good in all ways, from at least his own perspective.

Writing "something like GNU Taler" is almost a suggestion to fork the project, when we haven't even talked about what particular characteristics of Taler would make it a favorable choice, and what benefits. If, in the end, it's better or cheaper for them to build their own whatever it is, better than it would be to work with you on your project, they'll have no trouble coming to that conclusion on their own.

GNU Taler is not a product. It is a GNU project. You can use it full-features for free.
It can be both. This is an important point though, nonetheless, as if you are looking for a "product" and you choose an open source "project" without considering what it means, you may have a bad time.

This tweet[1] struck a chord with me when I saw it the other day, I almost couldn't find it when this thread reminded me:

>> I just don't buy the "many eyes make all bugs shallow" thing. It takes so much time to build the context to understand wtf some code is doing that the "many eyes" get whittled down to "very few" very quickly

> This is not just a technical problem, it's a social one too. In practice, 99.999% of users of open source software engage with and expect to be treated as customers of open source, not as collaborators in a communal endeavor to build and maintain it.

To these people, it is a product. For a healthy community, we may need to find a way to get them to see it as a project. And perhaps not just one (eg. how many open source projects are in your team's product stack, and how often do you all think about that?)

[1]: https://twitter.com/searls/status/1174955330582695938

A product is something produced. It doesn't need to be for sale. That's merchandise.