Conversation from When can an instance develop something specific around the OFN platform?
Facilitated by: @Rachel
Known:
Questions:
Adding (If I haven’t missed your convo here) - one question an instance that doesn’t have a dev faces is - should they prioritize finding devs? I haven’t done so for example - I’ve prioritized funding proposals and getting legacy hubs up and running. Would it be better if I (or new instance) prioritized finding devs? I just figured it was better to contribute money to existing devs than look for new ones. Right choice? Wrong choice? Either way there are implications (as the dev team experiences) of an instance not having their own dev.
Maybe need to make my comment more clear. There is a ‘now’ and there is a desired future/goal. So - it seems we are trying to work out how to handle this now - in a situation like Can where we don’t have a dev and need some things done (zapier integrations, Canadian specific payment methods maybe…) But I"m also flagging an issue re our desired future. Do we want to build a situation where we encourage and help ? local instances to have their own devs? Frankly - I had the sense that globally we didn’t want me to be seeking a Canadian OFN dev, because (assuming that person works their way through our qualifying process) it would just dilute money to the current devs. So - any money we find here, is going to the global pot. If we had our own qualified dev, we would want to add them to the global team and pay them here eventually. I feel like - to be frank - we are at a disadvantage (integrations, but also just understanding sometimes some basic backend database stuff) because we have decided to support the global dev team. (love you all of course - I’m just putting it out there.)
I hope I am not too late to the party! Thanks for the ping @tschumilas and @Kirsten. My main question in this area is around stuff that most instances might not need/want but a potentially influential/large/well-funded user, possibly because of the way they are already doing business on another platform, wants to have (and is willing to fund the development of) as a prerequisite to coming on board with OFN. Examples would be the stupid non-metric weights and measures, which no one has asked for yet but may, and things like an item “countdown” which would be especially useful in bulk buying (like how many more kilos of bananas need to be bought before it makes up a case - we have a user who really really wants that to the point where they may go elsewhere if they don’t see that there is a plan for it).
For us in the US, who are still trying to lure folks over to OFN, the answer to many requests is either “it’s on the list but not yet scheduled” or something that translates as “we can put it on the list and it will get prioritized in some months but there are a lot of things ahead of it and likely it will stay on the list if it only matters to your business model or just to our instance so your choice is to adapt if you plan on using OFN the way it is even if you have $25k to pay for this functionality to be developed.”
I am mostly interested in the process for doing things that really only matter to one instance for now, like the changes that are legally required to invoices in France. I can see that some development is critical for one instance and irrelevant to everyone else - what is the process around this? How do we balance being a slow moving monolith on one extreme and utter chaos on the other?
So - lets separate apart - 1. features/wishlist items that need development and are things we want to be part of the global platform (that’s our main global pipe - and we have process for that. and then 2. things that are only for specific instances. I think there are not as many of these ? (payment gateways, zapier integrations come to mind). @lauriewayne1 - the examples you give - I think - are wishlist things many of us would like in the global platform. (Even the non-metric weights and measures as an option would benefit future instances besides the US maybe - not sure how many countries still use imperial measures) But part of our challenge is that we have yet to find a fair way for a user with money to call the tune and pay for a feature that we don’t prioritize globally. (But that isn’t the discuss here.)
@tschumilas okay so this is a discussion about instances developing a thing that is unique to them/unusable by others then? Like for example when UK develops a Zap on its own that is not in some Zap library accessible to everyone? I guess I just need to get educated: it seems like right now a user who has funding to develop a feature that’s on the wishlist (and presumably just waiting for resources to get done or maybe it hasn’t been considered/voted on yet), and who won’t/can’t use OFN without it currently has the option to (a) support what the global team has decided should be supported (with that decision being partially based on how much money/time is available as well as how many people benefit/how big the need is and how well a thing fits into the longer-term strategic direction for OFN’s common code base) or (b) go somewhere else. To me this is a process/policy that should be explicit as a way to set expectations with new users (maybe it is and I haven’t seen it - surely this has come up before - how do we handle it?)
More or less - yes. History - before our first ever global head to head in Australia last year, if a user had money to develop something, the instance went ahead and did it. BUT in Aus we decided we were working towards a single instance - ie: one code base everywhere. So to do that, we set up the global dev team, and the prioritization process. So now, as I see it, we have uncovered 2 things that need fixing. First - sometimes there are things specific to an instance - that never get prioritized globally because they benefit no one else. How does an instance move forward on these? How does an instance without a dev move forward on these? Can OFN-CAN for example pay for a global dev to do such things for us (Zapier…). That is the subject the global group is talking about. How to do this, without diluting our committment to a single instance/codebase, and without diluting global dev time.
But the other thing (kind of problem I think) is that sometimes, there are users with money - who want a particular thing. But that thing has not been prioritized globally. So - right now - we don’t have a process for doing that work. And, perhaps we lose users with money in the process. So - I think this is another problem - not sure how widespread it is - but I think its a different discussion - not the one we are having here - but still one we should have. Global meeting people — what do you think? Are you talking about the situation where users can pay for work that hasn’t been prioritized, but would benefit the global codebase?
Thank you @tschumilas, the history and context make it easier to understand and will make it easier to explain to people. I appreciate the explanation.
When should we have the discussion about how and whether we let people with money influence or change the codebase (although this can also have to do with non-tech projects, right?) and thus potentially the direction of our work? It would be a quick discussion if we said we only accept money with no strings attached and the global team always determines what gets done- is that the case