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:
Bring together groups/users committed to this process
Raise funds for the design process
Codesign the dream functionality
Develop delivery plan and budget
Raise funds for delivery
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?
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)
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)
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.
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
The next step is the more challenging but Iād be happy to work on this!
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 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
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
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.
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ā
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
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.
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
Following the two sessions Iāll compile what we discuss into a proposal for community approval.
Hey, this is a great initiative
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).
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.
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:
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
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.
After this we can prepare the estimate, and some resources to help fundraising efforts and go out and try and raise the moneyā¦
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
It is relatively small and easy.
