Continuing on with my geek volunteer efforts, after some conversations with the ‘client’, we discovered that not only do we want to collect some information via forms, but the folks who fill out these forms will want to register for classes and be paired with a mentor.   Aha!  That starts to sound like a customer relationship management (CRM) system or one of the learning management systems that lots of colleges are using lately.  I knew of a few open-source solutions, and figured this was a good reason to do some exploring.  Idea on my part is that a custom app ought to be the last resort, unless the custom app provides a real advantage to the group.  Otherwise, someone’s gotta be willing to take on maintenance and hosting of that app if I’m hit by a bus / win the lottery.  This application isn’t, at least at this point, something that this organization wants/needs to invest in.

Open-source CRM – after surveying a bit, narrowed in on SugarCRM, specifically its community edition.  Its AGPL license is a challenge in terms of integrating other capabilities were I need to extend Sugar, but since I’m trying to go with vanilla and just use its customizations, believe it’s readily workable.

Open-source LMS – the clear community leader at the moment is Moodle.  As its GPL, rather than AGPL, the license headaches are mitigated a bit, as long as the group doesn’t attempt to share out its source.  (Note: not a open-source license expert: statement is my understanding – confirm before assuming it’s right..)

But licensing will only matter if the solutions are the right fit…

Shortening the story a bit…  I went ahead and stood up a Moodle instance on an EC2 instance.  I found a plugin to collect survey information related to student classes.  Since Moodle had that idea of surveys + people, adding SugarCRM to the mix definitely seemed the wrong way to go.  Moodle installed nicely, as did the plugin, but in the end, it just felt like the wrong use case fit – too much complexity, and then not enough control over the user experience.  Note: were I to customize the Moodle code or write a new theme, I assume I’d have had full control.  But it was a higher hurdle than I wanted to leave for those who came behind.

The same underlying technology stack that Moodle uses is also used by a composable system called Drupal.  Headed that way for part 2 of this app…

Working on a simple application to let a group have a set of forms in which they collect data. Something like a simplistic form of WuFoo which lets the group update their forms and save the data to a backing data store.

First level idea: use Google Forms. Forms are very readily editable, even by non-technical folk, data’s saved to a backing spreadsheet, and you can use Google’s tools for analysis.

Implemented a first pass solution:

Advantages:
– data validation, either through their selections, through regular expressions, or (not yet tested) scripts
– really easy to share the form’s editing and responses with a set of collaborators
– very easy to add new elements
– the control set (textboxes, checkboxes, etc) are non-sophisticated but OK for my needs

Disadvantages:
– No great way to handle theming. You can pick from a set of stock themes, and there’s one sitethat seems to have found a way to handle it, but definitely not something that seems like it’s embedded in the core capability. Since I expect the group to need to adjust this ongoing, this is probably a non-starter
– No great way to link records.. e.g., if I have the same user fill out multiple things, no good way to connect them through.

OK… committed to taking a look at a first-level solution, and this doesn’t seem to be the right one. Next I’ll look at a hosted open-source solution.