Loomio integration with a no-corporate and open source groupware

I feel that this request is missing the point of open source.

We're not open source so that people can ask us to do as they think open source should, ignoring the market and survival requirements of a small company, it's so that other people can participate and contribute to the codebase, to do what they like with it.

I want to do what you are suggesting - the problem isn't that nobody has thought of this before, the problem is resourcing.

To solve this problem we need a large customer who wants Mattermost integration, or an open source developer with a a passion to work on this.

I do appreciate your support! However, at this stage, I'm not able to do as you request.

I sadly understand.

@Rob Guthrie what if we look at this from the other corner, act iteratively and first separate API from the services standardizing them like a normal protocol? So we can have service-agnostic APIs for task management, messaging, voting, user management, etc... So everyone can implement backends and frontends for these APIs using favorite language and technologies, and even get integration for free? More, these APis can be mocked and blackbox tests written without any service yet exists - which will should further reduce efforts for back-end implementation. I've created https://github.com/black32167/socialapi just to demonstrate that idea. It declares few APIs using OpenAPI yaml format and ATM generates client/server stubs for Java/JAX-RS ATM but can be extended to any language and stack we want. As a step on this way, is it possible/worth to opensource voting part of Loomio's API for start?

I don't think you understood my message. I will spend my time supporting end users who support me, through paying for Loomio. I don't see any end users or payment in what you've suggested.

Standardization can lower integration cost, thus increase likelihood of using service by other vendors. Integrations potentially can be billed in different ways (on per application basis, per user, per request, etc...). So, in theory, more integrations - more money. However I agree it will unlikely increase payments in the short term while requires certain amount of efforts to develop/refine API and billing schemas... But in case you'll get interested in that - I could try to help.

Well, there has been a request for Mattermost integration, that would be a great place to start. The Teams and Slack integrations would help you find ways to standardize.

I don't see any end users or payment in what you've suggested.

Imagine Loomio was well-integrated with suites of open apps, which could form a drop-in replacement for an organisation's use of Google Apps, or FarceBook, or other corporate datafarms. That could open up a whole new revenue model, where organizations pay a subscription to use the suite, and the income is divided between the development teams of the various apps in the suite.

I will spend my time supporting end users who support me, through paying for Loomio.

Is Loomio still a social enterprise? If so, revenue is necessary to the cooperative's sustainability, but not it's reason for existing. If it isn't, a lot of people who gave to crowdfunding campaigns, or made unpaid contributions to Loomio development over the years, might be interested to know when and how the decision was made to become a bog standard for-profit.