[development] Convince Client to Release Code

[Alex Urevick-Ackelsberg]

I definitely think these types of discussions are best had before work
begins, and should be part of the contract between you and your client.
Here's the wording from our standard contract:

-------------
Proprietary Rights.
The Drupal software programs (comprised of core software as well as
additional community-contributed modules
and theme software) (herein referred to as “Drupal”) used by Consultant are
licensed under a GNU General Public
License, and all developed code and techniques derived from Drupal shall be
licensed in accordance with the
applicable GNU General Public License. Further, developed code and
techniques derived from Drupal shall be
contributed to the Drupal community for public use unless specifically
agreed upon in writing by both parties prior
to development or it is agreed that such code would not provide benefit to
the community. Developed code, when
contributed back to the Drupal community, can be attributed to both
Consultant and Company as appropriate.
Developed code and techniques not derived from or natively integrated with
Drupal shall not be contributed to an
open source community without express consent from Company.
-------------

This almost invariably makes the contract negotiations take longer, but in
the end they are sold on the ideas that it is 'the right/profressional way'
to work in Open Source, and we won't sacrifice working in the 'right way',
as well as the long term maintenance costs of maintaining your own code.

--
Alex Urevick-Ackelsberg
ZivTech, LLC
http://zivtech.com
alex at zivtech.com
office: (267) 940-7737
cell: (215) 866-8956
skype: zivtech
aim: zivtech


From: David Metzler <metzlerd at metzlerd.com>
> To: development at drupal.org
> Date: Mon, 13 Jul 2009 06:42:29 -0700
> Subject: Re: [development] Convince Client to Release Code
> Although the links provided touch on this.  The  most successful argument I
> have used is that the client may be able to defer and/or share the maintence
> costs of the module.  The first time that they don't have to pay a developer
> to upgrade the  module to the next major rev of drupal (because someone else
> has contributed the port), this can be a powerful argument. Of course as
> others have already mentioned, it should be pointed out that they are taking
> advantage of other consultants paid development by using drupal, and that it
> is fairly common practice for code that is paid for by other organizations
> to be released back into the drupal community.
>
> There are many success stories to be told, where an important feature to a
> contributed module was developed (and therefor paid for) wholly by another
> person.  Depending on the complexity and reusability of the module, they may
> FULLY recoup the cost of development in maintenance cost savings. I often
> describe open source software as bartered software developement, where you
> lose the overhead associated with contract management. ;)
>
> Given all that, continue to point all this out, every time you get an
> opportunity.  Sometimes it takes a while to sell, and the proprietary module
> could be released into the community at any time.  No rush.
>
> I'm still selling it at my shop, not cause the people don't get it, but
> because its an easy thing to take for granted. It's the bills you pay that
> get your attention, not the ones you manage to avoid.
>
> Good luck, and keep trying....
>
> Dave
>
> On Jul 13, 2009, at 6:06 AM, Fred Jones wrote:
>
>  Regarding the legal issues here, it's definitely interesting and I
>> will now take care to make contacts, but as far as this job, we have
>> no contract but anyway the owners of this group are friends of ours
>> and there is no fight going on--we just suggested to release the code
>> and they asked us not to. So now we have to convince them to agree. :)
>>
>>  I think your job is to let him understand the advantages of having
>>> such modules "supported by the community" and what does it mean
>>> "replicating and maintaining your work".
>>>
>>
>> So that's what I'm asking about here--I can tell him the advantages are:
>>
>> 1. Testing and Bug reports.
>> 2. Potential patches being submitted that he won't have to pay for.
>>
>> That's what I know. What does "replicating and maintaining your work"
>> refer to?
>>
>>  Does the client have a site/service that would be of interest to the
>>> general
>>> public? If so then I would try to sell it from the angle that you can
>>> release the module with a "supported by" attribution that links back to
>>> them
>>> from the D.O. project page. That could help give them more recognition
>>> and
>>> give their company a higher standing within the O.S. community.
>>>
>>
>> No, their service is only for other organizations in their particular
>> business. I don't think a link on d.o will interest them *at all.* I
>> would like one, but I'm a nerd. lol.
>>
>>  Does he realize that he's the beneficiary of millions of hours of work
>>> paid for by others?
>>>
>>
>> Of course he realizes that. Does he care, however? Seems like not. :(
>>
>> Well, it could be that he knows and appreciates BUT he still doesn't
>> want to lose his own money over it. lol.
>>
>>  See this related article:
>>>
>>> http://civicactions.com/blog/
>>> most_important_decision_developing_site_Contributed_vs_custom_development
>>>
>>> and the "Contribute back" section here:
>>>
>>> http://drupal.org/node/51169
>>>
>>
>> OK, great--this is the kind of thing I was looking for. Thanks.
>>
>> Fred
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090713/1cad0e22/attachment-0001.htm>