Hacker News new | past | comments | ask | show | jobs | submit login

New to web dev. New to node. Looks like a complete mess to me, deserves criticism, as does much of the web dev ecosystem.

Package maintainer should indeed have found someone to pass it onto (see Cathedral & the Bazaar). And that doesn’t include the first person he’s never heard of stepping up.

BUT this applies to all package managers, maintainers, and OSS at some level.

The idea that say a startup has time to audit every line of every dependency is absurd. Even a big business can’t do that. The idea that you “don’t have to trust” the authors is untrue, in the current workflow. FOSS relies entirely on trust.

I’m not convinced FOSS is even a good idea at this point, but with the advent of widespread cyberwarfare we need to either introduce a sophisticated accompanying trust model, or exclude FOSS when working commercially.

This is a business opportunity. Audit FOSS and sell your audit guarantees in a contract. Offer services to audit more recent versions on the proviso that you can sell that audit elsewhere.

This will have the incidental benefit of encouraging clean software to be written in languages that minimise audit costs, as those projects will get used more.

Some commercial arbitration of FOSS now looks inevitable.




> The idea that say a startup has time to audit every line of every dependency is absurd. Even a big business can’t do that.

This may sound strange, but once tech companies actually had to either write or buy all of their software, and if they didn't have a contract in place that made someone else responsible for its quality, they were. So, basically, the world was absurd.

The way FOSS works is if users agree that a common good is important enough to invest in, and then they all benefit more than they would if they invested alone; it's anti-competitive. Free (and Open Source) software should be thought of as "free as in beer" i.e., the next round is on you. If you can't audit every line, audit some of them, or pay someone else to do it. Coordinate to get code coverage. If you use a project that is inadequately covered, you're responsible for everything that goes wrong.

If you don't even know what libraries your project depends on, how could that ever be thought of as anyone's fault but your own?


> Coordinate to get code coverage.

This may be a central part of the issue. It's a coordination problem and creating common knowledge.

Each corporation might be willing to pay to have some bits of their dependencies audited as long as others cover other pieces. But to do that they need to be able to announce the audit result and scan their dependency trees for pieces that are not audited and pick from those. You'd also need some common standards what constitutes an audit and the lawyers would probably want some limits on liability so results should be considered as best-effort or whatever.

There are no conventions and social protocols in place to support this.


I might be missing your point or simply have a hard time understanding this anti FOSS rethoric.

I'm reading that you'd pay a third party so you can trust open source code and think that FOSS somehow exposes commercial code to more risk in some kind of cyber warfare? How is that not complete FUD? You already have the option to pay vendors like redhat for many open source software components if liability is your only concern, the same is true for many of the more complex libraries out there.

Closed source on the other hand would mean buying every single piece of code or paying in house devs to write that code. I get the quality concerns raised here up to a point but just because a company paid somebody to write something doesn't mean it's not effectively written by a solo dev under heavy time constraints. Except with FOSS you at least have the chance to go in and inspect/fix the thing yourself if needs be.


Two things:

1) The PC software world did run for quite a few years on the model of predominantly commercial/proprietary software, most of it being closed-source, so it's not like it is some far-fetched idea that doesn't work in economic terms.

Personally, I prefer the commercial license/source-included model, with the emphasis on the author/company getting paid to ensure that the situations like the one described here are avoided. You can then have additional educational licenses for ensuring access to developer tools for educational purposes, but that's up to the author/company.

2) If you directly pay someone to write software, I would expect any such arrangement to include the source code as part of the work product, regardless of the ultimate visibility of the source code to outside parties.


The history of cryptocurrency in particular and business law in general shows that adding money to the system doesn't automatically result in trustworthiness. Even the giant corporations providing cloud computing do decide to abandon products and discontinue services, or dramatically raise prices.

As someone else suggested, maybe the way to go is to rely on foundations. Maybe individuals shouldn't be taking on the burden of maintaining software alone? Maybe JavaScript needs a more slow-moving organization like Debian to handle package integration, with all the bureaucracy that entails?


