A proposal for fundraising for features

As a global community we have most certainly reached the point in which we need to diversify how we bring in revenue to this organisation. One of the obvious and under-explored ways we can do this is to fundraise for work on specific features.

Why do this?

We have a rich global community and strong reputation meaning that people will trust us to develop features. Our global community often have access to funds and would be willing to pay for features. We are not making use of this opportuntity even though people tell us they would like to pay for features.

Why not do this?

In the early days of the global OFN we experimented with this and it created problems. The problems came because features were underfunded and there was not enough money available for core costs, maintenance or tech debt. This meant the OFN product fell into quite a bad state that we have spent years recovering from.

So why do this?

We’ve learned our lessons from last time. We’re a much stronger team with much stronger processes and we know the value of keeping on top of our technical debt. We’re ready to re-explore this!

So how would it work?

To me it is important that:

  • If we fundraise for a feature we fundraise for double the capacity. The people/resources assigned to the project will spend 50% of their time on the project and 50% of their time on other tasks.

  • We unfold projects in stages:

  1. Bring together groups/users committed to this process
  2. Raise funds for the design process
  3. Codesign the dream functionality
  4. Develop delivery plan and budget
  5. Raise funds for delivery
  6. Deliver
  • Managing our pipe when we have delays for fundraising will be a key challenge. In order to maintain our team in between features we’ll need to be bringing in revenue from other sources. User fees, grants and donations will also be important to maintain.

  • Features that we develop will need to be features that we know there is a demand for and that we can make the case will bring in sufficient user fees that we will be able to cover maintenance++ from the user fees they generate. Features cost money AFTER they’ve been delivered too!

Why are you raising this now?

The UK is constantly being asked for subscriptions functionality from large box schemes. We’d really like to trail this process on subscriptions 2.0. Soooo, I’m putting it out there. What do y’all think?

5 Likes

Ping Instance managers
@Eugeni @Kirsten @tschumilas @lauriewayne1 @hernansedano @romale @rafat-khashan @berniemabbs @Cecilia-Hn @lin_d_hop @VPotvin @Jen @lbwright22

And delivery team
@apb @Jana @Erioldoesdesign @Rachel @Kirsten @sauloperez @Matt-Yorkley @maikel @jibees @filipefurtado

I think awesome and let’s do it. Thank you for taking the lead @lin_d_hop. It would be good to discuss capacity - particularly as I imagine some need for early investment in design perhaps even before the funds land (i.e. design helping to motivate people contributing)

1 Like

I think we can chat with @Erioldoesdesign about design interns :wink:

1 Like

design interns for something as significant as subscriptions? I am hopeful but cautious

Really happy about this topic and the timing. I was just contacted by our biggest hub about processing for online SNAP (food benefits provided by the USDA) which currently has to be done offline, sometimes in a snowstorm in Vermont. This capability has mostly only been available to big retailers like Amazon and Walmart, and to larger brick and mortar stores with an online component. Being able to process SNAP would be huge for existing users, and could be a game changer in terms of new users in the US. It’s totally US-Centric, I think it would be really complex and big and expensive to implement, and I believe there is probably a lot of funding opportunity from the USDA and others. Having a process for a project like this within the bounds of OFN (like without forking the code, if I am using that term right) would be hugely helpful.
(background: it’s a really heavy lift)

2 Likes

Great proposal. Let’s try it again.

There are a lot of steps before the funding though and I’m wondering if that will be funded in retrospect or just be covered by the global team. And that preparation is crucial for the success of the project.

Our current rules are that we don’t promise delivery dates. It’s probably good to set the expectation in these projects as well that we have an estimated delivery time frame but we never know about delays.

The process sounds like a waterfall model which is important for the funding part but should only be on a high level. We still need to apply agile processes in delivery to make this successful.

2 Likes

I think the idea is definitely nice.

But it’s a heavy job. Not only in needs strong design, but it also needs strong product management.

I think if we want to try this out we need to try it on something small first, with a circle of hubs we know and trust. Therefore I wouldn’t start this with something as huge as subs. I’m not saying this model cannot work for subs, just that starting with a big feature has a high risk of seeing its delays and budget exploding.

I wouldn’t spend any time on design before the funds are engaged. This is the best way with ending up with unpaid design.

There are a lot of aspect like this that we need to discuss. When people pay for features, they are not ready to pay for time. It’s an important step: paying for features means paying for a defined scope. Whether or not it requires (additional) time.

Anyway I’m not sure the purpose of this post was to go into detail. I’m available to push this further :slight_smile:

