Fastly hires entire Wasmtime team from Mozilla
bytecodealliance.org
bytecodealliance.org
This deal has got me thinking... whether a right way to "lay-off" a supremely talented bunch is to actually see if other companies are willing to offer them jobs? Kind of how player transfers happen in Football (soccer).
Either the team goes to the newer company wholesale or you help find your engineers suitable roles elsewhere.
One might argue there's no advantage to the company laying-off people, but they could save on the severance package, and frankly, two companies entering an understanding like this bodes well on other levels where someone could probably explore a "cross-company" job change with blessings of the employers on both sides of the table.
Of course, things like salary negotiations take a hit for the candidate especially, but internal transfers to different teams / location in bigger companies already work this way. May be year-end reviews and code can be shared on a need-to-know basis between the companies with employee consent.
In particular, such arrangements between smaller / crash-strapped companies and bigger / well-funded companies might work out for the good. Then again, you never want the bigger company to start poaching wholesale from the smaller one. May be there's a balance in here somewhere that can be worked out given enough time and data.
- Source company which is financially strained gets some income in addition to reduced salary expenses.
- Destination company saves on paying other recruiting costs and acquires a pre-assembled team. They're essentially buying a working unit instead of having to build their own.
- Employees avoid the uncertainty of being dropped in the middle of the process (or summarily laid off), assuming the right protections were in place in the agreement.
A company could just offer folks jobs directly (CA frowns on companies working to block employee mobility given employers can also fire folks with basically no notice). But it smooths things to wrap it up in an acquihire.
Startups often get offers like this.
Wasn't there a recent case on HN where google or apple after the company rejected the aquihire just offered the positions to staff directly? I think they got sued?
Ironically, the new company was paying new hires much more. I would have been better off quitting and getting re-hired.
It's better if the employees can negotiate their own way into a different company or companies. No sense in letting the previous company try to cash in on the team on their way out.
In a regular company trying to sell a whole chunk of workers, that should probably be a union. Which is indeed what happens in many European countries when this sort of thing happens.
Who is working in a team worth acquihiring and then plans on being on unemployment benefits or has trouble finding a new job ? And I can't remember the last time someone asked about referrals ...
hmm, I guess it's like the last season of Mad Men when McCann consumes SC&P.
In this case the project the devs were previously working on had public visibility, so perhaps they may have been able to negotiate at a higher level.
If you are ever in a position where you find out your current employer is looking to sell your team, and assuming you have an easy marketable skillet. it might be best to quit ASAP.
The surreal part came when the CEO of the consultancy and the CIO and CFO of the utility took the dozen of us out to dinner at a very upmarket restaurant. There were multiple times that night when a few of us felt like chattel. I almost felt like I should be baring my teeth so the new owner could check me out. Very weird, but it was a win-win and I stayed at the utility 7 years doing some really interesting work.
EDITED TO ADD: I should point out that our salaries went up, but for the utility that was still cheaper than the T&M rates they were paying.
That's how Gitlab sold Gitter recently.
I really like your idea. It should be one of management ethics: caring for staffs even if you have to say goodbye.
I really wish we could come up with sustainable models for not for (much) profit tech companies that was beyond our current systems of volunteer and "strategic partnerships" (as in, it's a side effect of a larger business strategy).
Basically in this model, engineers would make maybe 80-160k. No options, no equity, no "going public". No fancy offices or amenities. Just a reasonable pay, a mission for the public good, and sincere dedicated people.
I've looked hard and searched for jobs like that. Maybe wikimedia and internet archive. But yeah, can't get my emails returned so maybe that's not who they are.
I want a more general version
So they cut teams that a) weren't directly working on their core browser and b) doesn't make money for spending on their browser.
The money from Google is practically a donation at this point. It's not exactly an altruistic one but it's not exactly a pure business transaction either given Firefox's current market share.
Your first bad assumption is that the amount of money is fixed.
And here is a 2013 post about the "next generation" engine (Servo) https://blog.mozilla.org/blog/2013/04/03/mozilla-and-samsung...
> So they cut teams that a) weren't directly working on their core browser and b) doesn't make money for spending on their browser.
Exactly, that means they do not see any value in closing the gap with Chrome. Servo was this plan that launched years ago. See this paragraph from the above post from 2013
> Servo is an attempt to rebuild the Web browser from the ground up on modern hardware, rethinking old assumptions along the way. This means addressing the causes of security vulnerabilities while designing a platform that can fully utilize the performance of tomorrow’s massively parallel hardware to enable new and richer experiences on the Web.
Not to mention their threat response team got laid off
https://www.securityweek.com/mozilla-cybersecurity-staff-hit...
I think Servo was branded as a research project pretty early on. That it would replace Firefox wasn't very realistic.
Congratulations to the whole Wasmtime team! :)
I think they can make a great impact with these hires.
Looks like that product is in private beta. It'll be interesting to compare and contrast it with Cloudflare Workers. In any case, I'm glad there's going to be some competition in that space.
It seems most of the Mozilla people working on Cranelift are no longer employed to work on it.
In one side, I'm happy that some of the people affected by the Mozilla layoffs have now secured a job.
On the other side, now almost all the power of the WASI standard is concentrated into the Fastly corporation (with wider penetration thanks to the WASI integration in Rust). The main and only player of the Bytecode Alliance becomes Fastly as well (as Mozilla is out of the server-side Wasm game).
So... how this could be bad? The Bytecode Alliance has been biased since their inception, blocking any attempt of collaboration from Wasmer based on personal bias (I work at Wasmer) and other external entities out of their control [1] [2] [3]. This move is conceding them now a full-control over a standard such as WASI, placing the whole standard at risk [4]
[1] https://twitter.com/syrusakbary/status/1202351432050954240 [2] https://github.com/WebAssembly/WASI/issues/3#issuecomment-71... [3] https://twitter.com/cjihrig/status/1320763509463015425 [4] https://twitter.com/cjihrig/status/1320761713365581824
We just need JIT support for an embeddable RISC-V emulator, and we're golden. Does it matter what the host language is these days server-side? I suppose there's a higher chance that the WebAssembly standard will adopt some instructions that favor cloud computation now, with these news.
- wasm has modules, "imports", and "exports" for I/O and host communication. The glue is one of the harder parts of the problem.
- wasm bytecode is sandboxable with a simple MMU mapping. That's one reason it has structured control flow rather than goto. (And this is why you need a special algorithm to compile C gotos to wasm.) RISC V certainly doesn't limit itself like that.
So I think this idea is glossing over a lot of details... not all ISAs are equal, especially ones meant to be transmitted over the network!
The first point is news to me, but I suppose you can build anything you want in an open ISA too. It looks like each object is like a shared object with an import and export table that connects things together, so the host would have to have a "modern" variant of a dynamic loader. It sounds like it would be painful to support that without an established way of doing it, that is standardized. So, guess I agree.
https://scholar.google.com/scholar?cluster=14979605902538775...
tl;dr security introduces a lot of design constraints that RISC V doesn't have.
section 2.3 on structured control flow:
WebAssembly represents control flow differently from most stack machines. It does not offer simple jumps but instead provides structured control flow constructs more akin to a programming language. This ensures by construction that control flow cannot form irreducible loops, contain branches to blocks with misaligned stack heights, or branch into the middle of a multi-byte instruction. These properties allow WebAssembly code to be validated in a single pass, compiled in a single pass, or even transformed to an SSA-form intermediate form in a single pass.
Also, wasm is a "Harvard architecture" rather than von Neumann (separate address space for code and data), also for security reasons:
section 2.2:
Linear memory is disjoint from code space, the execution stack, and the engine’s data structures; therefore compiled programs cannot corrupt their execution environment, jump to arbitrary locations, or perform other undefined behavior. At worst, a buggy or exploited WebAssembly program can make a mess of the data in its own memory.
However, wasm also leaves some things to be desired security wise. Buffer overflows in C are still buffer overflows once you compile to wasm, and can be chained in to JS exploits.
https://old.reddit.com/r/ProgrammingLanguages/comments/icb9v...
If you try to use RISC V in the same contexts, you'll have the same problems. If you have an additional layer of process sandboxing, then those could be mitigated. But then RISC V is not a wasm replacement.
Although maybe wasm is hopeless for C code, so you need more sandboxing anyway, so then it's on par with RISC V... interesting question.
You can send anything down the wire to the wasm env provided
1. It can instantiate wasm itself
2. Your (whatever) to wasm compiler is small enough and outweighs the downsides of on device compilation (to wasm)
https://github.com/fwsGonzo/rvscript
I have done that here. Example:
APICALL(api_math_smoothstep)
{
auto [edge0, edge1, x] = machine.sysargs <float, float, float> ();
x = std::clamp((x - edge0) / (edge1 - edge0), 0.0f, 1.0f);
machine.cpu.registers().getfl(10).set_float(x * x * (3 - 2 * x));
return 0;
}
Good choice on using var-arg-templates for passing arguments between env and host, i think moving over all scripting bindings to va-templatized bindings is the only sane option for the future (boy have i spent time fighting binding bugs in my days)
Here's a nice comparison between WebAssembly and RISC-V, written by Heyang (from the Wasmer team) that fits perfectly on the topic:
https://medium.com/@losfair/a-comparison-between-webassembly...
ADD: a few of the reasons:
- When JITing RISC-V you cannot tell which are the last use of registers without a very expensive whole-graph analysis. Without that, you will have to generate more code than necessary.
- WASM's representation is very close to what you want in the compiler. In particular, you can directly tell all incoming control-flow edges, which makes analysis much more precise, gives optimization opportunities you would otherwise miss. Recreating this information from a binary is either impossible (due to computed branches) or expensive both in terms of analysis and the guards you have to generate to protect your assumptions.
> the running code is not even provided with a way to access itself.
You can do the same thing with some ELF post-processing. I have done this, and used it over several months now. It works just fine, even though there is nothing in the RISC-V standard that explicitly says this must be true.
I asked the GCC people and they consider it a bug if there's any data in the text-segment. So, at leas there is that. Maybe we can call it optional support? :)
- RISC-V is a large family of ISAs, though Unix platform targets a much narrower definition, the RV64GC. The "Feature table" lists FP and SIMD as "in extension" but doesn't do the same for Memory layout and protection. It's seems inconceivable to me that you would use paging in a WASM-replacement context. Same for instruction length, two-byte instruction depends on the "C" extension.
- There is nothing that prevents RISC-V in the browser from denying the ability to generate code on the fly. Just like, say iOS, it could run in a "W^X" model, that is, writable memory cannot be executed from.
- atomics, again, are part of an extension, the "A" extension. They do not have to be included, and do not make sense IMO in a single-threaded WASM replacement context.
All that said, WASM is well designed. The structured control flow is a bit painful for some producers and the lack of tail recursion elimination is criminal, but running running/JITting RISC-V in the browser would almost certainly add more overhead.
As for "personal bias," I think that's fair game considering the personal history between you and one of the members of BA. Wouldn't exactly be psyched to work with you either.
> the whole conversation on your end seems petty and toxic, at first glance
That's a first! Can you expand on that? Thanks!
Honestly, a logo for a project is both a huge thing, and a massive timesink. Your responses read that you just want to take over choosing the logo ("I'm happy to take on the responsibility of organizing it."). Then you seem to want to make this a whole issue encapsulating the problems with wasm (I am of course just reading one issue, not the many related problems)
Priorities in open-source communities are weighted differently by different members of it. We do care about accessibility, and the current logo have serious readability issues that affect disproportionally people with low-vision.
IMHO a "welcoming" community should encourage improvements, rather than halting collaboration because it doesn't come from the main members.
If they are also rejecting good quality code, that's a whole other issue.
What does this mean? How does this relate to current logo? Is this a color blindness issue?
I've explained it here: https://speakerdeck.com/syrusakbary/wasi-logo-proposal
https://www.w3.org/WAI/WCAG21/Understanding/images-of-text.h...
https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-cont...
>Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
So it's not about not being a main member but rather about being basically seen as a bad actor to the community. Actions have consequences and the consequence for the trademark BS is being seen as an enemy of the community. The way to resolve that is to not annoy them about things while being as helpful as possible. Your comments on Github definitely are not that (they're adversarial, clearly annoy them with something they don't want to deal with, etc.) which simply cements their view of you being a bad actor.
edit: Your attitude is one I've seen before and it works in getting things from people who are forced to deal with you (service workers, employees, government officials, etc.). It does not work for people who can just walk away, block you or blacklist you since they will just do that.
The pettiness is that this looks like a non-issue blown into a flamewar where the BA has every right not to accept contributions from yourself because of past actions taken by the business you founded. I thought it was fine for them to close the issue was out of scope/focus, it didn't need more attention or for you to project your own gripes onto it.
All told this thread left a very bad taste in my mouth with respect to Wasmer, while I have a lot of respect for the BA and Wasmtime teams and I'm very glad that they found a home at Fastly.
> We would need to work with a lawyer to determine the IP issues around this. It’s possible that just using the same policy as for the WebAssembly logo works, but I know that various organizations have grown more concerned about IP in this space since then.
> This is in no small part because your company, Wasmer, attempted to register “WebAssembly” and “Wasm” as trademarks. The USPTO rejected the application, but I don’t think we can assume that attempts to register a brandmark for a WASI logo would be similarly rejected.
This doesn’t seem to be a he said she said situation; gp had the chance to defend himself and all he could come up was a very weak “The trademark requests were driven by our lawyers” (and what came after that was even more shameless if you ask me): https://github.com/WebAssembly/WASI/issues/3#issuecomment-71...
Given that context, I’d say the gp comment (especially the “personal bias” part) is likely motivated smearing.
Bottom line: don’t make up your mind just because it’s the top comment of an HN thread, or because the discrimination/racism card is played (racism card isn’t played here, it’s in the linked GH issue). If you want to form an opinion, read the other side first.
But 100% agreed, it's essential to stay critical before making your mind on a given thing.
Also, did you delete your downvoted comment then post the same thing in a new one? I saw your comment posted a while ago, in the gray, then when I refreshed before responding, bam, “0 minutes ago”. That’s not cool.
And to answer your question: yes, I deleted the comment because I thought it was going to start a non-productive discussion (it had 1 point at the moment of deletion). Then I realized deleting could provoke some other issues, and decided to repost again.
Yeah, I know there is a spectrum of people that downvote my comments... and it's ok!
Then why register?
Lawyers can't make you do anything. They can advise. They can't act without your consent.
We also course-corrected as soon as we realized of it, much before it came public a few weeks ago.
You accidentally attempted to register a trademark?
I have never heard of that. Either you are small enough that the non-trivial tediousness and cost of the process catches a lot of attention. Or you are large enough to have a general counsel overseeing a documented chain of approvals.
You don't then get to go and complain that the community isn't treating you well. They're right not to trust you.
You use Oracle's JS trademark as precedent, but that's woefully ignorant of how it came about. JavaScript was not a four year old open standard when Oracle came along and scooped it up. JS was a Java branding deal between Sun and Netscape.
If you want to contribute to build something good, because a strong wasm community is in your best interest, drop the attitude and don't make any more moves to sabotage the project.
If you want to lawyer up and try to exploit the fruits of the community, then do that. But you need to pick a lane. I don't see Larry hanging around HN complaining about how people are treating him on GitHub.
I don't have a dog in this fight. Prior to this thread, I didn't know about you, your company, or anyone in all these links you've posted except I remember reading a post by Lin Clark once.
I wrote another post that I deleted pretty quickly when I realized how aggressive it sounded. But it wasn't trying to be aggressive, just convey the hostility of what you did and how you should expect people to react.
As reflected in other comments in this thread, it's not in Wasmer intent to trademark WebAssembly. And we successfully course-corrected any actions way before it was even public.
We have been continuously pushing the limits of WebAssembly since we were founded. The success of Wasmer as a company solely depends on the success of WebAssembly as a technology, and is on our best interest to continue pushing it forward.
In fact, I'd argue that Wasmer has been pioneer in:
1. Open-sourcing the first working Rust WebAssembly runtime (wasmtime existed when I created Wasmer, but was not able to run anything [1])
2. Creating a Package Manager for WebAssembly [2]
3. Creating WebAssembly embeddings for non-js languages (PHP, Ruby, Python, ...)
4. Running WASI fully in a browser, including an online shell [3]
I'm totally willing to entertain arguments that the Bytecode Alliance are also acting in bad faith. It's a harsh world and open source is not all unicorns and rainbows.
But you can't just brush off the trademark issue by claiming it was unintentional. Especially when what you write here doesn't fit well with what you've written elsewhere [3]. I've gotten trademarks through lawyers before and the level of detail was an intense experience.
You seem to be claiming your lawyers independently decided to trademark WebAssembly and you signed the pages without reading them? At least that's what I can put together from your vague writing about it.
If you're not willing to give a concrete step by step post mortem of how such a clusterfuck happened, the community should (and I'm sure does) feel at liberty to not believe you in the slightest. You don't owe them an explanation, they don't owe you their trust.
You're clearly good at technology, better than me I'm sure, and I'm no slouch. You're doing impressive work and I have no wish to downplay that. But you appear to be quite bad at getting along with people. Maybe you can make your business work without developing that skill, and if that's your plan then best of luck to you. Sincerely.
[1] https://i.imgur.com/TPBH9EH.png [2] https://news.ycombinator.com/item?id=19515476 [3] https://github.com/WebAssembly/WASI/issues/3#issuecomment-71...
Agreed, perhaps that's the best way.
> Wasmer the company might have been announced November 12 2019, but the open source project was around a year before that. I don't know what happened prior to that date to make the Bytecode Alliance members want to "veto" you as you put it, and maybe you're entirely blameless for that. As you point out, your trademark shenanigans hadn't taken place yet. But saying the "veto of Wasmer happened the same day it was announced" is misleading at best.
I think you misunderstood. I meant that Wasmer itself was vetoed from joining the Bytecode Alliance the same day that the Bytecode Alliance was announced. Wasmer was founded way before (as a company and a open-source project).
> But you appear to be quite bad at getting along with people.
It's curious this is the impression caused. I'm definitely not someone with low social skills.
EDIT: added an extra response
So the criticism in that paragraph is undeserved, I've removed it for clarity but will leave it here for posterity.
> Wasmer the company might have been announced November 12 2019, but the open source project was around a year before that. I don't know what happened prior to that date to make the Bytecode Alliance members want to "veto" you as you put it, and maybe you're entirely blameless for that. As you point out, your trademark shenanigans hadn't taken place yet. But saying the "veto of Wasmer happened the same day it was announced" is misleading at best.
I don't have much data around that, happy to be proven wrong. But we don't need more corporate control over package managers and code-reuse ecosystems.
Their persona bias seems to be summarized as (from the github issue):
>The rejection from the Bytecode Alliance was based on a history of behavior that isn’t compatible with the BA codes of conduct—both the individual CoC and the organizational CoC.
Which seems a lot less like personal bias and a lot more like both you personally and your company have crossed too many lines to be considered good members of the community. Given your response was to lash out everywhere rather than take it as constructive criticism to grow with I suspect your behavior beforehand wasn't much better.
Using a non-accessible logo that is hard to read provides a non-ideal experience for our visitors, so we can't really use it unless it becomes more polished.
This forced wapm to use a different WASI logo than the "official" one, which is also a non-ideal experience (it adds fragmentation). That's why we believe is just better to push all along a bit more polished logo.
Is such a simple thing to fix, that I'm surprised of the amount of flamewar that it generated.
[1] https://en.wikipedia.org/w/index.php?title=Wikipedia:Sockpup...
"Unreal Engine 3 Support for Adobe Flash Player - Unreal Tournament 3"
https://www.youtube.com/watch?v=UQiUP2Hd60Y
https://adobe-flash.github.io/crossbridge/
Luckily we are getting our plugins back, even in its present state.
https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
And naturally Flash and Java applets,