4 ms·

"I could fix it myself if needed" quite often comes up on HN and other programmer forums but I honestly have to wonder how many people could actually fix deep i

by WJW 3y ago

"I could fix it myself if needed" quite often comes up on HN and other programmer forums but I honestly have to wonder how many people could actually fix deep issues in production grade software. For example, there are plenty of bugs open on the issue trackers of (say) postgres or kubernetes yet despite the source of those being available I'm willing to bet a vanishingly small amount of users would be willing or capable to dive in and fix the issue themselves.

jen20 3y ago
Perhaps many would not. I regularly do.
plorkyeran 3y ago
I rarely fix bugs in my dependencies, but I have found having the source available to be very useful in working around bugs in them. It's frequently the difference between a workaround that appears to work but I don't know why and might just cause different problems and a workaround that I know is correct.
dddaaadddaz2 3y ago
It depends what the software is of course, but I've definitely fixed issues in a not unreasonable amount of time that in some cases would not even have been within the terms of any support contract (and would certainly have taken a tier 1 or tier 2 vendor application support an unacceptably long amount of time to do the same, assuming they didn't just close the ticket as unsupported use case). Would I be able to do that for the Linux kernel? Of course not. But the vast majority of software out there is nowhere close to that level of complexity. And there are specialized groups that are trustworthy that we pay enormous sums to handle that and have had good experiences with. So it depends but it's definitely a selling point of open source for a lot of systems engineering and adjacent roles that need to glue together lots of disparate pieces of software in sometimes unusual and unsupported ways, and sometimes for platforms that are not technically supported, or that the vendor is not able to establish any confidence in us that they will be able to support it competently for the next 10+ years for any number of reasons. That often requires forking the codebase. To summarize, as someone essentially in the business of insuring for fortune 500s that aren't software vendors against startups and other companies deemed non-trustworthy or risky in some other way...the vast majority of YC style companies inevitably fall into the category of company where their software would not pass risk management processes for enterprise wide deployment without a proper open source license. A lot of that is down to regulatory requirements as well. It isn't some sort of irrational FAANG company "not developed here" ego boost. For those of you that are new to the startup world, or weren't around back in the before times of the 60s-around about the mid 2000s up until the financial crisis, this may not make much sense. But it's very much the case that this ecosystem of software startups would not exist in any significant way if it had not gone all in on open source. I'm not sure how I feel about that morally or ethically but its something to think about when you are deciding how to license your software. As far as these weird source available licenses go...it's an option but it's risky. Those familiar with the history of computing will know that the old mainframe OS's and commercial Unix's were both once source available and that ended up burning a lot of people when they started to restrict access to the source (a lot of our companies had and still maintain custom operating system modifications to legacy platforms from back in those days). The institutional memory of source available licenses (or in the case of MVS, no concept of software licensing at all) being used to turn the screws on customers is still very raw in the much slower moving world of traditional industries. Enshitification is not a new idea, some industries have been through multiple cycles of that process and have developed defense mechanisms.
LtWorf 3y ago
I wrote a simple patch to postgres last month. Some other patch that was written by someone else at my company is now part of postgres.
ic_fly2 3y ago
Yeah, happens quite a bit. Also just being able to dig and figure out why something is doing a weird thing happens all the time. I’d say about once a month in my team of three people, and we’re not even doing fancy stuff. Most recent examples I can remember: polars data conversion errors, batch sizing in azure service bus sdk, some weird validation thing in pydantic and the performance monitoring in sentry not working as expected. The pydantic bug got a patch / note in the docs that was actually already merged.

by WJW 3y ago

jen20 3y ago

Perhaps many would not. I regularly do.

plorkyeran 3y ago

I rarely fix bugs in my dependencies, but I have found having the source available to be very useful in working around bugs in them. It's frequently the difference between a workaround that appears to work but I don't know why and might just cause different problems and a workaround that I know is correct.

dddaaadddaz2 3y ago

It depends what the software is of course, but I've definitely fixed issues in a not unreasonable amount of time that in some cases would not even have been within the terms of any support contract (and would certainly have taken a tier 1 or tier 2 vendor application support an unacceptably long amount of time to do the same, assuming they didn't just close the ticket as unsupported use case). Would I be able to do that for the Linux kernel? Of course not. But the vast majority of software out there is nowhere close to that level of complexity. And there are specialized groups that are trustworthy that we pay enormous sums to handle that and have had good experiences with. So it depends but it's definitely a selling point of open source for a lot of systems engineering and adjacent roles that need to glue together lots of disparate pieces of software in sometimes unusual and unsupported ways, and sometimes for platforms that are not technically supported, or that the vendor is not able to establish any confidence in us that they will be able to support it competently for the next 10+ years for any number of reasons. That often requires forking the codebase. To summarize, as someone essentially in the business of insuring for fortune 500s that aren't software vendors against startups and other companies deemed non-trustworthy or risky in some other way...the vast majority of YC style companies inevitably fall into the category of company where their software would not pass risk management processes for enterprise wide deployment without a proper open source license. A lot of that is down to regulatory requirements as well. It isn't some sort of irrational FAANG company "not developed here" ego boost. For those of you that are new to the startup world, or weren't around back in the before times of the 60s-around about the mid 2000s up until the financial crisis, this may not make much sense. But it's very much the case that this ecosystem of software startups would not exist in any significant way if it had not gone all in on open source. I'm not sure how I feel about that morally or ethically but its something to think about when you are deciding how to license your software. As far as these weird source available licenses go...it's an option but it's risky. Those familiar with the history of computing will know that the old mainframe OS's and commercial Unix's were both once source available and that ended up burning a lot of people when they started to restrict access to the source (a lot of our companies had and still maintain custom operating system modifications to legacy platforms from back in those days). The institutional memory of source available licenses (or in the case of MVS, no concept of software licensing at all) being used to turn the screws on customers is still very raw in the much slower moving world of traditional industries. Enshitification is not a new idea, some industries have been through multiple cycles of that process and have developed defense mechanisms.

LtWorf 3y ago

I wrote a simple patch to postgres last month. Some other patch that was written by someone else at my company is now part of postgres.

ic_fly2 3y ago

Yeah, happens quite a bit. Also just being able to dig and figure out why something is doing a weird thing happens all the time. I’d say about once a month in my team of three people, and we’re not even doing fancy stuff. Most recent examples I can remember: polars data conversion errors, batch sizing in azure service bus sdk, some weird validation thing in pydantic and the performance monitoring in sentry not working as expected. The pydantic bug got a patch / note in the docs that was actually already merged.