[consulting] Proper Collections Procedure

[Evan Leibovitch]

Gunnar Langemark wrote:

> Open Source and the aggressive business environment we work in - are 
> conflicting. We work on trust, and tend to believe in each other.


I am amazed that one of my must-have modules, "spam", is not included on 
the drupal.org site list. Why? Because it is released under a BSD 
license rather than the GNU GPL. And it is the BSD license, not the GPL, 
that is based upon trust.

What I mean by that is that developers release their code under the GPL, 
in order to legally force other developers to publicly release source to 
redistributed modifications. If developers really trusted other 
developers to do this, they could release under the BSD license (or even 
to the public domain). But since developers don't trust all other 
developers to do the right thing, they use the GPL to force them to do 
the right thing.

So I would argue that while Drupal is developed using a great deal of 
co-operation, I would not at all attribute that to "trust". In more than 
a decade of working with open source, I have not found Drupal's  bias 
against non-GPL (but OSI compliant) code -- indicated by the exclusion 
of "spam" from the mainstream module repository --  repeated elsewhere 
in the open source world outside of the FSF itself.

> In traditional business we have contracts, requirements specs., and we 
> have change requests.

Requirements, specifications and change requests are not exclusively the 
realm of proprietary software.

> This world is based on rules, law and legal rights.

Such as Drupal licensing.

> This is often percieved as TOO MUCH documentation

Only by people who are scared, or unwilling, to communicate their 
intentions to those who use their code -- and/or by people who haven't 
been in business long enough to be burned by poor or non-existent 
documentation. The fact that writing code and writing documentation 
(both contracts and manuals) can be very different skills often makes 
documentation intimidating (or at least distasteful) to coders. However 
that is no excuse to deny the importance of documentation, and the 
consequences of such denial are the kind of poor communications that 
lead to unhappy clients and bad business deals.

> If the client understands that he gets standard software

Never expect or assume that a client will know what you mean by 
"standard software" unless you formally define the term. Especially if 
your client is not focused on IT as their business, they will not 
understand many concepts that you may commonly use.

> If he thinks it's a web design project - where the visuals and 
> everything is to be exactly as in the slideshow with designs that he 
> saw - he will bother everybody with all the nitti gritti details.

If you and your client agreed on a result from a slideshow, you can 
expect the client to be upset if what is delivered does not meet that 
expectation. If what you plan to deliver is not exactly what is in the 
slideshow, then you and the client must agree on that BEFORE you start 
work, or else you will have problems later.

> So I see two conflicts here: One between the Open Source community 
> world - where trust is good - and the business world where 
> documentation is king.

As explained above -- there is heavy collaboration between open source 
developers, but I wouldn't call it a relationship of trust.  In the 
meritocracy behind most successful open source projects, you're as good 
as your code; trust has little to do with it. Certainly the GPL exists 
because developers do not trust all other developers to keep the code free.

The key issue here is money. Once you start to receive payment for your 
work, once it is no longer a hobby but a source of income, you need to 
be concerned with documentation. Obviously your government has an 
interest in your documentation of revenue work (for tax purposes) that 
did not exist when your work was voluntary. So documentation 
(record-keeping and agreements between client and contractor) becomes an 
important part of the work, and the effort spent on it must be treated 
as a necessary (if unwanted) cost of doing business.

> If the client expects to have that kind of control, and you sell him a 
> standard software project, you're bound to get into trouble.

This is why a contract -- even a simple but written "statement of work 
to be done" -- is so important. It helps certify that the expectations 
of the client and the developer are the same. What IMO is important, 
here, is that both sides agree on the result (what the client will 
finally receive) rather than the methods (whether you used "standard" 
code, slightly modified code, or written from scratch).

When hiring someone to do car or home repairs, most clients don't ask 
(and don't care) what brand of tools are used  by the technician -- or 
if the tools are custom-made -- so long as the repair done with those 
tools is of the agreed quality, speed and budget. People don't expect 
that working with IT contractors should be any different.

- Evan