Collective Feature Purchasing for CiviCRM and FOSS: Alternative to MIH

Screenshot of a CiviCRM Make it Happen project box titled "Discount codes for events and memberships": a progress bar from $0 to $4,500.00 at 24%, "Raised $1,060.00 of $4,500.00", 4 donors, a description that the project will allow administrators to create discount codes for events and membership, "Campaign is ongoing" and a "Learn more" link.

http://civicrm.org/mih

Original slide 6 (image)

Slide 7: Custom code developed

Custom code developed

Pros

Quick
Running site with code implemented

Cons

Expensive
Difficult to maintain (upgrade)
No shared expertise benefit
No public code review
Often hardcoded options to save cost = low customizability
Variable documentation

Original slide 7 (image)

Slide 8: Sponsoring sharing of code

Sponsoring sharing of code

Pros

Long-term support
Benefit of public review / shared expertise
More customizable / generic interface
Better documentation
Easier maintenance / upgrading

Cons

More expensive (more development needed)
Benefit of public review limited if no support offered (for modules not core)
Possibly less flexible

Original slide 8 (image)

Slide 9: Contribute to an MIH

Contribute to an MIH

Pros

Cheap
Long-term support
Benefit of public review / shared expertise
More customizable / generic interface
Better documentation
Easier maintenance / upgrading

Cons

No precise control over features
Functionality only available with upgrade cycle
Difficult to fit in with organizational accounting

Original slide 9 (image)

Slide 10: Alternative: Collective Feature Purchasing

Alternative: Collective Feature Purchasing

Original slide 10 (image)

Slide 11: Collective Feature Purchasing (CFP)

Collective Feature Purchasing (CFP)

Several organizations get together around specific feature (feature set) that they identify as having in common, contract with a developer (company) who will implement the features taking into account specific implementation needs of individual contributors.

Original slide 11 (image)

Slide 12: Collective Feature Purchasing (CFP)

Collective Feature Purchasing (CFP)

A CFP collective can also work with the Civi Core team to determine roadmap synergies and needs for future maintenance. E.g. will the features be modules or rolled into core code base?

Original slide 12 (image)

Slide 13: Collective Feature Purchasing (CFP)

Collective Feature Purchasing (CFP)

CFP collectives can be ad hoc or more permanent. Members can join or opt out of specific CFP rounds.

Original slide 13 (image)

Slide 14: Collective Feature Purchasing (CFP)

Collective Feature Purchasing (CFP)

Key difference between CFP and MIH is greater transparency and accountability on both sides. A successful CFP round would end up with all contributors running actual code on their website.

Original slide 14 (image)

Slide 15: CFP – Pros / Cons

CFP – Pros / Cons

Pros

MIH < Cost < others
Control over features
Benefit of shared expertise
New features translate to immediate site functionality
Easier maintenance / upgrading
Easier accounting (hopefully)

Cons

Potential contractual framework complexity
Agreement on features among CFP partners

Original slide 15 (image)

Slide 16: CFP Spec Framework (Uservoice)

CFP Spec Framework (Uservoice)

Screenshot of the Dropbox Votebox page, "Votebox lets you decide what we work on next!", with red boxes and arrows marking the In Progress and Completed tabs, the "6 votes left" counter, and the vote counts (131662, 95124, 86060) and comment counts of the ideas "Watch any folder", "Sharing permissions" and "Better (more affordable) storage prices".

Original slide 16 (image)

Slide 17: Anybody wants to work on Events?

Anybody wants to work on Events?

http://bit.ly/civieventwishlist

