NIH is amazing as long as you are realistic about what you are taking ownership of.
For example, the cost of maintaining a bespoke web frontend "framework" that is specific to your problem domain is probably justifiable in many cases.
The same cannot be said for databases, game engines, web servers, cryptographic primitives, etc. If you have a problem so hard that no existing RDBMS or engine can support, you should seriously question the practicality of solving your problem at all. There's probably some theoretical constraint or view of the problem space you haven't discovered yet. Reorganizing the problem is a lot cheaper than reinventing the entire SQLite test suite from zero.
f4c39012 · 12m ago
i can think of two reasons for using a third-party dependency
1) a dependency on a third-party service provider that publishes the dependency. So long as that service provider is current, the dependency should be maintained
2) short-cut to code i don't want to write
I have no arguments with (1), there's a business reason and the lifecycles should match. However, I should still expect major version breaking changes in order to keep my application running. For (2), the wins are less clear, more dependenent on the perceived complexity of what I can avoid writing.
Taking on any kind of dependency means that someone else can dictate when I need to spend time updating and testing changes that don't add anything to my product. Taking on a third-party dependency is always taking on a responsibility to maintain a codebase or the risk of not doing so.
abbotcabbot · 38m ago
> Reorganizing the problem is a lot cheaper than reinventing the entire SQLite test suite from zero.
Sure, but if you aren't happy with existing DBs you are probably wrong in thinking you need a general DB instead of a file layout on a filesystem.
AstralStorm · 19m ago
It seems easy, but actually managing files as a database safely is actually very hard. Especially ensuring atomicity.
Portability is a problem as well.
You do not need an SQL database however, there are others available.
bob1029 · 3m ago
The technology is only part of the problem. If you aren't happy with any existing database, throwing even more technology at it is definitely not going to help - statistically speaking. You're up against millions of engineering hours in this space.
At some point, we need to get up from the computer and go talk to the business and customer about their problem in terms that don't involve anything more sophisticated than excel spreadsheets. There is definitely some aspect you missed if you think you need to build a fully custom technology vertical to get them to pay for a solution.
Of course, all of this advice is pointless if what you are doing is for amusement or as a hobby. I think a lot of arguments about technology would be diffused if we prefaced with our intended applications.
devjab · 2h ago
Being in the energy sector dependencies is something we intentionally avoid because we'd actually have to go through and review changes. What has helped this immensely is AI code assistance. One of the primary uses is to use it to write CLI tools for code and config generation in the tool chain. All of it is around making your life easier, without pulling external dependencies.
An example is that we create openapi docs with LLM's. Then we serve them with Go's net/http + FileServer, meaning that we never leave the standard library. Of course the LLM itself is a third party dependency, but when you use it to write CLI tools that then do the code generation, it never actually sees the code. That also means that the quality of those CLI tools are less important, because it is their output that matters.
It only goes so long of course. I'm not sure any of our front-end engineers would want to live in a world where they weren't allowed to use React, but then, their products are treated as though they are external anyway.
Anyway, it's a lot easier to make engineers stop using "quality of life" dependencies when you give them something that still makes their lives easy.
landgenoot · 1h ago
Doesn't the LLM spit out the code of the dependency it has been trained on?
How is that any different from just forking the dependency and treating it like your own?
smokel · 1h ago
One advantage might be that you would only implement the (small) part of the library that you actually need, potentially avoiding bugs such as Log4Shell.
The risk of code duplication is a serious one though, and it would be nice if AI could automatically detect and clean this.
I guess we are in an annoying "in-between" state of things, with a pretty unsure future.
nurettin · 29m ago
You would (probably) be avoiding commonly known exploits while introducing subtle AI-induced bugs like printing logs out of order or not locking/ordering resources properly.
fmajid · 27m ago
Dependencies introduce risks, but not using them at all puts you at a competitive disadvantage against those who are using them and thus achieve faster development time and time to market.
What you need is a process to manage dependencies:
1) Only consider open-source dependencies.
2) Introducing new dependencies requires a review. Not just a code review on the pull request introducing it, but checking the license, estimating how much work it would be to rip out, auditing it for history of security vulnerabilities or bugs, whether it is live and still gets updates, how vibrant the community is, and so on.
3) If possible, review your dependencies for possible security issues. Doing this at scale is expensive and the economics of this are still an unsolved problem (I have my ideas: https://blog.majid.info/supply-chain-vetting/).
4) Do not adopt a dependency you are not willing and able to take over the maintenance of, or fork if necessary. At a minimum, it means you have built it from source at least once, not just used binary packages maintained by someone else.
5) Preemptively fork all your dependencies. People can and do delete their repos out of pique, see left-pad.
lmm · 2h ago
People love to claim this, especially on this site, but in my experience it's the opposite. Many people like writing new code and will do it even when it's detrimental to the business, but 9 times out of 10 even using a "bad" dependency is far more effective than writing in-house.
freetime2 · 2h ago
Can I ask how seriously your company takes security vulnerabilities and licensing? I used to have a pretty lax attitude toward dependencies, but that changed significantly when I joined a company that takes those things very seriously.
lmm · 2h ago
I've worked with many companies over the years. License management should be automatic or mostly-automatic if you're taking dependency management seriously (particularly these days where so many projects use well-known open-source licenses and everything is machine-readable metadata), and I've never seen a single in-house codebase (even at e.g. F500 financial institutions) that took security more seriously than your average open-source library.
friendzis · 57m ago
Dependencies are a double-edged sword.
Most vocal people work on "disposable" end of software. It's cheaper for software giants to just throw engineer-hours at rewriting piece of code that has fallen into organizational obscurity than to maintain (hehe) maintainability. There is usually no sense for small branding/webshop factories to churn out high quality, maintainable code.
However, I suggest you revisit the reason why the dreaded "enterprise patterns" exist in the first place. The main reason to use these architectures is so that five years down the line, when documentation is badly outdated, there is no organizational memory left behind that component, original developers have transitioned to either different teams/departments or left the company altogether, the component is still well isolated, analyzable and possible to work on.
Introduction of external dependency(-ies) carry two inherent business risks: either support for dependency will be dropped, meaning you will have to either absorb maintenance burden yourself or switch dependencies, or it will introduce breaking changes, meaning you have to stick to unmaintained version or update your product code. Both situations will eventually impact your feature flow, whatever it is.
Compromise between trunk and leaf (push of dependencies vs pull of deps) is intrinsic to modularization and is always there, however with internal components this compromise is internal, rather external.
> Many people like writing new code and will do it even when it's detrimental to the business, but 9 times out of 10 even using a "bad" dependency is far more effective than writing in-house.
If you are a SaaS company - most probably yes as it is the short-term outcome that is determinate of business success. However, if you work in any industry with safety and support requirements on software or put the burden of long term support on yourself, long-term horizon is more indicative of business success.
Remember, writing new code is almost never the bottleneck in any mature-ish organization.
xupybd · 2h ago
The author is from New Zealand. You have to understand the Number 8 wire[1] mindset the has taken root there to put this in context.
I think just about every experienced developer I know - most of whom are not from NZ - would agree with this article. We've all been burned by using the wrong dependency for the job at some point, or the pain of having to deal breaking changes when upgrading a library that really wasn't necessary to use in the first place.
ironmagma · 2h ago
To push back on this article's thrust, those are actual issues that can occur with dependencies. It's just that they usually don't, and most dependencies are harmless, small, and transparent, so articles like this and people complaining about dependencies are almost always overstating their case.
And therefore, adopting a "zero dependencies" policy is absolutely an overreaction.
makeitdouble · 1h ago
I'd argue harmless, small and transparent dependencies are the easiest to avoid. The extreme of it "is_even", but any library that could fit in 200 lines should probably be owned code.
Where the article hits is critical libraries that you heavily rely on and that your code is slowly formatted around. I'm thinking specific data parsers, fancy query brokers, time management libraries etc.
freetime2 · 2h ago
I don't think the author is actually arguing for zero dependencies here. While they do quote a "zero dependency policy" in one open source project as being "instructive", they also propose a "framework for evaluating dependencies" - which of course anyone advocating for zero dependencies would have no need for.
xupybd · 2h ago
As a developer from NZ I agree
jashmatthews · 30m ago
Purely vibes but as a Kiwi I feel like Number 8 Wire mentality has been dead for at least 20 years now.
bitwize · 2h ago
TIL. I'm reminded of the Australian "She'll buff out, mate" meme.
barisozmen · 4h ago
Completely agree. It's one of the most important skills to know which dependency is good and which is bad.
My two cents. If a dependency is paid, than it is usually bad. Because the company providing that dependency has an incentive to lock you in.
As well, paid dependencies usually only have one source of support, and when the company goes under or stops supporting the product you are in rough seas.
Given very few companies last forever, you have to assess if the trajectory of your project would be impacted by being coupled to their ability to support you.
barisozmen · 3h ago
Exactly. That's another point
AdieuToLogic · 3h ago
> My two cents. If a dependency is paid, than it is usually bad. Because the company providing that dependency has an incentive to lock you in.
Vendor lock-in is a risk for both purchased components and FOSS ones where the organization is unwilling to assume maintenance. The onus is on the team incorporating third-party component(s) to manage their risk, identify alternatives as appropriate, and modularize their solutions.
7402 · 2h ago
If a dependency is paid and it is bad, then maybe you just aren't paying enough for it.
If my code has a dependency then I want there to be people whose feel it is their job to support it.
Either there have to be enough people who are paid to support it, or there have to be enough people whose self-worth and identity is so wrapped up in the code that they take it as a point of honor to support it.
I don't need a company that's likely to abandon a code product and leave me hanging. I also don't need a free software author who says "bugs are not my problem - you have the source, go fix it yourself." If those are my choices, I'd rather write it myself.
jmcgough · 2h ago
I've experienced some bad paid dependencies forced on us by a non-engineering team. I've had a few good experiences with "open core" kinds of dependencies that are widely used by the community, e.g. sidekiq, and therefore less likely to suddenly vanish one day as they would almost certainly get forked and maintained by others in the same boat.
The upside of paying for something is that, assuming the owner or company is stable, I don't have to worry about some unpaid solo maintainer burning out and never logging back in.
RossBencina · 50m ago
> assuming the owner or company is stable
and continues to be stable for the lifetime of your product.
eviks · 16m ago
> Sometimes it's easier to write it yourself than install the dependency...
A few examples wouldn't hurt...
> Their breaking changes can trigger expensive re-writes of your own code to handle a new interface.
Don't update them or NIH-update them just like you'd do with the original NIH code. Still a net win in saving the time for the initial coding
> You need to ensure they end up on your clients' machine.
Vendoring exists?
Tractor8626 · 1h ago
You can tell it is written by C programmer because they think installing dependencies is hard.
mrheosuper · 25m ago
if it's not hard why do we have docker ?
zdw · 3h ago
The ubiquity criteria also informs scaling - for example, if a tooling or backend dependency is being production deployed by a company at a scale of 10^2 or 10^3 times your use case, you're much less likely to hit insurmountable performance issues until you get to similar scale.
They're also much more likely to find/fix bugs affecting that scale earlier than you do, and many companies are motivated to upstream those fixes.
srcreigh · 2h ago
Their libraries sometimes don’t even work for low scale though.
The protocol buffer compiler for Swift actually at one point crashed on unexpected fields. Defeating the entire point of protos. The issue happens when only it tries to deserialize from JSON, which I guess none of them actually use due to large scale.
zdw · 2h ago
To clarify, I'm not thinking of code/libraries written by a huge company, more about open source code that has been scaled far beyond your deployment size by someone/anyone else.
Also, if you're using some feature that isn't regularly exercised (like your Swift protobuf example), it's probably doesn't have the variety of use to be covered by Hyrum's Law (see https://www.hyrumslaw.com ), which is definitely a different aspect of the Ubiquity criteria.
moron4hire · 3h ago
I don't agree.
Some of the worst bugs I've hit have been in libraries written by very large companies, supposedly "the best and brightest" (Meta, Google, Microsoft, in that order) but it takes forever for them to respond to issues.
Some issues go on for years. I've spent months working in issue trackers discussing PRs and whether or not we can convince some rules-lawyer it doesn't warrant a spec change (HINT: you never convince him), chasing that "it's faster/cheaper/easier to use a 3rd party package" dragon, only to eventually give up, write my own solution, fix the core issue, and do it in less time than I've already wasted. And probably improve overall performance while I'm at it.
I think a lot of it depends on the exact field you're working in. If you're working in anything sniffing close to consulting, work is a constant deluge of cockamamie requests from clients who don't understand they aren't paying you enough to throw together a PhD research thesis in a month with a revolving crew of junior developers you can't grow and keep because the consulting firm won't hire enough people with any amount of experience to give the small handful of senior developers they keep dragging into every God damned meeting in the building so we can have a chance to come up for air every once in a while.
I'm at a point where I have enough confidence in my skills as a software developer that I know pretty much for certain whether I can develop a given solution. There are very few I can't. I'm not going to try to train an AI model on my own. I won't try to make my own browser. A relational database with all the ACID trimmings, no.
But I'll definitely bang out my own agentic system running off of local inference engines. I'll for sure implement an offline HTML rendering engine for the specific reports I'm trying export to an image. I'll build a fugging graph database from scratch because apparently nobody can make one that I can convince anyone to pay for (budget: $0) that doesn't shit the bed once a week.
Most of the time, the clients say they want innovation, but what they really want is risk reduction. They wouldn't hire a consultant if it wasn't about risk, they'd put together their own team and drive forward. Being broadly capable and well-studied, while I may not be quite as fast at building that graph database example as an expert in Neo4j or whatever, we're also not getting that person and have no idea when they are showing up. If they even exist in the company, they're busy on other projects in a completely different business unit (probably not even doing that, probably stuck in meetings).
But I know I can get it done in a way that fits the schedule. Spending time reading the worst documentation known to mankind (Google's) because some drive-by said they did this once and used a Google product to do it is probably going to end in wasting you a lot of time only to realize that said drive-by didn't spend long enough actually listening to the meeting to understand the nuance of the problem. Time that you could have spent building your own and hitting your schedule with certainty.
Sorry, it's late and I'm tired from a full quarter of 12 hour days trying to rescue a project that the previous team did nothing on for the previous quarter because... IDK why. No adults in the room.
porridgeraisin · 2h ago
Hope you're getting paid well bro
moron4hire · 2h ago
Don't go into consulting. If you do, it's impossible to get out. No product-oriented companies will ever hire you. Wish someone told me that 20 years ago.
silisili · 1h ago
> Sometimes it's easier to write it yourself than install the dependency
This is definitely true, but only really relevant if you're either a solo dev or in for the long haul, so to speak. And it'll work way better for your use case too.
The problem is working with others. Others coming in are more apt to try to learn a known or semi-known system than "Dave who used to work here's crazy thoughts." Especially in this market where longevity is rare, and company specific knowledge is useless as resume fodder.
So from a dev standpoint it absolutely makes sense. From a business standpoint, probably markedly less so.
toast0 · 1h ago
Figuring out how to get others to install a dependency is even worse!
travisgriggs · 46m ago
I feel this post. I maintain software in Android, iOS, Python, embedded C, and of late adding Elixir to the mix.
Some in the community will wine about lack of Elixir ecosystem. But often, I’m fine just putting together what I need. It varies. I don’t want to do my own bandit sever or Phoenix live view stuff. But MQTT, no probs.
Often I find that the need for libraries can be an indictment of complexity against the problem space. Take Blootooth as an example. What a huge ball. Though at the end of the day, I’ve done straight to HCI python implementations that for some things are better than the “libraries” available. Don’t get me started on the “hold your hand” gpio libraries for the raspberry pi.
One type of dependency, that I kind of miss is the “copy this code to your project” dependency. You can take complete ownership right away. Whereas with more crafted dependencies, the dependency surface is more than just an algorithm writ large in code, but a whole philosophy/metaphor that may not be an exact fit for your own project.
jeffhwang · 3h ago
And here I thought I was going to read a novel defense of the British healthcare system.
alex_young · 2h ago
NHS?
jeffhwang · 2h ago
Haha, I was doubly confused! You’re right, I should have said National Institutes of Health.
barisozmen · 4h ago
"One technique for making software more robust is to minimize what your software depends on – the less that can go wrong, the less that will go wrong. Minimizing dependencies is more nuanced than just not depending on System X or System Y, but also includes minimizing dependencies on features of systems you are using."
“Find the dependencies — and eliminate them.” When you're working on a really, really good team with great programmers, everybody else's code, frankly, is bug-infested garbage, and nobody else knows how to ship on time.
[..] We didn't think that everyone else was producing garbage but, we also didn't assume that we couldn't produce something comparable to what we could buy for a tenth of the cost.
After many years using libraries without any sort of vetting process, I completely agree in principle that most code out there is bug infested garbage. One dependency had a concurrency bug so severe it almost cost our company our biggest customer early in our journey. We forked and completely rewrote the library as after looking at the source it was clear they didn’t have nearly as much care with their code as we did. This was the worst case but we faced many bugs in widely used libraries. We can’t replace them all as time is short but if we could we would probably replace most of them.
skydhash · 3h ago
A good question I ask myself is: Can I vendor it in? If I cannot, that’s usually something standard, but also a complex domain (crypto, network protocol, platform framework,…). Anything else, I assume it’s only a short term gain, so I make sure to explore the library and get a good understanding of its internals.
3eb7988a1663 · 2h ago
I am failing to find it, but Simon Willison had a post where he vendored some small (<1000 line) blob of code instead of adding it as a dependency. The trick was that he had some Github action(?) automation which would automatically check if the vendored version ever fell out of sync with upstream. Get the benefits of vendoring while minimizing your actual support burden.
Only a realistic strategy for small bits of code, but I have considered do the same for a few utility libraries which are a focused niche, but subtle enough that you would rather outsource the complexity.
betaby · 3h ago
Vendoring is somewhat an answer, but not always.
I have some python code, vitrualenv is an obvious solution. However, older modules depend on older python3.9 behavior. And python 3.9 EOL is October 2025.
eviks · 11m ago
What's the difference vs a state where you wrote the code many years ago that defends on 3.9?
skydhash · 3h ago
Vendoring is taking the responsibility to maintain it as part of your codebase instead of relying on third party, not just capturing a snapshot.
fireattack · 3h ago
What's NIH
rjh29 · 3h ago
Short for Not Invented Here syndrome... when developers ignore existing libraries or solutions and implement their own version. Usually this is meant negatively, i.e. developers thinking they -need- to implement their own version, at great expense, when they could have just used an off-the-shelf library. However this article is positing that writing your own code is a good thing in some cases.
chrisweekly · 3h ago
Not Invented Here
brian-armstrong · 3h ago
National Institute of Health
memming · 1h ago
This is what I thought too.
kazinator · 3h ago
Note that the ECMA-48 escape sequences themselves are the good dependency, not abstractions that hide them, like your tput command or curses or what have you.
bubblyworld · 3h ago
I think the OP's article is saying that they are both good and bad depending on the context. You need to evaluate these things on a case by case basis. Writing a little TUI for yourself or your team? Sure, go nuts with escape codes. Making a well supported tool that runs on any developer's machine? Maybe consider curses, there are probably more edge cases than you think.
Trying to find product market fit as a startup? Who gives a duck, find some customers before you care too much about the tech =P cattle not pets etc
KingOfCoders · 1h ago
With AI NIH will be the new normal.
WalterGR · 1h ago
Why not ask AI how to use <appropriate library / framework> to implement <thing>?
Doesn’t seem like you can blame NIH on AI more than other causes of NIH.
Edit to add: If AI makes NIH easier, then it implies that AI is good at solving problems, and speaks to AI’s credit.
For example, the cost of maintaining a bespoke web frontend "framework" that is specific to your problem domain is probably justifiable in many cases.
The same cannot be said for databases, game engines, web servers, cryptographic primitives, etc. If you have a problem so hard that no existing RDBMS or engine can support, you should seriously question the practicality of solving your problem at all. There's probably some theoretical constraint or view of the problem space you haven't discovered yet. Reorganizing the problem is a lot cheaper than reinventing the entire SQLite test suite from zero.
1) a dependency on a third-party service provider that publishes the dependency. So long as that service provider is current, the dependency should be maintained 2) short-cut to code i don't want to write
I have no arguments with (1), there's a business reason and the lifecycles should match. However, I should still expect major version breaking changes in order to keep my application running. For (2), the wins are less clear, more dependenent on the perceived complexity of what I can avoid writing.
Taking on any kind of dependency means that someone else can dictate when I need to spend time updating and testing changes that don't add anything to my product. Taking on a third-party dependency is always taking on a responsibility to maintain a codebase or the risk of not doing so.
Sure, but if you aren't happy with existing DBs you are probably wrong in thinking you need a general DB instead of a file layout on a filesystem.
Portability is a problem as well.
You do not need an SQL database however, there are others available.
At some point, we need to get up from the computer and go talk to the business and customer about their problem in terms that don't involve anything more sophisticated than excel spreadsheets. There is definitely some aspect you missed if you think you need to build a fully custom technology vertical to get them to pay for a solution.
Of course, all of this advice is pointless if what you are doing is for amusement or as a hobby. I think a lot of arguments about technology would be diffused if we prefaced with our intended applications.
An example is that we create openapi docs with LLM's. Then we serve them with Go's net/http + FileServer, meaning that we never leave the standard library. Of course the LLM itself is a third party dependency, but when you use it to write CLI tools that then do the code generation, it never actually sees the code. That also means that the quality of those CLI tools are less important, because it is their output that matters.
It only goes so long of course. I'm not sure any of our front-end engineers would want to live in a world where they weren't allowed to use React, but then, their products are treated as though they are external anyway.
Anyway, it's a lot easier to make engineers stop using "quality of life" dependencies when you give them something that still makes their lives easy.
The risk of code duplication is a serious one though, and it would be nice if AI could automatically detect and clean this.
I guess we are in an annoying "in-between" state of things, with a pretty unsure future.
What you need is a process to manage dependencies:
1) Only consider open-source dependencies.
2) Introducing new dependencies requires a review. Not just a code review on the pull request introducing it, but checking the license, estimating how much work it would be to rip out, auditing it for history of security vulnerabilities or bugs, whether it is live and still gets updates, how vibrant the community is, and so on.
3) If possible, review your dependencies for possible security issues. Doing this at scale is expensive and the economics of this are still an unsolved problem (I have my ideas: https://blog.majid.info/supply-chain-vetting/).
4) Do not adopt a dependency you are not willing and able to take over the maintenance of, or fork if necessary. At a minimum, it means you have built it from source at least once, not just used binary packages maintained by someone else.
5) Preemptively fork all your dependencies. People can and do delete their repos out of pique, see left-pad.
Most vocal people work on "disposable" end of software. It's cheaper for software giants to just throw engineer-hours at rewriting piece of code that has fallen into organizational obscurity than to maintain (hehe) maintainability. There is usually no sense for small branding/webshop factories to churn out high quality, maintainable code.
However, I suggest you revisit the reason why the dreaded "enterprise patterns" exist in the first place. The main reason to use these architectures is so that five years down the line, when documentation is badly outdated, there is no organizational memory left behind that component, original developers have transitioned to either different teams/departments or left the company altogether, the component is still well isolated, analyzable and possible to work on.
Introduction of external dependency(-ies) carry two inherent business risks: either support for dependency will be dropped, meaning you will have to either absorb maintenance burden yourself or switch dependencies, or it will introduce breaking changes, meaning you have to stick to unmaintained version or update your product code. Both situations will eventually impact your feature flow, whatever it is.
Compromise between trunk and leaf (push of dependencies vs pull of deps) is intrinsic to modularization and is always there, however with internal components this compromise is internal, rather external.
> Many people like writing new code and will do it even when it's detrimental to the business, but 9 times out of 10 even using a "bad" dependency is far more effective than writing in-house.
If you are a SaaS company - most probably yes as it is the short-term outcome that is determinate of business success. However, if you work in any industry with safety and support requirements on software or put the burden of long term support on yourself, long-term horizon is more indicative of business success.
Remember, writing new code is almost never the bottleneck in any mature-ish organization.
[1]https://en.wikipedia.org/wiki/Number_8_wire#:~:text=Accordin...
And therefore, adopting a "zero dependencies" policy is absolutely an overreaction.
Where the article hits is critical libraries that you heavily rely on and that your code is slowly formatted around. I'm thinking specific data parsers, fancy query brokers, time management libraries etc.
My two cents. If a dependency is paid, than it is usually bad. Because the company providing that dependency has an incentive to lock you in.
As another point, "dependency minimalism" is a nice name for it. https://x.com/VitalikButerin/status/1880324753170256005
Given very few companies last forever, you have to assess if the trajectory of your project would be impacted by being coupled to their ability to support you.
Vendor lock-in is a risk for both purchased components and FOSS ones where the organization is unwilling to assume maintenance. The onus is on the team incorporating third-party component(s) to manage their risk, identify alternatives as appropriate, and modularize their solutions.
If my code has a dependency then I want there to be people whose feel it is their job to support it.
Either there have to be enough people who are paid to support it, or there have to be enough people whose self-worth and identity is so wrapped up in the code that they take it as a point of honor to support it.
I don't need a company that's likely to abandon a code product and leave me hanging. I also don't need a free software author who says "bugs are not my problem - you have the source, go fix it yourself." If those are my choices, I'd rather write it myself.
The upside of paying for something is that, assuming the owner or company is stable, I don't have to worry about some unpaid solo maintainer burning out and never logging back in.
and continues to be stable for the lifetime of your product.
A few examples wouldn't hurt...
> Their breaking changes can trigger expensive re-writes of your own code to handle a new interface.
Don't update them or NIH-update them just like you'd do with the original NIH code. Still a net win in saving the time for the initial coding
> You need to ensure they end up on your clients' machine.
Vendoring exists?
They're also much more likely to find/fix bugs affecting that scale earlier than you do, and many companies are motivated to upstream those fixes.
The protocol buffer compiler for Swift actually at one point crashed on unexpected fields. Defeating the entire point of protos. The issue happens when only it tries to deserialize from JSON, which I guess none of them actually use due to large scale.
Also, if you're using some feature that isn't regularly exercised (like your Swift protobuf example), it's probably doesn't have the variety of use to be covered by Hyrum's Law (see https://www.hyrumslaw.com ), which is definitely a different aspect of the Ubiquity criteria.
Some of the worst bugs I've hit have been in libraries written by very large companies, supposedly "the best and brightest" (Meta, Google, Microsoft, in that order) but it takes forever for them to respond to issues.
Some issues go on for years. I've spent months working in issue trackers discussing PRs and whether or not we can convince some rules-lawyer it doesn't warrant a spec change (HINT: you never convince him), chasing that "it's faster/cheaper/easier to use a 3rd party package" dragon, only to eventually give up, write my own solution, fix the core issue, and do it in less time than I've already wasted. And probably improve overall performance while I'm at it.
I think a lot of it depends on the exact field you're working in. If you're working in anything sniffing close to consulting, work is a constant deluge of cockamamie requests from clients who don't understand they aren't paying you enough to throw together a PhD research thesis in a month with a revolving crew of junior developers you can't grow and keep because the consulting firm won't hire enough people with any amount of experience to give the small handful of senior developers they keep dragging into every God damned meeting in the building so we can have a chance to come up for air every once in a while.
I'm at a point where I have enough confidence in my skills as a software developer that I know pretty much for certain whether I can develop a given solution. There are very few I can't. I'm not going to try to train an AI model on my own. I won't try to make my own browser. A relational database with all the ACID trimmings, no.
But I'll definitely bang out my own agentic system running off of local inference engines. I'll for sure implement an offline HTML rendering engine for the specific reports I'm trying export to an image. I'll build a fugging graph database from scratch because apparently nobody can make one that I can convince anyone to pay for (budget: $0) that doesn't shit the bed once a week.
Most of the time, the clients say they want innovation, but what they really want is risk reduction. They wouldn't hire a consultant if it wasn't about risk, they'd put together their own team and drive forward. Being broadly capable and well-studied, while I may not be quite as fast at building that graph database example as an expert in Neo4j or whatever, we're also not getting that person and have no idea when they are showing up. If they even exist in the company, they're busy on other projects in a completely different business unit (probably not even doing that, probably stuck in meetings).
But I know I can get it done in a way that fits the schedule. Spending time reading the worst documentation known to mankind (Google's) because some drive-by said they did this once and used a Google product to do it is probably going to end in wasting you a lot of time only to realize that said drive-by didn't spend long enough actually listening to the meeting to understand the nuance of the problem. Time that you could have spent building your own and hitting your schedule with certainty.
Sorry, it's late and I'm tired from a full quarter of 12 hour days trying to rescue a project that the previous team did nothing on for the previous quarter because... IDK why. No adults in the room.
This is definitely true, but only really relevant if you're either a solo dev or in for the long haul, so to speak. And it'll work way better for your use case too.
The problem is working with others. Others coming in are more apt to try to learn a known or semi-known system than "Dave who used to work here's crazy thoughts." Especially in this market where longevity is rare, and company specific knowledge is useless as resume fodder.
So from a dev standpoint it absolutely makes sense. From a business standpoint, probably markedly less so.
Some in the community will wine about lack of Elixir ecosystem. But often, I’m fine just putting together what I need. It varies. I don’t want to do my own bandit sever or Phoenix live view stuff. But MQTT, no probs.
Often I find that the need for libraries can be an indictment of complexity against the problem space. Take Blootooth as an example. What a huge ball. Though at the end of the day, I’ve done straight to HCI python implementations that for some things are better than the “libraries” available. Don’t get me started on the “hold your hand” gpio libraries for the raspberry pi.
One type of dependency, that I kind of miss is the “copy this code to your project” dependency. You can take complete ownership right away. Whereas with more crafted dependencies, the dependency surface is more than just an algorithm writ large in code, but a whole philosophy/metaphor that may not be an exact fit for your own project.
From http://nathanmarz.com/blog/principles-of-software-engineerin...
“Find the dependencies — and eliminate them.” When you're working on a really, really good team with great programmers, everybody else's code, frankly, is bug-infested garbage, and nobody else knows how to ship on time.
[..] We didn't think that everyone else was producing garbage but, we also didn't assume that we couldn't produce something comparable to what we could buy for a tenth of the cost.
from https://danluu.com/nothing-works/
Only a realistic strategy for small bits of code, but I have considered do the same for a few utility libraries which are a focused niche, but subtle enough that you would rather outsource the complexity.
Trying to find product market fit as a startup? Who gives a duck, find some customers before you care too much about the tech =P cattle not pets etc
Doesn’t seem like you can blame NIH on AI more than other causes of NIH.
Edit to add: If AI makes NIH easier, then it implies that AI is good at solving problems, and speaks to AI’s credit.