The next step is the more challenging but I’d be happy to work on this!

2 Likes

Agreed.

I actually think the lead time on subs would give ample time to try something else first and still prepare the beds for subs work… Just bringing people together for subs will take months and both rounds of fundraising will be long and not a process to be rushed.

I think this would make a good first project :point_down: It is relatively small and easy.

The advantage of working on that as a first project is that it simultaneously unlocks another revenue stream - the annual takeover of the feature by OFN to fundraise globally (in the way wikipedia do an annual fundraising drive). I think this global fundraising purpose can justify the decision to work on this first while we clarify some other surrounding processes…

I’m really keen to continue driving the explorations… though not at all sure what it means to have agreement on this kind of decision :thinking:

2 Likes

How about splitting the decisions process step by step? Like here we decide on the general idea. Then next step for example is to decide on a feature, next one after that on the rules between participants etc

1 Like

Sure.

So step 1:
Are we keen to explore this general process?

I’ll bring this to Product Curation on Monday.

Note we will not be choosing a first feature in Product Curation. We’ll be figuring out how to agree to commit to a general process for a first trial.

1 Like

In convos with users and funders here, there is often a point where - when I say, ‘yes, that features is on our wishlist’, they will ask, 'how much would it take?". So - it would be nice to have a way to answer that. Even if the answer was - phase 1, to scope it out, would take… But if we can’t give people who are interested in specific features even a prelimianry estimate, then I’m not sure how to proceed.

For example- today, a fairly large CSA wanted to have specific payment methods attached to an order cycle (public shop, tagging not possible). I said it was a wishlist item we had identified. They asked if they could help with it - how much would it be? I couldn’t answer.

I know that many CiviCRM community folks do a similar approach to feature development with limited and…complicated success? Mostly around 'if a feature is built not in core then updating features that aren’t part of core becomes extra dev maintenance labour.

I think the tricky thing about giving an ‘exact’ amount to build something is that scoping and investigating what is needed is work and therefore needs funding and we get into a ‘loop’ of needing funding.

I do think there’s a way of doing this though! in a ‘fund the MVP of a feature and then X months of maintenance’

Thanks to everyone for your inputs so far.

Last night in Product Curation the Delivery Team agreed that this is a proposal worthy of more investigations.

We’d like to TRIAL a SINGLE feature in this way.
Just to be clear - this will be a trial. This means that it is too early to start telling users about this idea.
Also note that we’ll be trailing with a single feature, so it’s too early to pull out that scrolling feature list you’ve been keeping.

We need to come up with a way to decide which feature to select for our trial. The ideal feature will have some specific characteristics that make it different to other features in our Wishlist. In particular:

  • It will be reasonably small. This is because smaller features are easier to estimate and less risky to the community.
  • It will have wide appeal. This is so we can include a wide section of our community in the process. Ideally shoppers, producers, enterprises and instance managers will all be interested in the result and see the power of our global community!
  • It will be interesting. We want to inspire our global community with this feature. Things that are too technical, or boring, or about compliance are probably not the ideal first feature.

As a next step I’d like to invite anyone interested to join a meeting so that we can explore potential features ideas and how to decide, as well as the next few steps.
Please fill in this doodle if you’d like to join.

In the meantime please feel free add any other thoughts you might have in this thread :slight_smile:

Thinking on this more… It seems to me there are 2 different (perhaps complimentary) types of features to do this with…

Type A - features we imagine charging users for in the future (ie - the costing would require a business model that charges for the feature explicity once its developed - and maybe users who contribute financially get the feature for free or discounted for a period of time)
Type B - features we imagine being accessible to all users as part of their user fee

Originally when I read this, I was assuming Type 2 - because in Canada, we don’t charge for any specific features. We’ve talked about it - but in the end, we think a better marketing strategy is to say that users get all features, all the time for one price - because other platforms (including shopify which is the most popular ‘other’ e-commerce platform here now among our user group) charge for extra apps so the user can do what they need to (ie - run a marketplace/farmers market using shopify) - so users are really hating that. They feel pulled in only to later learn that they need to pay more.

SO – I think we have the most to gain with Type 2 features - low relative cost, broad appeal, everyone gets… (I have a list of suggestions - and have put my availability in the doodle)

Also just reminding (it was a long time ago) – in 2019, we rolled out a thing at trade shows that we called Community Supported Software - join OFN, and we’ll match your user fees, and for one year only all that money will go to develop new features for everyone. We raised $10,000 for global pot (this is the $10,000 we ‘reserved’ to help kickstart the US instance) So - it worked pretty good even in a tiny instance like CAnada was back then.

