On 09/08/10 22:53, David Gerard wrote:
.... or free software issues in particular. The question was triggered by someone whose management is scared silly of the GPL, for whatever spurious reasons. My answers assume that legal and technical facts won't work without answering the subjective business-sense issues attached.
What sort of things have you had to do to get reluctant management to let you contribute patches back to free software?
Whatever answers the underlying concerns and helps them say "yes":
Some I've used/will use:
Concern: we'll have to give the source away anyway Answer: we'll have to give away our changes anyway - our competitors can get them just through buying one of our products second hand, and we'll have to give it to them - we may as well work closer with the project developers and scratch each-others backs - if they accept our changes then it will likely reduce the maintenance burden for us. And if we don't contribute our changes, our competitor might contribute our changes - or worse, incompatible changes that make life harder for us and easier for everyone else. If the code does what our customers want through our competitors changes, why would they buy from us? Better to buy from the authors of the feature who are developing and supporting it.
Concern: loss of business value Answer: We get the benefit of thousands of man-hours of expertise and testing for free. A few patches back is a bargain and more than paid for with the community good will in return. Business value is not in secrecy but ability to execute rapidly. Co-operation and goodwill brought through co-operation will reduce time to market, can we work out how much that is worth to the business? (You may want to estimate the size and variety of the testing base, and how much it would cost the company to organize it. Be careful to get a realistic estimate, and not all testers may use your features - which doesn't make it worthless if they are testing that your changes didn't break other features).
However, some open source projects are enormously hard to contribute to. One major project has been such a drain on the time of my previous employer that it was not worth the time it took to get patches accepted (these were just enabling patches to allow the main feature to function); so be careful what promises you give to your employer.
Perhaps open source projects should have a published policy accepting 3rd party contributions. I know that Mysql and Samba do. Both require that the copyright of the patches be given up by the employer which is another hurdle - so good luck getting that one past your employer! (http://samba.org/samba/devel/copyright-policy.html, http://forge.mysql.com/wiki/Sun_Contributor_Agreement)
Sam
- d.
---------- Forwarded message ---------- From: David Gerarddgerard@gmail.com Date: 9 August 2010 22:50 Subject: Re: [ORG-discuss] GPL Advice To: Open Rights Group open discussion list org-discuss@lists.openrightsgroup.org
On 9 August 2010 21:12, Will Hallorg@gnatter.net wrote:
Whilst the spirit of GPL/copy[right|left|fight] issues is clear (ish), the intricacies are not, and I would very much appreciate some help with my basic understanding.
I replied from my experience, and (despite being somewhat off topic for ORG) it may be of benefit to others here in a similar boat .
In my experience, you need to point out the business advantage: we got a bunch of our build process working *far* better by contributing a fix we needed to the build software, and one of our staff, who is actually a medical doctor, has found himself a significant contributor to a GPL project!
That is: focus on the carrot, to the point they consider it attractive enough to see problems as things to work around. And GPL compliance is ridiculously easy *once you have* management buyin.
The "competitive advantage" is "free vendor assistance, they like us so will tend to help us." They might respond to that.
It can also be good marketing and public relations. Get the marketers interested, that'll swing it ;-)
[I might forward this to FSFE for ideas too.]
- d.
Discussion mailing list Discussion@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/discussion
