GitHub has completed its acquisition of NPM

It's 2020, please stop bringing up E/E/E. That boat sailed long ago.

Correct, it is not their fault. But they ended up spending all their time on it, and in an unproductive manner, I feel.

Oh please... I’ve solved more customer needs and business value from this "dumpster fire" than I have with other "real languages" I've worked with in my career. Give it some credit.

The JS community is the worlds biggest open source community and that's what they've been buying.

No, it is an NPM fault. Their team is highly toxic and selfish.

As an online community gets larger, the probability of a member deserving a comparison involving Nazis or Hitler approaches 1?

That the JS community is huge and overwhelmingly newer to the industry than (for example) me does not excuse bad behaviour. What it _does_ excuse is a lack of awareness of history and historical context. And the solution to that is education.

It pains me to see so many wheel-reinventions, both technical and social. But the flip side is that people who don't know something's not supposed to be possible will _sometimes_ manage to do it anyway.

NPM, on the other hand, seemed very much to be all about package management being a simple problem, and learned the hard way that there's a reason why other systems have more complexity.

Are you using a 5400rpm hdd?

In an existing UI project repo... ci (which clears node_modules) then installs from lock...

    added 1880 packages in 23.283s

    real    0m24.073s
    user    0m0.000s
    sys     0m0.135s

Still slower than I'd like... but I'm pretty judicious in terms of what I let come in regarding dependencies. That's react, redux, react-redux, material-ui, parcel (for webpack, babel, etc) and a few other dependencies.

For one of the API packages ci over an existing install...

    added 1069 packages in 12.911s

    real    0m13.708s
    user    0m0.045s
    sys     0m0.076s

So either you're including the kitchen sink, or you're running on a really slow drive.

I just use yarn. V2 forces PNP by default which speeds up the installation by 2-3x.

https://yarnpkg.com/features/pnp

You are saying it is like you don't have to put JDK to your Dockerized java apps. (pick any language you want that is not statically compiled)

What companies do you see paying for this service? Why would they prefer paying a company for this over a community-driven effort to curate secure packages.

Yep, in particular the use case is private packages.

Yep, non-canonical registries are used by business and they are more likely to pay. For example our dependency firewall will be a paid feature that delays updates from packages that are recently updated under suspicious circumstances like: author changed, author information changed, different programming language, activity after a long period of inactivity, large change to the code, etc.

I think hosting a package repo will generally create more downloads (costs money) than uploads (helps with peering but costs storage) because the average number of downloads for a package is more than 1.

We stopped using gitlabs artifact repositories for this exact reason!

GitLab PM here - Agreed that is an important feature and one we have scheduled for milestone 13.1 which will be released in June 2020.

As a workaround, you can add your access token as an environment variable and use that to publish/install packages via CI/CD.

And if you are interested in contributing to GitLab that issue is a great way get started.

If you're running a package registry, you'd be painfully unaware of your own requirements if you're using a host/cloud that you need to pay for the amount of bandwidth.

Hosting a package registry on AWS for example, unless you figure out a way of seriously reducing the amount of traffic (which seems to be against working towards making a popular registry), is suicidal because of the bandwidth costs.

> This massively depends on the architecture of the package manager though. Composer (PHPs primary package manager) only serves the metadata

See also, CocoaPods. But we're really talking about two things here as if they're the same, and I think it's because the language we use for them isn't clear: package managers (like CocoaPods and Composer) and full-blown package registries (like RubyGems and NPM). I mean, the difference between them is slight; and there's overlap. They both resolve package dependencies and sort out problems, for example. But they're such very, very different things!

It's not really fair to compare these two approaches and say things about Composer like "this allows them to serve the whole community with a team of 2-4 people": they're just not directly comparable. Those 2-4 people + the entire GitHub staff is what supports the whole community.

Now - don't get me wrong: I think it's fine that GitHub does this! I'm not saying that CocoaPods and Composer are making the wrong choice here at all. In fact, I'm proud to work for a company that provides this service to everyone. But it hand-waves away a lot of stuff as just an "architecture" decision, when in reality it's a decision not to do the hardest part - which is hosting, because it requires gobs of money and dedicated staff and people on-call 24/7.

