Hacker News new | ask | show | jobs
by Kolja 999 days ago
I have no personal experience with Wasmer or the people behind it. But with the things I read about them (e. g. https://mnt.io/2021/10/04/i-leave-wasmer/ crossed my path again a few days ago) would make me, to put it lightly, hesitate before building on it.
2 comments

This CEO in question also appeared yesterday here and was blocked from ziglang. https://news.ycombinator.com/item?id=37541994
Thanks for providing the link, readers can probably judge for themselves by checking the comments there if blocking someone just for having a different point of view was the right thing to do by the Zig leadership team

Context: https://news.ycombinator.com/item?id=37545192

> […] just for having a different point of view was the right thing to do by the Zig leadership team

From reading these threads it’s less about the opinions you hold and more about how you behaved, no?

Zig leadership asked you to not place bug bounties on issues without their consent. You decided to ignore their request and kept the bounty up by moving it to your own repo. Zig leadership decided you weren’t engaging in a particularly constructive way and decided you were unwelcome.

Is not a bug bounty and the bounty was placed for a feature we needed at Wasmer, it was not required to be merged upstream in Zig so of course we kept the sponsorship for the work up
WASIX relies on way too many forked projects to be maintainable. It's part of the reason that I resigned after only a couple months working for you - what you're trying to do isn't a terrible idea, but it is super poorly executed.

The other part is exactly what yoshuaw described as very disrespectful and immature behavior on your part. I know from my interactions with you that you are extremely argumentative _to a fault_, don't take no for an answer, and always assume you know better than everyone around you. Maybe you're somehow proud of that, but it's not surprising to hear you've been banned from participating in the Zig community.

You should respect the Zig community's wishes and be willing to contract the work out with clear terms, taking on some of the risk that it takes longer than expected yourself.

Please read the comments on other threads https://news.ycombinator.com/item?id=37558807
The "different point of view" here seems like you're determined to interact with their community in a way they've explicitly asked you not to [0]:

> Please don’t use bounties to incentivize Zig development.

They explained their reasoning extensively:

  - Bounties foster competition at the expense of cooperation.
  - Bounties are an utterly simplistic way of dealing with the business management side of creating software:
    - Instead of scouting for a suitable candidate, you’re letting battle royale dynamics pick a winner for you, at the expense of everybody who’s going to lose the competition.
    - Instead of creating a clear contract where you take on some of the risk, you implicitly put the entirety of the risk on the contestants (eg partial solutions don’t get any payout).
    - Instead of allocating time and resources to proper due diligence, you instead penalize any form of thoughtfulness in favor of reckless action (eg a solution just needs to pass a test suite).
    - Instead of planning for the full lifecycle of software, which also includes maintenance, you end up with a quickly bitrotting artifact that is of no practical use to anybody.
    - Instead of spreading unease to all the people involved, it would be preferable you instead learned how to do business properly.
  - On projects less radical than Zig, you might also put pressure on the development team to accept the winning submission, which, given the above, will probably not be the most well-thought-out and maintainable solution.
You responded by moving the request to your own repo, with the following disclaimer [1]:

> Info: while ideally the PR should be merged into Zig master, is not a necessary requirement to receive the bounty. As long as a fork exists that fulfills the requirements laid out before, the bounty will be awarded

To an outsider, this looks like you slapped a new name on the exact thing the Zig team asked you to stop.

Do you feel your new request adaquately addresses the team's issues?

[0] https://ziglang.org/news/bounties-damage-open-source-project...

[1] https://github.com/wasmerio/wasmer/issues/4218

While I respect their point of view, I do not agree that banning bounties in OSS projects is the right way of approaching it, and as such we haven't complied to it. Specially since this is a bounty for a real need that we have at Wasmer.

Furthermore, we also took their post constructively and added two more points on the bounty issue [1] that we believe should solve most of their concerns:

* Wasmer will manage the work and have at most one person or team working on it at a time. Anyone interested on the work should reply here and organization of the work will be done by the Wasmer team

* Partial work that actually works will be rewarded accordingly (for example, the libc layer, or the Zig layer itself)

Of course, the fact that they banned any further conversation from the disagreement doesn't make specially easy to see if such an approach will be sufficient for them or not.

[1] https://github.com/wasmerio/wasmer/issues/4218#issuecomment-...

Isn't that how oss works? You should be able to add bounties to your fork. Then zig team can choose not to merge these if they want.
Clearly, they are not compliant with WASI specifications built by the ByteCode Alliance, creators of WebAssembly. They are making their own web-assembly-thing not compliant with anything.
What do you mean? We are as compliant with WASI as a Wasm runtime can be. We have tests assuring that for each commit on our repo.

As a matter of fact we pass more tests than any runtime created by the BA as reflected here:

https://wasi.fyi/

You forked the WASI Preview 1 and are making your own standards from it, and instead of working with the Bytecode Alliance, you are forcing your own standards.
Where is that clear?

I assumed they were compliant with the WASI specifications.

They are forking from WASI Preview 1, but Bytecode Alliance is working on WASI Preview 2.