DevSummit07:Business Models for Software Development in the Nonprofit Sector

From DevSummit
Jump to: navigation, search

Facilitated by David Geilhufe, CivicSpace, April Pederson and Chris Lundberg, DemocracyInAction

Sustainability is an unsolved problem in the majority of nonprofit software development efforts, but inspiring success stories exist in a range of contexts. Cooperative and collective approaches to software development and services will be studied in detail, and stories of success, failure and points in between will be the currency of idea exchange.

Business Models: 1. Consulting (FLOSS/proprietary) 2. ASPs (FLOSS/proprietary) 3. Open APIs (proprietary becomes more like FLOSS)

Session Notes

Income Models

  • ASP
  • Consulting – setup, new features, ongoing
  • Support
  • Philanthropic
  • Product licensing
  • Donation/ tip jar

Most of these models depend on scale, especially if you’re focusing on small nonprofits, rather than huge nonprofits ready to invest. Because of this, you need considerable investment capital while you get to size.

Support costs stay the same, though, even though the size and money goes down. A tiny nonprofit is likely to call you as much or more as a mid-sized one. As products and systems improve, though, and with economy of scale, it doesn’t keep going up and up, though.

For Kintera, 60-70% is from a tiny number of customers (like 20 customers)


Investment Capital

  • Foundation- not really an ROI expected, but rather social outcomes. Not tremendously reliable – long cycle. While it’s compelling in the ideal world that nonprofit software dramatically improve efficiencies for nonprofits (for instance, foundations support a number of organizations in buying GetActive), this is a hard sell for foundations. Group builds are a bit more compelling, as they can be aligned specifically to funder interests
  • Donations
  • Government
  • Commercial (angel investment, venture capital)– not going to fund unless they see a profit in it, might withhold money unless you do what they want
  • Collaborative funding – multiple organizations chip in to fund (pizza party model)


Costs

Innovation – cost of feature creation Support – providing ongoing support – this can be driven down with usability Acquisition – marketing and sales

You can drive all of these things down via usability, great features, terrific products – but this takes experience. And experience takes money.

For open source projects, building a critical mass of volunteer developers can also really help drive down costs


Consolidation

There’s been a lot of consolidation of late – what does that mean?

  • Mature markets tend to consolidate, it might be inevitable
  • Might make it hard to break into the market, because it’s already saturated
  • But there’s still the long tail for the right product


Resources

Movement as Network – Gideon’s article Open Sources 2.0 (book)