Framing it as just a different "architecture" implies that registries like NPM are making the wrong choices by hosting their own downloads, which I think is not nearly that simple. Because what happens if GitHub or Bitbucket decided to not allow this type of usage? It would be devastating for the community - so I think it's very appropriate for package managers to make a decision about whether or not they also want to be a registry. They're considering what could happen down the road and what that would mean.

CJ's comments on all of this, re: entropic, are really good: https://www.youtube.com/watch?v=MO8hZlgK5zc

Composer is amazing and I'm going to say far better than what I've seen in JavaScript and python world.

Can't we get all that directly from git repos and signed tags?

Wouldn't you just include a file by it's minor version like this:

  import * as E from 'https://cdn.jsdelivr.net/npm/fp-ts@2.5/lib/Either.js';

Whenever you `--reload` you'll get the latest 2.5.x release, no?

This should work out recursively for all the deps if they follow the same pattern, no?

I think there's some confusion here.

NPM is both a massive repository as well as a package manager.

Deno will (soon?) have a package manager, but it won't be tied to one central repository run by a private company, now part of a massive corporation (Microsoft.)

So let's not lump package manager and repository: you can have a package manager that pulls in all the exact or latest dependencies at build time, but it does not have to be tied to one central repository owned and administered by one company.

Centralize-able yet decentralized.

The Deno team recently blessed Pika

https://dev.to/pika/introducing-pika-cdn-deno-p8b

Accruing positive sentiment in the dev community through acquisitions of someone else's nice things. Who came up with that crazy idea? GitHub isn't Microsoft. You can't buy brand loyalty.

VSC has been huge in this regard, too.

I for one appreciate that Microsoft is allowing these dev related acquisitions, such as Github, to maintain an individual brand image. I can't think of anything worst if they decided to reskin/theme these brands to be all Microsoft-y.

> capture a tool/ecosystem that developers liked using and benefit from that positive sentiment

So...appeal to devs, something something, money??

I really like how MS are improving our tools and embracing open source, I really do. But I've never quite understood how the return on investment in these things justify the cost. I just struggle to the an obv big picture here.

I.e. is it incorrect to think of the GH acquisition as mostly an azure marketing expense?

>I once saw some Microsoft guys demo something cool at a conference, and they had to basically apologize that they were from Microsoft

Microsoft, "the people" were never bad. They did a lot of cool things, they had great coders and scientists. The upper management did bad things, and made poor decisions, guys like Ballmer and business strategists.

With the new management things changed a lot and I hope Microsoft will keep up at doing good things.

Not all things are rosy: desktop development with MS tools suck, they changed framework after framework, Windows Forms and WPF aren't cross platform, C++ desktop programming is still Windows only, and not Visual at all. I don't get why the naming: "Visual C++" since QT or C+= Builder are much more "Visual" than MFC and Winapi.

But I guess desktop doesn't bring MS too much money so they don't care enough about it. If that's the case, I don't get why they don't promote and support a third party, cross platform development framework like Uno or Avalonia.

They can, and will have to continue to, thank MS legal for that bad rep..

While Upper Management has lessened some of their excesses, they still tend to be very aggressive in some area's, and time will tell which 1/2 of the company will win. The Open Collaboration group, or the "We want to control the world" group, there is still an internal struggle there

Many believe the "We love Open Collaboration" is just a facade and the "real Microsoft" will revel itself in a few years

I agree with this take. I'm primarily JavaScript/TypeScript developer, doing both front end and back end web app development. Microsoft being a good steward of TypeScript (and now the js ecosystem) inclines me to give C# and .NET Core a shot, and probably Azure down the line.

Yup. There’s a great memo from 1995 describing the web as the next big platform: http://pstella.com/reading/THEWEB.pdf

Looking at the massive growth in frontend technologies within the last decade, it’s easy to see why Microsoft wants to be a little ahead of the curve this time.