Absolutely - adding money doesn't automatically result in trustworthiness. What it does do, however, is make the transaction fall under legal commerce, which gives the purchaser/user rights and remedies that they do not have with free (as in cost) software.

With foundations or any other form of over-arching bureaucracy, you risk stultifying software developers and harming innovation. It's really, really hard to beat the self-organizing aspects of free markets combined with commercial legal frameworks.


Well okay, but these aren't opposites. Large businesses cooperate internally using bureaucracy. They cooperate externally using (and funding) foundations and other open source work.

There is market demand for stability and it can be a competitive advantage over innovative but unstable alternatives. (Consider why Go and Docker are so popular.)

And why do companies start and fund foundations? Because their customers have doubts. It's better for stability than a market that's not based on standards.


Do you have any rights with paid devices? A kindle comes with 8 hours, 59 minutes of disclaimers

https://www.youtube.com/watch?v=sxygkyskucA


>The PC software world did run for quite a few years on the model of predominantly commercial/proprietary software, most of it being closed-source, so it's not like it is some far-fetched idea that doesn't work in economic terms.

And now Microsoft uses linux on the majority of their own cloud offerings. Open source beats propriety software on economic terms a lot of the time. It doesn't matter that both can work in economic terms, it matters which one is better in economic terms.


I don't think this book has been completely written yet. I think we're just now starting to see some of the major issues with FOSS, so don't throw up that "Mission Accomplished" banner yet.

FOSS is very much like the internet, in general: it was great when it was a small group of technical, like-minded, dedicated individuals working towards common goals. It starts falling apart, however, once you introduce the rest of the world into the system because the world primarily works on the basis of ruthless self-interest.


FOSS was going nowhere until the rest of the world got introduced to it. It was of more or less purely academic interest for a very long time.


TANSTAAFL. You're literally getting the source code for free. I agree that it absolutely makes sense to pay a third party to audit your dependencies if you can't do so yourself. The alternative is to restrict yourself to code from a source you trust implicitly.


> The idea that say a startup has time to audit every line of every dependency is absurd. Even a big business can’t do that.

Big business absolutely do that. Code quality review, security review, legal review. Every line of every 3rd party dependency.

Of course, for the most part big business doesn't take 3rd party dependencies. If you have a big enough software org, you write everything above the std library in-house. Why do you think so many of the big open-source frameworks are vended by big 10 tech firms?


> Big business absolutely do that.

If would be true somebody would have noticed this hack before. Has been online for 2 months and they only found out because of a deprecation message.

> Of course, for the most part big business doesn't take 3rd party dependencies.

I worked for many big companies, definitively they use 3rd party deps.

> std library in-house

And that contains 3rd party deps.

Big companies have some 3rd party to check the libraries but it looks like they are not good enough because they didn't catch this one.


Maybe this particular dependency just isn't used by many big firms?

I've had to go through code, security, and legal reviews at both Amazon and Facebook when desiring to import 3rd party libraries. They were fairly thorough.


> Audit FOSS and sell your audit guarantees in a contract

Pay Redhat enough and they will do that. Although you will be limited in what you can use.


