Slashdot Mirror
Corporations and OSS Do Not Mix (coglib.com)
An anonymous reader writes: Ian Cordasco, a prolific open source developer, wrote a lengthy post about his experiences working on code that gets used by companies as part of their business. His basic thesis is that the open source development process is not particularly compatible with for-profit corporations, and having them involved frequently makes progress more difficult. "As soon as a bug affects them, they want it fixed immediately. If you don't fix it in 24 hours (because maybe you have a real life or a family or you're sick or any number of other very valid reasons) then the threats start." He adds, "When companies do 'contribute,' it's often not in the best interest of the community, it isn't enough, or it's thoroughly misguided." Cordasco is quick to note that there are exceptions, but he has an idea why the majority behave that way: "I don't have the complete answer, but one important point is that there is toxicity in the community, its leaders, and or its contributors, and the companies have learned their behavior from this toxicity." He provides a list of suggestions both for companies using open source software, and also some further reading on the subject from Ashe Dryden, David MacIver, and Cory Benfield.
What threats? (I didn't RTFA yet). Start with the warranty disclaimer that you attached to your licence in capital letters. Then, if they "contribute", tell them nicely to fork off (the technical term, not the innuendo) and, if their fork is actually any good, they should ask you to merge their changes, which you will if they're not bullshit.
If they keep kicking and screaming like baby lawyers, submit for their review a support contract. Make sure your rate is in the "highly paid consultant" range - you might even get away with it, as at that point you'd be speaking _their_ language.
"Everybody's naked underneath" -- The Doctor
This problem isn't toxicity in the OSS community, it's toxic expectations of the corporate world. They wrongly (for almost all projects) expect OSS software to have the same support mechanisms and turnaround times in place as the proprietary systems they're used to, and think they can strongarm one or a few individuals into solving problems they could likely easily fix themselves and release a patch to the authors. Their main misunderstanding is that unlike expensive proprietary software, OSS is not supposed to be a one way street.
Chances are most of this would go away if the OSS software in question had an explicit disclaimer of warranty and fitness for purpose.