I’m less pessimistic. Microsoft has engineers with a business mindset in charge. For now, it’s true. But we saw node vs IO.js — Microsoft can’t afford a fork or they lose their own control. They won’t close open source, they’ll add subscription or cloud usage fees for large enterprises. The value, like GNU “open core” is that open is popular, while enterprise features on the other hand are expensive. The enterprise is being led now by open source because it’s cheap, then value add to solve the problems they still have around control and oversight, etc.

If anything, I expect basic Visual Studio internals will eventually get open sourced as cheaper to maintain that way than Roslyn rebuild-all-the-things. And VS Code will adopt them and continue to cannibalize VS mindshare.

The first word that came to mind was "integration", but I suppose "control" is another way of putting it.

I doubt Microsoft would intentionally degrade developer experience, like "cutting off third-party tools". Rather, they're seeking to gain market advantage from the tight integration of services. It would make sense for them to encourage third-party tools to play well in that "Microsoft ecosystem".

> Pushing to GitHub and publishing to NPM from right within VS Code

That's exactly what I picture coming soon, if not here already. Also: develop in VS Code, click to build, push to GitHub, deploy to Azure.

Ironic really given that Microsoft has the most notoriously insecure products I can think of.

Can anyone point to a technology company that has a larger attack surface or a more fundamentally insecure product?

This is the dream of the token model for networks like Bitcoin, Ethereum or Filecoin / ipfs.

it can be the cost of access

Ubuntu and Debian have mirrors of their apt repositories hosted all around the world by groups, schools, businesses, etc. There is no single point of failure, you grab from the best mirror near you.

I seed several torrents for OSS, it's not much but that's about all I can do to help.

Whatever happened to people hosting things in an old computer in their basement? That used to be a more popular thing back in the days before the cloud came about and before we had these stable broadband connections. Obviously an infra like npm couldn't deliver with such a setup but at scale, who knows

open whisper systems

There are laws, non-profits executives & boards must follow, but there is nothing stopping any of the non-profits you listed from selling any assets you listed with them as long as doing so is in the best interest of the nonprofit; which at best is a subjective topic, at worst, easily dismissed given properly crafted pretext & reasoning.

Generally speaking, much like for profits, it is the people that run it that decided its culture, not a legal structure.

Are you interested in mitigating risk by reducing central dependencies? I am. But it's too costly right now.

All being equal, though, we should try to avoid technical systems with unnecessary trust relationships and critical concentrated dependencies, though.

And if we must have a concentrated dependency, we should do our best to pick very trustworthy ones-- both based on their track record and their likely future interests relating to organizational structures.

From my own attempts at developing a decentralized service I've learned that there is no free lunch. Consensus is still unsolved without resorting to a nuclear option like a blockchain. Federation is a far better strategy. Let people host their own instances and let instances interact with each other.

I feel like bootstrap and jquery stand a decent chance of being caches in a large enough portion of the user base.

And even ignoring my user's bandwidth, it would still save me significant bandwidth (depending on the size of my website).

I guess eventually your site might grow such that your dependencies are not a significant portion of your total download size, but I am not currently there.

In which contexts should I use CDNs and why am I otherwise better off with NPM?

It's called Typescript

He didn't say which developers though. Arguably, Office and enterprise developers have been served fairly well even during his tenure. As long as you colored between the lines, the experience was alright.

Isn't that kind of the point of the GitHub Package Registry?

Because open source has always been defined in its very definition by its definition to the for-profit software industry, which Microsoft basically invented? Because in spite of having made a turn towards open source, Microsoft once treated it like a mortal enemy, akin to cancer? Because of how other large companies like Google have smothered open source projects?

I'm personally not worried about the acquisition (I think it's a net positive for the community), but there are plenty of reasons to discuss this interaction.

Yep. IMHO if Google would want to make a move here, now would be a good time. And as the creators of Kubernetes, they have some nice incentive to try to stay relevant.

MS gobbling this one up would not be a big surprise.