CiviEvent Wishlist (#CiviCRM)

Posted on September 1, 2011 by Dominik Lukeš

We have been using CiviCRM for event management for over a year. This list covers the sort of things that might be needed by an organization running a wide range of events and courses of different types.

Event management

Easier search: There should be an equivalent of the quick search bar for contacts for events. We run close to a hundred events at any one time and it would be nice if we could access them from the front screen. The workaround using Views/Finder works but doesn’t provide access to all the event functionality.
Configurable event dashboard: The dashboard as it is now is pretty much useless for us since it only shows about a dozen events (we need a quick overview of many more) without any clear indication which events make it there. Also, it would be nice to be able to choose the columns displayed. E.g. event type is irrelevant to most admins but they would appreciate more granular registration count display. This could be built in Views in Drupal except, Views don’t seem to have access to counts of users. Plus the links provided by views to event configuration and participant listing appear to be broken.
Multiple changes to event configuration: Often we have lots of events that need to have a small change made to them – e.g. the event price or location or default profile. It would be nice to be able to make those changes at once. Also, it would be nice to be able to edit event dates and things like registration status inline without having to go to the whole edit interface.
Participant info: Better access to participant info would be really great. It would be great to be able to configure what is visible at a glance or have the participant profile expand similarly to what happens on case listings.

Event functionality

Multiple registration paths: We need to register tutors, volunteers and students for the same event and it would be nice if we could have a different registration page for each. Particularly for paid events where only internal staff get to attend free. Showing a free option on the registration page is unprofessional and confusing.
Internal/hidden prices: At the very least, it would be nice if we could have internal/hidden prices for events. At the moment, if we want to give somebody a special price we have no way of accounting for it in the database. Some of this could be accomplished by CiviEvent discount http://drupal.org/project/civievent_discount
Post registration contributions/Partial payments: We have a number of events where the participants have to go through an approval process before they are asked to pay. It would be nice if we could associate contribution pages with specific events and have those show up as fees. Even better, it would be nice if multiple associated contributions would add up to an event’s fee (for instance, deposit and full payment).

Original slide 17 (image)

Slide 18: Anybody wants to work on Events?

Anybody wants to work on Events?

http://bit.ly/civieventwishlist

4. Internal/external event titles: This is a small but annoying feature. We would like to be able to refer to events with internal titles that would be used for internal listings and long descriptive titles that would be displayed to students. This way, managing events is cumbersome within the existing interface.

5. CiviAdmissions: Many of our events require the student to go through an admissions process. We use CiviCase for this at the moment but it is a big too big of an overkill for the job. It would be nice to have some sort of an event admissions workflow to manage event status. Perhaps per event type event status list with notes on each status and a record of event status changes on the event screen. Or an integration with CiviCase where a case status would trigger an event status.

Profile behavior

Multi step profiles: This has been mooted elsewhere before. Here’s a nice way of how this can be accomplished but it would be nice to have this as core functionality: http://civicrm.org/blogs/kurund/using-civicrm-profile-survey
Private profile titles: The profile titles show up on the registration form as is which makes it impossible for us to manage over 100 profiles effectively since we can’t name them in a descriptive way: “Short event initial info – Version 2 since May 11″
Profile field logic: This has also been discussed. But we could really use “If you check X, Y becomes available/compulsory” kind of logic on profiles.
Multi value fields in profiles: This is also not new and is standard functionality on most forms. http://forum.civicrm.org/index.php?topic=11563.0
Contribution/participant fields on non-event related profiles: Very often we want to have participants submit additional details that we want associated with their participant profile and/or a contribution. It would be nice to be able to associate specific profiles with particular events and their related contributions.

Original slide 18 (image)

Slide 19: Discussion

Discussion

Photo of three white geese standing on ground covered with fallen autumn leaves.

http://www.flickr.com/photos/ktylerconk/3045268759

Original slide 19 (image)

Slide 20: Tweet comments @techczech with #civicrm

Tweet comments @techczech with #civicrm

The historical Twitter logo: a white lowercase letter t on a glossy light-blue rounded square.

Original slide 20 (image)

Collective Feature Purchasing for CiviCRM and FOSS: Alternative to MIH

Slide 1: Collective Feature Purchasing for CiviCRM and FOSS: Alternative to MIH