8 ms·
> Wasmer, by necessity, design, and passion lives and breathes Wasm and open source. > As is dictated by our commitment to open source and the precedent of soc
by mfer 5y ago
> Wasmer, by necessity, design, and passion lives and breathes Wasm and open source.
> As is dictated by our commitment to open source and the precedent of social alignment set by WebAssembly...
> Although all these events still do not portray Wasmer in the best light, I hope they can at least assuage the understandable concerns of our community that we had acted in a way so fundamentally contrary to the values of open source and WebAssembly in particular.
Wasmer recently recently released a closed source wasm package manager. Something doesn't seem right. Anyone feel something is off here?
- syrusakbary 5y agoThe WAPM backend is closed-source for now. However, the API layer based on GraphQL and the CLI are completely open for anyone to use: https://registry.wapm.io/graphql https://registry.wapm.io/graphql https://github.com/wasmerio/wapm-cli https://github.com/wasmerio/wapm-cli If anyone wants to replicate the WebAssembly Package Manager locally please send me an email to syrus@wasmer.io so we can start a discussion around a potential open-source path for it :) EDIT: removed "for security reasons among other things" as it might imply WAPM is not secure, and that's definitely not the case
- tux3 5y agoClosed source for security reasons? Do you mean it would not be secure if people were able to see the source?
- syrusakbary 5y agoOpen-source code is obviously easier to exploit than closed source one. But that doesn't imply necessarily the existence of security bugs. For example, we might be using a dependency that is vulnerable to exploits or have an exploit in our own code that opens a security breach (hopefully not!). As an open-source maintainer I like to open projects for which the code-quality is high, and this implies doing a deep and thorough review of the codebase before open-sourcing.
- tptacek 5y agoOpen-source code is not in fact easier to exploit than closed-source code is. Security and openness are mostly orthogonal.
- syrusakbary 5y ago> Open-source code is not in fact easier to exploit than closed-source code is Not sure if I agree with this. Obscure systems are usually harder to hack as they require an extra effort on discoverability that open systems don't have. Easier to exploit != more exploitable. One is about the threshold to discover an exploit, the other is about the total exploitable bugs. In my view, the "hackability level" is the same for both open and closed-source projects. Making something close it doesn't make it less hackeable, it just makes the threshold to discover bugs higher. Also, one may argue that with open-source projects you may be able to fix more bugs since those are in the open and more people can report them (thus, more secure). I think it really depends on the contribution level and where the codebase is at to see if security might be a concern or not. > Security and openness are mostly orthogonal. But I mostly agree with this ;)
- tptacek 5y agoMost people would say that reducing the threshold to discover security bugs is a good thing.
- burnte 5y agoSecurity through obscurity is not security. The source WAS open, any bugs in it then are still discoverable. Opening source can actually make things more secure, the whole "many eyes" thing.
- kasey_junk 5y agoThe interesting thing in this argument is that the first person is positing axiomatically that closed source is more secure, the second person is positing that open/closed largely doesn’t matter and finally your position axiomatically is that open is more secured. We’ve known since the 70s that you (provably) can’t trust source code. We know experientially that it’s easier to diagnose code than programs. We also know experientially that the teams involved have a dramatic effect on the security of the outcomes. How will we ever decide which of our three contestants will win?
- slimsag 5y agoThere is nothing[0] suspicious[1] about[2] Wasmer. [0] https://news.ycombinator.com/item?id=28772863 https://news.ycombinator.com/item?id=28772863 [1] https://www.reddit.com/r/programming/comments/o1838v/the_webassembly_runtime_wasmer_20_is_released_up/h21rpzp/ https://www.reddit.com/r/programming/comments/o1838v/the_web... [2] https://news.ycombinator.com/item?id=24904829 https://news.ycombinator.com/item?id=24904829
- srcreigh 5y ago> But you need to know that Wasmer and its sibling projects will stay free forever. We are open source lovers, all of us, and we have a strong background on working on open source projects before joining Wasmer too. That's great. I'm sure the closed source paid 10x faster editions of the graphene Python GraphQL server written by Syrus "CEO of Graphene" and CEO of wasmer will be open sourced in this spirit. https://github.com/graphql-python/graphene/issues/268#issuecomment-340214405 https://github.com/graphql-python/graphene/issues/268#issuec... http://graphql-quiver.com/ http://graphql-quiver.com/
- syrusakbary 5y agoBummer. What an unfortunate comment. Many people in the Python GraphQL ecosystem are very aware of how much I pushed that ecosystem forward (in fact, I created it!) and actually cheered for the success of Quiver [1]. Probably downloads will speak louder than any words: Graphene has 1/5th of the downloads of Django (~1.2 million per month [2]), all on the spirit of an open community that is governed by many more people than myself. If you want an open alternative to Quiver, you can start by investing your time creating it. But you are not entitled on other people's time doing it for you for free. As people say in the US: "Put your money (or time) where your mouth is". [1] https://news.ycombinator.com/item?id=17568848 https://news.ycombinator.com/item?id=17568848 [2] https://pypistats.org/packages/graphene https://pypistats.org/packages/graphene
- srcreigh 5y agoI have no problems paying for good services. Is quiver still available and supported? When I checked the demo website a few weeks ago it seemed a bit abandoned. [0] We seem to be doing well enough by disabling middleware promise wrapping via middleware manager [1]. Our median graphQL API response times got 2x faster with that config change. However, IIRC we are still seeing around 150 promises in one GraphQL request when I'd like to see around 1. I am interested in quiver for that reason. Anyway, the problem isn't about charging for your work. It's about having a track record of charging for closed source additions to your own open source software platform meanwhile saying wasmer and sibling projects will be free forever as if that's how it's always been with everything else. [0]: https://graphql-quiver.com/benchmarks/ https://graphql-quiver.com/benchmarks/ [1]: https://github.com/graphql-python/graphql-core-legacy/blob/master/graphql/execution/middleware.py#L14-L29 https://github.com/graphql-python/graphql-core-legacy/blob/m...
- eatonphil 5y agoI don't think it's too reasonable to expect that every open-source-friendly company never releases a closed source project. Or at least I don't find it weird that an open-source-friendly company might have one closed source project. Their core project, wasmer, is open-source after all.
- ledgerdev 5y ago> Wasmer recently recently released a closed source wasm package manager. Something doesn't seem right. Anyone feel something is off here? I have to agree. Are there any open source package managers similar to cargo?