3 ms·

Just to give a picture how similar situations play out in closed source environments: They would have a key account manager who's live they would turn into hell

by erikb 8y ago

Just to give a picture how similar situations play out in closed source environments: They would have a key account manager who's live they would turn into hell. And depending on the size of gitlab's business in relation to the customers of the software provider it would have more or less effect towards software development. Reaction might range from having a fix in 2 days plus on-site engineer/consultant visits plus inviting the corresponding manager of gitlab to dinner for $100+/person to not even getting a response to even getting an angry call from the provider side's manager that the account will be closed if gitlab doesn't behave. So, Github owned by Microsoft might not even notice such a bug for long, since the engineer would be able to get it fixed through an email or two. While the pre-Github-purchase Gitlab might have gotten no fix at all. In that regard one might argue that open source doesn't completely destroy the ability to solve problems, but open source certainly helps balancing out the odds for different competitors.

pjc50 8y ago
This very much depends on how big you are and how much you're willing to spend. At a medium-size all-Microsoft shop with 100+ MSDN licensees, I found a bug in WINCE7's handling of "structured exceptions", and eventually got them to acknowledge it but they never fixed it. (I got as far as disassembling their DLLs to point to the exact problem)
- uep 8y ago
  Yeah, I don't really buy the parent comment's insinuation that Microsoft GitHub would be more likely to fix it than GitHub previously. My company has shipped hundreds of thousands of devices with a Microsoft OS on it, and they virtually never fixed anything reported. At least one bug was very serious, and we thought they would have to fix it, but it just didn't happen. What's hundreds of thousands to the hundreds of millions they ship every year?
  - timerol 8y ago
    I think you misread the comment. Assuming that NFS was sold by NFS-Co, GitHub, as part of Microsoft, would be a big enough customer to get NFS-Co to fix the bug quickly. However, GitLab would be a tiny NFS-Co customer, and so the bug would have gone unfixed. The difference is in the size of who reports the bug.
  - erikb 8y ago
    > I don't really buy the parent comment's insinuation that Microsoft GitHub would be more likely to fix it than GitHub previously If Linux would be a proprietary product, than post-acquisition-github would get a fix from Linux developers because Microsoft is big. Not Github would provide anything, but they would get something due to the size of the Microsoft empirial stamp.
- tinus_hn 8y ago
  Supposedly if you buy support incidents they should do something. I don’t know if that is actually true in practice though.
AceJohnny2 8y ago
> but open source certainly helps balancing out the odds for different competitors. Assuming all competitors have the same engineers who are competent in the various technologies involved in debugging this (at a glance: filesystem operations, strace, wireshark, linux kernel compilation and modules, Google Cloud Platform...), know how to contact and approach the open-source maintainers. ... and most importantly: have the time to dedicate to such a debugging task.
peterwwillis 8y ago
Or another example in closed source: We had the source code for an API that hooked into a proprietary library. We found a bug in the library. I don't think we had a support contract, and the issue was affecting production. Fixing it could have entailed some decompiling of the library, identifying the bad function, writing a workaround, and shoving it all into a new library. But I didn't have the expertise for all that, so instead I hacked up the API with a different workaround, essentially killing off some functionality, which avoided the bug. The application worked again, and we went on with life. Another example: a proprietary extension to a tool did data replication. Under certain circumstances, data replication would fail, and the loss of data meant we would have to full-sync all data, taking up to four days. We reported the bug to the company. They determined it was a "minor error" and said the fix would arrive in the next release, in six months. So we identified a workaround (add cacheing, monitor for potential service disruption, restart services to re-connect networks before cache would empty) and implemented it until the fix could be delivered. Regardless of who fixes the bug or how, the amount of time and money you invest in the fix matters. If a workaround saves you time and money by deferring the cost of the fix, that's often an acceptable solution. In this case, if the issue was affecting customers in production, blocking 'git gc' just for affected customers may have been a perfectly good workaround while whoever owned the NFS Client code figured out and implemented a fix.

by erikb 8y ago

pjc50 8y ago

This very much depends on how big you are and how much you're willing to spend. At a medium-size all-Microsoft shop with 100+ MSDN licensees, I found a bug in WINCE7's handling of "structured exceptions", and eventually got them to acknowledge it but they never fixed it. (I got as far as disassembling their DLLs to point to the exact problem)

uep 8y ago
Yeah, I don't really buy the parent comment's insinuation that Microsoft GitHub would be more likely to fix it than GitHub previously. My company has shipped hundreds of thousands of devices with a Microsoft OS on it, and they virtually never fixed anything reported. At least one bug was very serious, and we thought they would have to fix it, but it just didn't happen. What's hundreds of thousands to the hundreds of millions they ship every year?
- timerol 8y ago
  I think you misread the comment. Assuming that NFS was sold by NFS-Co, GitHub, as part of Microsoft, would be a big enough customer to get NFS-Co to fix the bug quickly. However, GitLab would be a tiny NFS-Co customer, and so the bug would have gone unfixed. The difference is in the size of who reports the bug.
- erikb 8y ago
  > I don't really buy the parent comment's insinuation that Microsoft GitHub would be more likely to fix it than GitHub previously If Linux would be a proprietary product, than post-acquisition-github would get a fix from Linux developers because Microsoft is big. Not Github would provide anything, but they would get something due to the size of the Microsoft empirial stamp.
tinus_hn 8y ago
Supposedly if you buy support incidents they should do something. I don’t know if that is actually true in practice though.

AceJohnny2 8y ago

> but open source certainly helps balancing out the odds for different competitors. Assuming all competitors have the same engineers who are competent in the various technologies involved in debugging this (at a glance: filesystem operations, strace, wireshark, linux kernel compilation and modules, Google Cloud Platform...), know how to contact and approach the open-source maintainers. ... and most importantly: have the time to dedicate to such a debugging task.

peterwwillis 8y ago

Or another example in closed source: We had the source code for an API that hooked into a proprietary library. We found a bug in the library. I don't think we had a support contract, and the issue was affecting production. Fixing it could have entailed some decompiling of the library, identifying the bad function, writing a workaround, and shoving it all into a new library. But I didn't have the expertise for all that, so instead I hacked up the API with a different workaround, essentially killing off some functionality, which avoided the bug. The application worked again, and we went on with life. Another example: a proprietary extension to a tool did data replication. Under certain circumstances, data replication would fail, and the loss of data meant we would have to full-sync all data, taking up to four days. We reported the bug to the company. They determined it was a "minor error" and said the fix would arrive in the next release, in six months. So we identified a workaround (add cacheing, monitor for potential service disruption, restart services to re-connect networks before cache would empty) and implemented it until the fix could be delivered. Regardless of who fixes the bug or how, the amount of time and money you invest in the fix matters. If a workaround saves you time and money by deferring the cost of the fix, that's often an acceptable solution. In this case, if the issue was affecting customers in production, blocking 'git gc' just for affected customers may have been a perfectly good workaround while whoever owned the NFS Client code figured out and implemented a fix.