Difference between revisions of "DevSummit07:Business Models for Software Development in the Nonprofit Sector"
m (1 revision imported)
Latest revision as of 23:08, 20 May 2015
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)
- Consulting – setup, new features, ongoing
- 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)
- 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
- 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)
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
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
Movement as Network – Gideon’s article Open Sources 2.0 (book)