In view of a crirtical situation with membership, income, paid hours and communication across ops members https://forum.meet.coop/t/sustainability-discussion/970/77 I propose an alternate agenda for this all-hands.
Two items, 30min each:
A short-term focus on rapidly engineering a slimmed-down platform operation involving one decently paid Admin person and a Tech team/person (decently paid?)? Who to occupy these roles?
Would/could this then be scaled? Adding further regional servers (eg Agaric’s proposal)? Adding labour-intensive relationships with users back in again? Etc?
Would this be a multistakeholder coop? A consumer coop? A worker-coop-ish free software project bringing in a small income and federating loosely with other projects/coops?
Etc?
A matching proposal on short-term marketing work (Business plan, Marketing plan, dramatic membership increase) based on @osbhttps://forum.meet.coop/t/sustainability-discussion/970/23 and comments that follow in that thread @Graham “marketing activity can shift focus from stopping the rapidly emptying bucket of paying members . . and filling it up”.
Questions include:
Alongside the slim-platform development above, could this also be paid work? Or is it further sweat-equity debt that might not be repaid? @wouter “We have collectively incurred around 50.000 GBP as debt towards the operational members”
How OK is that?
Is dramatically increased membership essential anyway (>10x), to pay wages in the slimmed-down platform operation?
Etc?
AN Other item? If the above radical slimming and concentration of work contributions is adopted, does it remove the pressure from the communication issues flagged within the Sustainabiity discussion?
Just a thought: consider decoupling the SSO work (which is underway) from the model Ben’s suggesting. In other words, this work will be beneficial no matter what meet.coop looks like going forward.
re: the last point on communication between users on tech issues, it seems worth exploring a ticketing system.
I also asked some questions about GitLab and its workflow management tools, but the feedback was that it was perhaps too technical for communicating project priorities.
thanks, @mikemh , that makes quite some sense to me, the two main discussion topics. The first is especially driven by tech.circle’s work on SSO and automation, something that as @andi points out, is underway and will be beneficial no matter what way fwd. And the 2nd would be a combination of marketing, with overall vision, and importantly with a rethinking of how we pay for what work to make sure that it is worth the work, while advancing on that shared mission.
Maybe gitLab could do the work, also for non-technical stuff. But here’s a doubt: we want members to file incidents, desired features requests etc. The feature requests can then be categorised and validated properly by ops, while all members could vote for the feature. That’s what other projects do quite well in various git platforms, right? My doubt is about the account people would need to participate in this process. Can it be done with the SSO account people will have? Without us needing to maintain yet another server (gitlab). I guess there are solutions to that, like the IndieHosters have done for their keycloak authenticated gitlab server.
A rather small paid group (one paid admin staffer + some bountied coms/mkt work + some paid dev/tech circle work)
Equals a version of @benhylau ‘s SaaS model (slim workers’ coop plus thin user interactions?), modified by adding bounty payments as a stream of costs to be explicitly funded.
Working under a multistakeholder Board, maintaining the coop-community vision?
with a mission statement that includes multistakeholder User contributions and Collaborator contributions on a par with a ‘viable thin workers coop’ provisioning model of (paid) Ops contributions?
Questions include:
Does this all hinge on the size of the bounty fund? Would bounty-work in marketing or tech development be starved, and end up needing to be done under sweat equity, as now? How does @osb feel about that possibility, for example?
Who in our Collaborator/Ops community has the skills and experence in making this kind of workers-plus-community governance structure work? Are they available to work for free (eg as a Board member) or would they need to be staff (paid)?
If @benhylau is correct, all this is luxury fantasy. He might be right. Can anybody do the numbers on this?
I’d say 10x the MRR then it’s ok to think about the overhead of a bounty system. But by then probably it is better to have consistent staff on part-time recurring salaries. Managing a bounty program is probably a lot more work than you think.
For example, the person scoping it has to define it very well. Acceptance criteria, etc. Meetcoop does not have an abundance of technical PMs who can define a proper bounty + acceptance criteria… it’s more likely that the dev duals as TPM. The risk of failure is high if passed to an unknown person. If it is same person doing the bounties all the time anyways, why not just pay them a salary? Why do we choose the path of maximal overhead?
Of this list, the only thing that was my recommendation is “one paid admin staffer” with a budget to spend on dev and mkt as they wish. The rest are all overhead and non-essential to delivery of service.
yesterday’s notes. Most people seem to agree that it is time to put effort in outreach, i.e. deploy a marketing plan while driven by the core team, but supported by the community around it.
Yesterday we seemed to have consensus that we need to scale down the paid work part and simplify the compensations. Oli suggested a three person team; and distribute the gross monthly margin over them until we have doubled or tripled our userbase, and evaluate end of year.
Agenda
