[software] Rapport2

[Bob F]

>

We all have our preferences in languages, but I think this should  
play a minor role in our thinking.  The maintainability of code  
depends not just on the language but also on the various frameworks  
and libraries employed, and of course the design of the software  
itself.  I would guess that language is the least of those issues,  
unless the language being used is completely inappropriate for the  
task at hand.  Moreover, the ability of a particular programmer to be  
productive in a particular language or framework depends so much on  
that programmer's experience with said system.

> (The other is that the
> licensing is completely unclear, because patchers must send changes
> under an AGPLv3-incompatible license, yet the project is AGPLv3'd.  It
> makes no sense, and would make it impossible for me and many others to
> contribute.)

This, I believe, is a more serious issue.  I noticed that problem  
too.  Actually, I can't figure out what they're doing:
	http://civicrm.org/licensing
Their lack of explanation doesn't help either.  It's just "here's  
licensing terms to apply to your code when you give it to us."  I  
don't trust this, and I would not want to donate code under these  
terms. My guess is that when you license to them under the Artistic  
License, that allows them to build proprietary forks with your code,  
if they wish.

Maybe we should rule out CiviCRM for this reason alone, unless we're  
prepared to make an all-free fork (as with Joomla).

I believe in free software that remains free for all, without the  
possibility of proprietary forks.  I am prepared to sign over the  
codebase of OA to an appropriate non-profit organization that is  
committed to keeping it free forever.  And I would expect  
contributors to do the same.  I believe this is how core FSF software  
is licensed?

> Java is not a language that I am opposed to, but I am not likely to  
> look
> at OA until we have a tutorial that shows exactly how to run it with a
> Free Java system.

I will put this together.  I think it's going to be just about:
  1. Install the system.
  2. Install the appropriate Java packages.
  3. Run OA like you would on a non-free system.
But we will see when we see.

> I am ready to use all the political capital (not
> lots, but I do have some) I can burn to get the Free Java folks I know
> involved to help try to get it running, once we're at a point where  
> they
> can be helpful.

What I really need is just to know which IcedTea builds out there  
today are actually 100% free; that's what's stalling me now.  I can  
take it from there.

> I understand Dave's point about not wanting to sacrifice nice system
> design for a plugin architecture, but I think it's worth keeping it in
> mind.

As I mentioned before, a system that allows subclassing and  
overriding can help with this.  I don't know Perl very well, but I do  
know that OO features have become quite widespread these days.  So a  
system of extensions based on subclassing and overriding should be  
possible (I imagine) in many languages.  It's worked surprisingly  
well so far for me.

> Also, Dave, Josh Berkus has argued frequently for trying to push  
> some of
> the unchangeable workflow logic (i.e., database integrity certainty)
> down into database stored procedures.  One reason this is helpful is
> that it can often mean someone can write applications directly to the
> database itself, since they are unlikely to "break" anything by not
> using the standard APIs, since the stored procedures will stop them  
> from
> doing something stupid.


I've built a DB this way in the past.  OA does not use stored  
procedures (except for a few), but rather uses a kind of equivalent  
client-side "stored procedure."  As always, pros and cons of both.   
And I'm not against moving this logic into stored procs either; one  
big advantage of stored procedures is they can reduce round trips  
between server and client, as well as bandwidth.

PostgreSQL now offers stored procedure engines in Java, Perl, etc.   
So it should be relatively easy to just move existing client-side  
code directly into the database.  MySQL seems to take the more  
traditional (and easier for them to support) route of offering just  
one stored procedure language, which is not Java or Perl.  Both these  
choices seem to be in keeping with cultures of these two similar-but- 
different database systems.

-- Bob