[software] Rapport2 (was Re: OffstageArts and CiviCRM)

Dave Rolsky autarch at urth.org
Fri Oct 24 15:32:23 UTC 2008


On Fri, 24 Oct 2008, Bradley M. Kuhn wrote:

> Every non-profit has a different workflow, and the problem is the
> existing systems are built around specific sub-area workflows (OA for
> Arts orgs, CiviCRM for campaigns/canvasing).  We need a more modular set
> of stuff that can model different workflows.

Rapport is also campaign/donor-oriented. It's also designed so that you 
can store information on volunteers as well (who are often also donors). 
In my organization, most work is done by volunteers, so being able to 
store info on them is important.

As far as modularity, my long-term vision for Rapport is to be able to 
integrate different chunks of features that people can enable or disable 
via config. It also has a pretty thorough custom field implementation for 
contacts (not yet coded but in the database ;), which shold handle a lot 
of custom workflow.

I'm _not_ too interested in a plugin API, as it seems like big apps with a 
plugin API end up becoming a mess for the sake of plugins. Instead, people 
would just code something that looks like any other Rapport module. The 
trick, then, is just managing database changes. All this is rather 
nebulous at this point, though, since my current goal is simply to make it 
work for my organization without hard-coding anything specific to our 
work.

>> https://hg.urth.org:445/hg/R2/file/9d4851bc14d6/LICENSE ;)
>
> I can't seem to load this URL due to port blocking issues on the network
> I'm on, but I am guessing maybe the ;) means you AGPL'd. :)

That is what it means, yes.

>> I do think in the long run that maintainability is important, because
>> it lowers the barriers to entry,
>
> I agree completely.  This relates to my obsession with test-coverage.
> Are you doing test-coverage for Rapport2?

I have tests, and Perl has an excellent coverage tool, Devel::Cover. I 
haven't run it over my test suite yet, but I plan to make that part of my 
ongoing workflow.

Ultimately, I'll have a continuous smoke tester & coverage system.

>> Also, I know that some Perl folks are on this list, so maybe they'll
>> like the fact that it's in very modern (aka Moose & Catalyst) Perl.
>
> This is modern for the Perl world.  OTOH, I hope we don't end up in
> language wars, or people picking systems by what language it is in.

Well, language does matter to some degree. Presumably, a system in 
something relatively obscure like O'Caml would be less appealing, just 
cause less people are able to hack on it.

My point about modernity is to emphasize that it should be easier to hack 
on than your typical "ball of mud roll your own everything" Perl app (or 
PHP, Java, etc app ;)


-dave

/*============================================================
http://VegGuide.org               http://blog.urth.org
Your guide to all that's veg      House Absolute(ly Pointless)
============================================================*/


More information about the Foundations-software mailing list