News for hackers. Stuff that matters.
Re:Napa.js: A multi-threaded JavaScript runtime by j_s on Wednesday October 18, 2017 @09:55AM (#15499144)
I will circle back in a year or so to see if this 'sticks' -- very few Microsoft open source projects provide enough value / demonstrate enough inertia this early in their lifecycle to justify any investment on my part.

https://github.com/MicrosoftArchive/redis/issues/556 (Jun-Sep 2017)

>Why do MS always do this??? Start something, announce it aloud "we are now open source, we are now this and that blah blah" then quietly do a 360 and moonwalk away

Re:Napa.js: A multi-threaded JavaScript runtime by dclowd9901 on Wednesday October 18, 2017 @11:22AM (#15499853)
No doubt, but this API is something to behold. Either it's going to make it, or Facebook is going to ape it and that version will make it. I mean they probably use at least some variant of this for their multi-threaded flow-bin. I'll be happy either way, tbh.
Re:Napa.js: A multi-threaded JavaScript runtime by mohamedmansour on Friday October 27, 2017 @01:33PM (#15570490)
Re:Napa.js: A multi-threaded JavaScript runtime by panta on Wednesday October 18, 2017 @10:08AM (#15499249)
Perhaps a 180? :-)
Re:Napa.js: A multi-threaded JavaScript runtime by j_s on Wednesday October 18, 2017 @10:10AM (#15499268)
To be clear for non-Michael-Jackson-fans: 360 + moonwalk works out the same (by sliding away backwards).

https://en.wikipedia.org/wiki/Moonwalk_%28dance%29

>moves backwards while seemingly walking forwards

It's actually a near-perfect analogy here, where actions speak louder than words re: Microsoft's commitment to maintaining adaptations of existing open source projects. I think the example provided is enough to trigger a careful analysis before jumping in, and I would love to see counter-examples to help balance the evaluation.

(Please note: very specifically requesting counter-examples of Microsoft-official, intended for production, open source repositories demonstrating long-term maintenance of tweaks of/dependencies on established open source projects that for whatever reason were never up-streamed.)

Re:Napa.js: A multi-threaded JavaScript runtime by chucky_z on Wednesday October 18, 2017 @10:46AM (#15499545)
In the case of Microsoft specifically it's a silly meme that started due to the Xbox 360.

'Why do they call it the Xbox 360? Because when you see it you do a 360 and walk away.'

Re:Napa.js: A multi-threaded JavaScript runtime by panta on Wednesday October 18, 2017 @10:16AM (#15499330)
ah, cool, thanks! I didn't get it!
Re:Napa.js: A multi-threaded JavaScript runtime by smnscu on Wednesday October 18, 2017 @10:09AM (#15499259)
My reaction exactly, but it's actually a joke.

> do a 360 and moonwalk away

Re:Napa.js: A multi-threaded JavaScript runtime by rounce on Wednesday October 18, 2017 @10:31AM (#15499439)
It made me think of this Jason Kidd quote: "We're going to turn this team around 360 degrees"
Re:Napa.js: A multi-threaded JavaScript runtime by genzoman on Wednesday October 18, 2017 @10:54AM (#15499596)
Came here for this :)
Re:Napa.js: A multi-threaded JavaScript runtime by FascinatedBox on Wednesday October 18, 2017 @02:51PM (#15501845)
Re:Napa.js: A multi-threaded JavaScript runtime by jonny_eh on Wednesday October 18, 2017 @03:03PM (#15501959)
They did a 360 with xbox
Re:Napa.js: A multi-threaded JavaScript runtime by youdontknowtho on Wednesday October 18, 2017 @10:47AM (#15499555)
How do you know if they are still using it internally? It could have wide adoption inside Microsoft.

They built this to scratch an itch, then they opened the source, but that's still not enough?

Re:Napa.js: A multi-threaded JavaScript runtime by bad_user on Wednesday October 18, 2017 @10:57AM (#15499637)
People in the Microsoft camp still have to adapt to the Open Source mentality.

If the maintainers of a project don't manage the project properly and other people think they can do a better job, Open Source gives you the right to fork. And this social contract is an incentive for the maintainers to do a good job in order to not lose control.

On the other hand the maintainers have no contractual obligation to keep supporting the project.

When maintainers stop supporting the project, the code is still there to be picked up if there's enough interest. That's powerful, but also distributes the responsibility to all interested parties.

If no new maintainers show up to fork the project, then maybe it's OK for the project to die.

Re:Napa.js: A multi-threaded JavaScript runtime by jsgo on Wednesday October 18, 2017 @04:00PM (#15502421)
sounds like any other piece of software except that with it being open, someone can fork it. Software dies sometimes. That's kind of life. But it is better for them to go this new track than to push out closed items that people legitimately stake their livelihoods on and then kill it off when something else comes along.

When Windows Phone 7 was the new thing, I went to one of the Microsoft dev camps for it. I vividly remember someone in the audience, standing in the walkway berating the guy on stage talking about Windows Phone 7 development because he had been focused on some Microsoft technology (Silverlight? WPF? I can't remember) and they had basically relegated it to the past by switching over to this new framework. At the time, I was kind of just mind blown, but in retrospect I can see his disappointment. If it were open source, either another entity could champion it or it would still go in the heap of bygone frameworks, but at least then it stood a chance.

And I'm fine with Microsoft playing around with something, open sourcing it, and then they decide there is something else out there they want to work with. Mostly in cases like this where it isn't a "product" they're attempting to market. Seems to be an okay process and perhaps someone can look at what they left in their wake to gain some kind of insight from it.

Re:Napa.js: A multi-threaded JavaScript runtime by j_s on Wednesday October 18, 2017 @11:32AM (#15499973)
> How do you know if they are still using it internally? It could have wide adoption inside Microsoft.

> They built this to scratch an itch, then they opened the source, but that's still not enough?

I'm honestly not sure where this question is coming from. The issue I linked is on a port of Redis to Windows done back when Microsoft Open Technologies was temporarily spun out as a subsidiary, and is one of many there reflecting frustration at Microsoft's mismanagement of the project, especially lack of communication regarding long-term support. It serves as a recent example of how Microsoft drops a low-priority open source project.

Microsoft is building a strong track record with open source projects that they completely control, but less so when they don't. I believe this is relevant here because of Napa.js's tight coupling with Node.js.

Re:Napa.js: A multi-threaded JavaScript runtime by WorldMaker on Wednesday October 18, 2017 @12:09PM (#15500340)
The entire goal for the fork was to try to convince upstream (antirez) to eventually merge the needed changes for a better experience for Windows users. Just as any other distro doesn't want to long term maintain a fork and prefers to merge changes upstream as much as it possibly can. In the case of redis, the fork didn't entirely meet upstream needs/considerations and the Windows distro didn't have the resources to continue a long term fork.

Microsoft Open Technologies had some successes here too: off the top of my head NodeJS and Git both have gotten much better on Windows as a result of work that Microsoft Open Technologies started in forks and eventually got merged upstream. The NAPI work to support both V8 and ChakraCore continues at a reasonable pace precisely because there is upstream engagement, upstream merging, and NodeJS-ChakraCore is less of a full fork more like a distro-specific build flag.

Plus, the priority on things like Redis for Windows shifted with the Windows Subsystem for Linux; there was less need to get open source projects to treat Windows as a supported distro directly when Windows can piggy back off of Ubuntu (or SUSE or Fedora) distro work.

None of that solves lack of communication about the forks left on the vine, and it is a shame there isn't strong redis support on Windows, but everyone has priorities, including antirez, and even if those priorities aren't communicated fully, they seem to at least be somewhat transparent to this humble developer from the outside of either work.

Re:Napa.js: A multi-threaded JavaScript runtime by tmzt on Wednesday October 18, 2017 @12:19PM (#15500428)
I'd like to see something come out of their OpenSSH fork to support AD and PSRemoting/WinRM.
Re:Napa.js: A multi-threaded JavaScript runtime by j_s on Wednesday October 18, 2017 @12:23PM (#15500456)
So what is your prediction on the long-term viability of Napa.js? Also, any feedback on the timeline would be appreciated, specifically how long to wait before evaluating the probability of long-term support from Microsoft.

In my mind, it will have to attract a strong enough community to survive without Microsoft's financial support which will probably shut down in a year or two. It's interesting because if it does hit critical mass that increases the likelihood that it will continue to be funded.

Re:Napa.js: A multi-threaded JavaScript runtime by WorldMaker on Wednesday October 18, 2017 @02:32PM (#15501683)
That's a good question. Ignoring past headaches you've had with Microsoft's support of open source, how do you evaluate any open source tool for use in production and/or for long-term viability?

In the NodeJS world, sometimes "long-term" means 9 months it feels like. In open source, sometimes "support" means "file a PR if you care so much about that bug" or "fork it yourself". Are you perhaps expecting a longer term or more support because it is Microsoft behind it?

It looks actively maintained right now, but its published semver is 0.x. There are a lot of 0.x libraries in active use in NodeJS, but it's still semver-obvious grain of salt from the maintainers to keep in mind when considering it for support.

The README tells us that it was directly built to support a production need in Bing today. That seems like as big of a vote of support confidence as you might get from an open source project that a team has vested interest in it.

On the other hand, Bing isn't inside Microsoft's developer division, so they have fewer vested interests in supporting outside developers long term. It's also possible that at some point in the future they get internally sold on a developer division or Windows division or Azure alternative that Microsoft has financial or marketing reasons to commercialize.

If I had a production need for something like Napa.js I don't see any particular red flags to avoid it, it looks like it should be easy enough to migrate to something else down the road if necessary, and would probably consider it.