Don't know why you're being downvoted, because Red Hat does indeed audit all of the code we ship in RHEL (and believe me it's pretty tedious). We don't ship much in the way of Javascript libs though.


> The idea that say a startup has time to audit every line of every dependency is absurd.

I kind of agree, but remember you are getting free software. Not a little, but a ton of free software and you feel like somebody should guarantee all works fine.

Choices:

- See what is going on in all your deps and waste a lot of time - Risk it and use the software without knowing what is doing - Pay somebody to guarantee that the software is not malicious


> Package maintainer should indeed have found someone to pass it onto (see Cathedral & the Bazaar). And that doesn’t include the first person he’s never heard of stepping up.

WITH NO WARRANTY.

Do you not understand what this part of the licensed mean?

Mainter doesn't have to do shit. That is the point.

You want to start putting arbitrary ethics and morals on these developers? The "Fuck you. Pay me." talk comes to mind.

FOSS works fine like this and has been for a long time.

We're seeing issues now because of nodes lack of a standard library. Not trust and certainly not instead issues with free and open source software.


It sounds like you haven’t read the Cathedral and the Bazaar, which really is one of the founding documents of OSS, and it does indeed encode ethics in its motivation. Recommended reading.


Lack of standard library only makes the trust issue manifest with more hilariously basic libraries, instead of more slowly with the libraries. We've still seen this in Python, the poster child for batteries-included.


I think it's been said elsewhere, this is true but the frequency and severity is orders of magnitude less with the languages with good standard libraries.

When the entire ecosystem depends on left pad I think you have a problem.

When the entire ecosystem depends on express it is less of an issue because more eyes are invested in auditing it and changes are more widely reviewed.

You think a nefarious leftpad function would make it's way into express? It could, but it is way less likely.

Updating the dependency to a newer version of left pad isn't going to raise an eyebrow. And that is the issue.


> I’m not convinced FOSS is even a good idea at this point, but with the advent of widespread cyberwarfare we need to either introduce a sophisticated accompanying trust model, or exclude FOSS when working commercially.

So, you are saying that we should prefer code where it is impossible to have a look at the source because that solves the problem of having to trust the developers of that code?


No, the point is that in practice FOSS code is not any more open than closed source.

That's the point of this piece. For any non-trivial edit on a real project with real deadlines the source code is effectively useless, because no one has the time, the resources, or possibly even the inclination to fix bugs, do full-coverage testing, or make custom modifications.

So you have to take the internals on trust. Which is a ridiculous situation when so many packages are created as hobby projects with - literally - no guarantee of performance or reliability.

I realise it's hard for FOSS advocates to understand this, because it's a fundamental flaw with the FOSS philosophy. The benefits are "obvious" to crusaders, but the objective reality is that large swathes of FOSS are full of casual or hobby code that barely works, has gaping security vulns, and/or is nowhere close to being robust enough for production.

"Make software simpler" is a good goal, but hard to do. Other solutions are also possible. They're hard too. So it goes.

But there will be no solutions at all until the FOSS community starts dealing with professional reality instead of relying on free-to-tinker-without-consequences rhetoric - and understands that there are real problems that need real answers, and not just more "Clap Louder" and "At least we're not Microsoft".


Most widely used oss projects are not hobby projects. Only small trival projects tend to be hobby projects. Notably, apache projects are not hobby projects per foundation requirements.

Quite a lot of contributions are need driven - client project needing something digging into code and fixing it. It is called "scratching own itch". The reason for popularity of oss libraries was that comertial ones had historicall low motivation to improve after point of sale, especially when it comes to performance. That is why you see a lot of oss targeted at developers and very little at general public. Closed source libraries were unable to compete not just because of price, but because business of selling libraries does not value quality.


> No, the point is that in practice FOSS code is not any more open than closed source.

You seriously believe this? I mean, it's so obviously nonsensical I can hardly believe you are seriously making that point. With FOSS, you have the option to look at the code, with closed source you don't. And you are seriously saying that that is the same level of openness?

Also, even if it were true: How is that relevant? FOSS is just as bad as closed source, therefore you should exclude FOSS? How does that follow?!

> So you have to take the internals on trust.

So, I can not look at FOSS code? Like, you are telling me it is impossible for me to look at the code that I am in fact looking at when selecting code to use for something? I mean, really? That is your point?

And the solution then is to not use FOSS, because then you don't have to take the internals on trust?


Their point is, clearly, that to the end user, code they cannot understand is for all practical purposes no different than code they cannot view.


Code I cannot understand, I can ask for help with understanding. Code I cannot view, I cannot.


That's true. But most people using free software can't simply ask for "help understanding" millions of lines code written in possibly multiple languages. Like a lot of the axioms of FOSS, the utility of that breaks down at the scale of modern software.


But for one that still doesn't mean that not being able to view the code is somehow better, as was claimed above, and which I objected to. At best that means that being able to view the code does not necessarily imply the quality of that code is better. Which really is just obvious.

And also, that does not at all mean that the utility breaks down. Back in the day, it was normal for devices to come with schematics. Like, if you bought a TV, the schematic was included. Almost noone who owned a TV could read schematics. But the schematics were still useful to the owner, because those schematics were what enabled you to take your broken TV to any independent repair business of your choice and have them fix it at a competetive price.

You can profit from the wide availability of knowledge without having to learn it all yourself. If there are ten competing car repair businesses in your city that all understand how to fix your car, that is better for you than the manufacturer having a monopoly on repairing your car, even if you don't have the slightest clue how your car works.


I think you have pretty much proved his point.

>I realise it's hard for FOSS advocates to understand this, because it's a fundamental flaw with the FOSS philosophy. The benefits are "obvious" to crusaders, but the objective reality is that large swathes of FOSS are full of casual or hobby code that barely works, has gaping security vulns, and/or is nowhere close to being robust enough for production.

>And the solution then is to not use FOSS, because then you don't have to take the internals on trust?

I think the point is to realize FOSS is not a utopia and has tradeoffs like everything else.


> I think the point is to realize FOSS is not a utopia and has tradeoffs like everything else.

But that wasn't what this thread was about. The statement that I was responding to above was this:

>> or exclude FOSS when working commercially.

I.e., that there isn't a tradeoff, but that the solution to shortcomings of some FOSS that aren't unique to FOSS in any way is to not use FOSS at all.

And that was then defended using equally nonsensical logic.

So, noone here is claiming that FOSS is utopia. But people are implying that proprietary software is. Which I am asking people to justify. So far, nobody did.


No, I think what people are implying is that commercial licensing of software solves the trust/responsibility aspect of software. With proprietary software, there are legal remedies to malfeasance.


In which case that is still both obviously nonsense and irrelevant on two counts.

It's irrelevant because this was about FOSS vs. closed source, not about commercial licencing vs. noncommercial licencing. Even if commercial licencing were the solution, that says nothing about whether the commercial licence should be FOSS or closed source.

And it is also irrelevant because there are broadly the same legal remedies to malfeasance in all cases. If you are breaking the law, you are sill breaking the law if you are publishing your source code, and you are still breaking the law if your are doing it non-commercially.

And in so far as you mean liability for defects rather than malfeasance, it is obviously nonsense that there are any generally applicable effective legal remedies against terrible proprietary code if you look at the real-world quality of products in the market. You might be able to put together a contract that helps with that, but (a) that is far from the norm and (b) is obviously still irrelevant to whether the code should be open or closed.


1. Commercial does not imply closed source.

2. It’s about legal responsibility and recourse.


> 1. Commercial does not imply closed source.

How is that relevant?

> 2. It’s about legal responsibility and recourse.

How is that relevant?


You pay for the software, you get the source. I gather this used to be the default distribution method, and I think it still gets used for game engines.


> you are saying that we should prefer code where it is impossible to have a look at the source

Just because not everybody has access != a person inside a gated area doesn't get to see. You made that leap.

If you are building software on top of software that carries no guarantees then you are liable unless you also somehow make no guarantees. Are you able to sell software without guarantees? Maybe?


> Just because not everybody has access != a person inside a gated area doesn't get to see. You made that leap.

Well, I guess that was somewhat of a leap, but it doesn't really make a difference to the argument: The point is that they are suggesting that preferring code that fewer people can look at somehow solves a problem.

> If you are building software on top of software that carries no guarantees then you are liable unless you also somehow make no guarantees.

Well, yeah? But what does that have to do with FOSS? Neither does FOSS imply that there are no guarantees, nor does proprietary software imply that there are guarantees. Hence: What is the relevance?

The only difference between FOSS and proprietary software in this regard is that with FOSS you have the option to do an audit yourself and offer guarantees on that basis without creating a huge unknown risk for yourself, or you could possibly buy auditing services on the free market that come with some sort of guarantee from a third party. There is no option that you have with proprietary software that is somehow impossible with FOSS, which is why the suggestion that not using FOSS for commercial projects somehow solves a problem is strange at best.

> Are you able to sell software without guarantees? Maybe?

Well, given the tons of massively broken proprietary commercial software out there? Yeah, obviously you can?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: