|
|
|
|
|
by WorldMaker
1522 days ago
|
|
If your company is paying you to work on Product X and Product X depends on Open Source Library Y, Open Source Library Y's bugs are Product X's bugs. Open Source Library Y's features are often productivity enhancements that make Product X better. Your company is paying you to work around Open Source Library Y's defects and use Open Source Library Y's productivity enhancements, no matter what. Sometimes the fastest way to work around Library Y's defects is to fix them yourself and sometimes the best way to get more productivity out of tools like Library Y is to contribute Library Y features yourself. Because your company may see Open Source Library Y as free as in beer they may not value the vendor relationship with Open Source Library Y. The "cultural" Maintenance Agreement with Open Source "vendors" is that good open source users contribute back to open source those bug fixes they need for workarounds and those features they request for productivity benefits. Compared to the costs of Maintenance Agreements with many large, classic closed source vendors, the cost of a few hours labor on dependencies to products is often quite cheap relatively speaking especially with the "free as in beer" platform/networking effect that other "good" companies following cultural Maintenance Agreement norms contribute as well. The only real missing ingredient is that because that Maintenance Agreement is cultural more than it is written down in a way that Corporate Lawyers can read it and Actuaries and CPAs can understand it to be an asset and/or liability that impacts the books, it just becomes invisible guilt: either the guilt that you aren't doing your part as a developer with respect to that culturally assumed Maintenance Agreement OR the guilt that you are doing your part but that your company may find out and claim you are wasting their time. But seriously, that vendor relationship even though most of the "assets" are "free as in beer" should be on the books and have its own billing codes for the culturally encouraged "liabilities" of Maintenance Agreements to spend a few hours of developer time here or there for the "greater good", but also the specific good of "making Product X better" because that is an asset directly related to the performance and success of "Product X". |
|