3 ms·
About a decade or so ago, I found the way free and open source software was used in commercial projects seemed to better align with the warranty disclaimers of
by susam 3y ago
About a decade or so ago, I found the way free and open source software was used in commercial projects seemed to better align with the warranty disclaimers of the open source licenses. For example, I remember in a C++ project I worked on back then, every single dependency was committed along with the project. Today this practice is known by the term "vendoring". And, yes, there was no supplier.
To illustrate my point, let us consider the case of Net-SNMP which was one of the projects I had direct experience with back then. We had the entire source code of Net-SNMP checked into our own project repository. From that point on, it was our responsibility to understand/maintain/update/upgrade/patch/customise the code (at least the parts that we relied on). When something didn't work the way it was supposed to, it was one of the employer's developers responsibility to figure out how to make it work. If needed, sometimes we would even engage with the community around the project in their IRC channels or mailing lists, to figure out how to solve our problems and sometimes such engagement might even end up benefitting both the community and us.
But at no point there was the notion of a supplier or "they" or "them". It was always "we". We decided to take this gift called Net-SNMP. We decided to use it develop our software. So it was now our responsibility to keep it in good shape. After all, the employer's developers were getting paid for it.
Now I know in today's world of software engineering, it is no longer possible to tend to every single dependency that is pulled into a project. There are thousands and thousands of them in every project. The way software engineering is done today is vastly different from how it was done a decade or two ago. There has been a Cambrian explosion of programming languages, open source software, frameworks, ecosystems, etc. It is impractical to assume the ownership of the thousands of dependencies that get pulled into every project and I think this is why the notion of "they" or the mythical "supplier" implicitly creeps in. While this rising complexity has resulted in increased speed and agility of software development, we have lost the simplicity and clear sense of ownership of code we rely on, which I believe was more prevalent a decade or so ago.
- ChrisMarshallNY 3y agoThanks for that. It is pretty much the way that I look at things. It was also the way that the company that I worked for, did things. They would never have blindly relied on some outside supply chain. In some cases, we were only given opaque binaries to add (licensing/contract stuff), but we checked that binary into CM, and it was part of our product. Testing, calibration, accountability, etc., was all on us. If the vendor software failed, it was our failure, and we were Responsible for fixing it (which may have consisted of frantic calls to the vendor). We also did not add any free software. Indeed, we actually paid a company beaucoup bucks, to scan our software, and let us know of any unlicensed software. It was really important to establish full provenance of every line of code in our products. We had good lawyers.
- vsnf 3y ago> We also did not add any free software What does this really mean? Did you use some paid language/compiler ala Borland? Did you write all your own libraries? Without huge resources, like an intelligence agency or multinational, I don’t see how it’s possible to not use any free software. Unless these stories take place 30 years ago or something.
- dartos 3y agoI’m working somewhere now where we’re building everything above the network transport layer from scratch. We just built an in memory IPC and rpc protocol on top of UDP. You can just do that. It’s not as easy to use as grpc+protobuf. Probably not as fast, almost certainly not as correct, but you can do it.
- couchand 3y agoMore half-broken solutions is not the answer...
- 01HNNWZ0MV43FF 3y agoIf it's not as fast or correct... Why?
- Dalewyn 3y agoLiability.
- dartos 3y agoIMO the CTO hasn’t written production code since 2008 and doesn’t know about what modern software dev is like. He dreamt up a system which is basically AWS lambdas, but calls to services are abstracted by wrapper classes so it doesn’t _feel_ like you’re making a network call. Also, I think he just ignores what he doesn’t understand. I asked what he was thinking about using for our front end and he suggested using wisel, which is a proprietary, mostly unknown, C# to html+css+js package. He said it “paints widgets directly on the page from c#.” He believes that html+css+js is too complex, so ofc adding C# and a JSON style format that approximates css to the equation will make things simpler.
- madsbuch 3y agoI just wrote a report on open innovation, and I explicitly brought up this development - going from having to implement everything in house (before effective internet) to vendoring to the external dependencies we have today. While it is definitely unfair to require an independent open sourcing developer to maintain there software free of charge I really like the idea of deferral of not just the knowledge embedded in open source code, but also the maintenance. The success stories are probably big companies who open source business supporting elements of their stack. Like Meta with React: People can use react and Meta maintains it. On the other hand they benefit from other big companies sharing parts of their stack.
- lifeisstillgood 3y agoIt not only is possible to vendor all the dependant code, it is (under executive order dum de dum de dum) required to provide a software BOM in USA (and by extension more or less everywhere) Most companies think that they can outsource this to say Tidelift and just keep treating it as a free gift from the global community But as long as there is not a precise definition of your software stack (I am thinking something like nix plus repeatable software builds) then there is nothing the global community can do (because unless we know your stack precisely who can say what vulnerabilities exist) I think there is an interesting new industry - software dependency provision - imagine being able to define the complete set of software, where and how it was compiled, probably using something like nix.