Even if your code is better than the OSS alternative now, are you going to be able to maintain it at that level, given all of your other responsibilities?
If someone was able to produce better code in some way before, despite any OSS alternatives available at the time, why would anyone assume they could not also maintain and develop that code more effectively than the same OSS community and projects in the future? That makes no sense.
A lot of developers seem to make dubious assumptions today about the quality of something they could import compared to the quality of what they could build in-house. There’s little reason or evidence to support a lot of those assumptions, but people continue to make them regardless, because hype and inexperience are things.
If you’re talking about a huge OSS project with many contributors, quite a few experts involved, well-established infrastructure and funding, and so on, then sure, it’s a tough thing to beat. I couldn’t set up and maintain a new operating system with the same capabilities as something like Debian or FreeBSD, and neither could any other small team.
But most OSS isn’t like that. Lots of OSS projects have only a single main developer, or maybe a small team of contributors, and those people may or may not be as skilled, experienced, dedicated or simply available as your in-house team. Lots of OSS projects effectively get abandoned, sometimes even well-known ones with lots of contributors, major commercial backing and a large user base. Lots of OSS projects are highly unstable, and if you depend on one that needs constant updates to keep it working, that’s an overhead of its own. There is precious little evidence that OSS quality is better in general than something a good team could have built in-house.
And even if none of those things were true, your own in-house development would still be focussed on your specific needs and priorities, instead of trying to be a generic tool with potentially a lot of functionality (and risk) you don’t need, and potentially being steered in a future development direction than doesn’t meet your needs as effectively.
Don't write it unless you intend to own it.
The flip side of that is that if you do want to own it, writing it in-house may well be a better option.
Obviously there has to be a balance, and reinventing the wheel (or a sports car) for every project isn’t necessarily a good use of time and resources. Bringing in a good external tool or library that solves a problem for your project effectively can be a huge win, particularly if it’s in an area that isn’t a core part of your own project.
However, I believe the current culture in some parts of our industry is crazily biased towards bringing in external libraries to do every little thing. That is a very dangerous trend that we must challenge, because we’re writing an awful lot of awful software as a result.
True, but Javascript libraries tend to be pretty small and deal with well-known concepts. Many experienced dev's have seen a router 10x by the time they've come to React-Router, and the entirety of the source code can be read in a single day.
If you both (a) have experience and (b) have read and understood the entirety of a library, then you are in the best position to claim that you can do it better in house.
The prevelance of libraries doing the same thing in Javascript shows that alot of people have different ideas, and due to culture decide to open source it instead of keeping it in-house.
Other communities do the reverse. There are probably a million homebaked Java frameworks that will never see the light of day because people in Java land don't think that MVC is so extra ordinary that they need to release their in-house needs specialized framework.
One of the weaknesses of Javascript is its absolutely terrible standard library. In comparison to languages with solid, comprehensive, "batteries-included" standard libraries, you spend a lot of time re-implementing basic functionality. Or you import jQuery, or LoDash, or underscore, or use pieces of Ember or Angular, or React, etc, etc. Or some bastard abomination of all of those.
I'd argue that's a strength. Note how scala is modularizing its standard lib in Dotty, and TypeScript is doing that same for stdlib typings.
Standard libs are great, but they need to be modular. If they're modular then they are versioned separately from the language, and at that point there's no difference between a well specified and maintained lib (eg lodash) and a stdlib.
>> Don't write it unless you intend to own it.
> The flip side of that is that if you do want to own it, writing it in-house may well be a better option.
An unspecified question is "What is the cost of ownership?" (which you alluded to in discussing the size of the project.) I've written plenty of code that could have been replaced by a library. I've put out OSS projects that I actively discourage people from using because the function of the library was so straightforward that its just not worth the dependency (even if its my own, completely flawless code ;) ) Moreover, in most of these cases the code churn even over several years is almost zero. That's a metric that should be looked at a lot more often when evaluating dependencies.
To your point, the cost of ownership is completely negligible in most cases, and all developers are doing by including a new dependency is saving a small amount of time up front with a heavy backside cost.
If someone was able to produce better code in some way before, despite any OSS alternatives available at the time, why would anyone assume they could not also maintain and develop that code more effectively than the same OSS community and projects in the future? That makes no sense.
A lot of developers seem to make dubious assumptions today about the quality of something they could import compared to the quality of what they could build in-house. There’s little reason or evidence to support a lot of those assumptions, but people continue to make them regardless, because hype and inexperience are things.
If you’re talking about a huge OSS project with many contributors, quite a few experts involved, well-established infrastructure and funding, and so on, then sure, it’s a tough thing to beat. I couldn’t set up and maintain a new operating system with the same capabilities as something like Debian or FreeBSD, and neither could any other small team.
But most OSS isn’t like that. Lots of OSS projects have only a single main developer, or maybe a small team of contributors, and those people may or may not be as skilled, experienced, dedicated or simply available as your in-house team. Lots of OSS projects effectively get abandoned, sometimes even well-known ones with lots of contributors, major commercial backing and a large user base. Lots of OSS projects are highly unstable, and if you depend on one that needs constant updates to keep it working, that’s an overhead of its own. There is precious little evidence that OSS quality is better in general than something a good team could have built in-house.
And even if none of those things were true, your own in-house development would still be focussed on your specific needs and priorities, instead of trying to be a generic tool with potentially a lot of functionality (and risk) you don’t need, and potentially being steered in a future development direction than doesn’t meet your needs as effectively.
Don't write it unless you intend to own it.
The flip side of that is that if you do want to own it, writing it in-house may well be a better option.
Obviously there has to be a balance, and reinventing the wheel (or a sports car) for every project isn’t necessarily a good use of time and resources. Bringing in a good external tool or library that solves a problem for your project effectively can be a huge win, particularly if it’s in an area that isn’t a core part of your own project.
However, I believe the current culture in some parts of our industry is crazily biased towards bringing in external libraries to do every little thing. That is a very dangerous trend that we must challenge, because we’re writing an awful lot of awful software as a result.