2 ms·
I understand where you are coming from but I imagine few open source projects were created with the idea that they'd eventually make the big bucks on support co
by VBprogrammer 6y ago
I understand where you are coming from but I imagine few open source projects were created with the idea that they'd eventually make the big bucks on support contracts.
I think the important point is that if money should be on the table. After that it's a business negotiation as to how much you are willing to pay.
An interesting point is how you can implement a process to make this whole thing not consume non trivial amounts of time. By way of example:
Bob is a developer. He finds bug in his code comes from an underlying open source library. This gives Bob 3 options.
- Bob can either dig into the library and see if he can fix it and maintain a fork.
- Bob can fix it and try to get corporate approval for submitting an upstream patch.
- Bob can try to seek approval and budget to pay the maintainer of the project to take a look at the problem.
If companies I have worked for are anything to go by 3 sounds like a herculean task. 2 sounds possible but involves effort. 1 is a minor annoyance (with high probability of major issues down the line).
- erikerikson 6y agoMy main point was to note how far apart the paradigms are. I think you're right that few projects are started with aspirations to gaining support contacts. It does seem like it might help OSS be more sustainable though. If I could transition to independently working on some of my projects I'd be glad to make a fair number of compromises to do so. 2 is definitely the best option and can be surprisingly low friction, especially when Bob points out that otherwise there's an ongoing maintenance cost to the business to keep merging the upstream. Bob also has his personal time even though that shouldn't be on the table. I've succeeded at 1 & 2 and failed at 3.