Might be useful in the context of what your are talking about @tschumilas

1 Like

Hi everyone,

The Doodle did not have a clear date so to ensure everyone can participate I am going to split the session.

I’ll host two sessions:
8am GMT on Tuesday 16th
8pm GMT on Thursday 18th

Please come to one or both. Both are in the global calendar.

In both sessions we’ll be exploring:

  • What are the criteria for choosing the first feature to joint fundraise for?
  • What potential feature do you think might work well as this first feature?

Note - if you come just because you want to pitch a feature that is very big, or a feature that only benefits your instance, then you probably won’t have a great time :wink:

Following the two sessions I’ll compile what we discuss into a proposal for community approval.

1 Like

Hey, this is a great initiative :clap:
I would just like to add that we should avoid making mammoth initiatives when there’s no need for them. Are we not ready to stop talking about the big elephant called Network 2 and break it in smaller more manageable parts, let’s say 3 or 4 projects?
Same for subscriptions v2, I think we can list, at high level, what are the different parts of subs v2, so we can make them more manageable, and more fundable.
I am saying this because some of these smaller parts of network but specially subs v2, could be good candidates to start this.
Like, we don’t want to find funds for this huge project called subs v2 but we could try to find funds for “users can edit/customize their subscriptions in the FrontOffice” (subs v2 example) or “enterprises can make their catalog available to other enterprises to search and source their shop” (network v2 example).

4 Likes

One key thing about this idea for me, that makes it different from how we do our current wishlist and item selection, is that the issue is framed in user language, and not in our language. I totally concur it needs to be small - but to engage our users, it needs to be exciting – which could be big. So - maybe one way to think of this is we describe a collection of small issues within a big exciting picture and we bite them off one by one. So we might say to our users - we are fundraising to make improvements to our shopfront. We are starting with adding the option to show stock remaining, and to show sold out items. (I’m not pushing this - I just know that this is a big want for our users)

I also like the idea of the donate button as the trial - very focused and clear, and lots of users would appreciate the need for this.

Meetings Summary

Thanks to everyone who came along to the meetings about funding features last week. They were both great meetings with huge overlap in some ways and big differences in others. It was really interesting to do the session twice and receive quite diverse input from the two different groups.

You can see the notes from both the meetings here.. If you don’t have access to the Global Drive just request when you open the doc and we’ll grant it.

Criteria

Between the sessions it was widely agreed that the following criteria were crucial for this first feature.

  • Have a clear, discrete scope: It is already well defined. This will mean no complex design processes or complex legal/product requirements on this task.
  • It is small in size. 2-3 days dev time + design, review, test. Keeping to a small size should also limit the maintenance on the feature.
  • It will have wide appeal and impact. We want many users and instances to appreciate this contribution… and to fund it!

Cautions

There were also some pretty clear cautions from folks about traps we must certainly avoid with this first feature.

  • Don’t have a fixed deadline. We are not yet good at estimating.
  • It must not be something fashionable eg AI or IoT

Delivery Process

  • We will follow our existing delivery for this task including user guide process.
  • We will offer delivery date estimates for first release on staging only. Not for completion.
  • We will estimate this task before beginning and during completion.
  • We will compare estimates with reality via time tracking
  • We will retro on the task.
  • We will select the task with a transparent process involving instance managers and delivery team.

Next Steps

To continue on this journey I propose:

  1. A session with delivery folks to go through all the features that were suggested by people in the meeting and consider them in relation to the size and scope criteria to create a shortlist of potential features that meet our delivery criteria
  1. From this shortlist I will create a survey tool to share with the community to guage which is the task with the widest appeal. We’ll need to know both if instances want it and if they think they might be able to raise funds for it from some of their users. Hopefully this will inform which feature we choose to go with.
  1. After this we can prepare the estimate, and some resources to help fundraising efforts and go out and try and raise the money… :tada:
  1. Note that so far this work is not on our Roadmap. We have a little time before we get to the point of actually needing to deliver the work so in the background via Delivery Train and Product Curation we can continue to discuss what it means to our processes to include this task in the upcoming priorities.

I just want to acknowledge that there are a lot of scary things about this process. I deeply encourage everyone to express your fears with an open heart. Everyone’s fears will help us grow wisely. Our ability to sit within the fear and continue down the path anyway takes courage… and certainly our world needs our courage right now :heart:

2 Likes