Housekeeping for this Loomio group

I don't know that "the code is already out there", meeting the original OAE goals: purposefully aligned, open source, interconnected, quality, skinnable, supported, small and mobile. In fact I'm pretty sure that some required coding (esp regarding APIs and interoperability) will only happen if we develop the knowledge commons you wisely indicate @strypey: reviews, case studies, HowTos, handbooks etcetera. Not to mention, open source signaling protocols which could potentially circumvent any 'need' for an OAE coordinating/ stewarding team.

I work on open source person-to-person signaling protocols and collaborative frameworks. The OAE vision could crucially complement such tools (from any sources) as long as we prioritize human interactions, and become increasingly conscious and intentional regarding the actions we automate. I.e., focus on inclusively developing our software specifications, and IMO, let the code follow-- more or less per an essay of mine.

We could use that GH repo, but text can be stored almost anywhere, and I would prefer to be using a free network service, one not owned by a monopolistic corporation with a history of fighting against software freedom

I'm open to using open source alternatives to GH, etc; however, I think we're in a war (hopefully of ideas, not people) and I'd consider it unwise to refuse using the tools of the 'enemy' (multinational corps) if that refusal might sabotage our activities. Most cultural & tech revolutionaries I know, myself included, live precariously on limited resources. This includes many people & teams who provide open source alternatives to multinationals like Google; and I think it's important to be mindful to not multiply our points of potential failure.

For example, I use GH and GDocs extensively, because I literally can't afford to depend on alternatives which might vaporize either suddenly or gradually. Nor can I even really afford to do thorough research to ensure that specific alternatives are practically as stable (both technically, and in terms of attentive human support) as GH and GDocs.

I don't feel very dependent on GH and Google because it's easy for me to frequently export GH data & GDoc text.

With all that said: Yes, text can exist anywhere, and this could potentially include an effectively distributed/p2p directory of media resources. (Easier IMO if true distributed computing like Holochain effectively develops, but also possible without it.) We could probably even simulate distributed versioning with the right person-to-person protocols. That's kinda up the alley of my work; however, it's quite a lot of work to coordinate people in consistently performing predefined cooperative actions. In my experience, most people aren't anywhere near ready to reliably do that except when they're keenly motivated by direct personal (not collective) compensation or extractive profit.

For a start, I'd like to suggest again that we make more use of the editable context boxes at the top of each thread, to harvest the cream of each discussion.

If you think that you, anyone else or all of us could help facilitate some process which effectively and inclusively harvests the cream of each Loomio discussion, and advances OAE goals, please go for it: but I perceive that as being a labor-intensive process, requiring dedicated curators. I don't expect it to be P2P, because it will privilege whoever can afford to spend the most time curating. It could work, nonetheless, but I think that'd proceed slowly & methodically through inclusive 'baby steps'/ adjacent possibilities.

Regarding the origins of the OAE group: I suppose that one hope was to develop a code commons on Github; however, I'd also guess that creators felt flexible about how OAE might eventually manifest. I think that Joshua Vial (already tagged), @ahdinosaur and Simon Tegg may know the history most personally.

Seems to me, the important overviewing @strypey is proposing needs to be done in ordinary English, in spaces shared with app users? As distinct from dens of code?

Suggestions are welcome for what platform to use, either an existing service, or a piece of software and an offer to host it. For example, would anyone be willing to host an instance of Ward Cunningham's Smallest Federated Wiki (SFW) for use by the OAE group? The federated wiki offers the intriguing possibility that in future, each app and service group that has people participating here could run their own SFW instance with their own copy of the OAE knowledge base, so that no one group has overall control of its development.

@strypey @mikeh8 just wanted to say thanks for putting some thought into housekeeping and organizing this crazy bunch of content! :heart:

"the code (like the truth) is out there, and the real challenge is to strap it together, and convince people to use it instead of the datafarms. So the outputs of this group need to be knowledge commons; reviews, case studies, HowTos, handbooks, and so on. But beyond that, where are we going to a) collaborate on such texts, and b) publish polished recommendations for the people we hope to make use of them?"

My own two cents, that @strypey already knows, in part:

• "the real challenge is to strap it together, and convince people to use it" : YES, +100 to this. with one specification: let me repeat that IMNSHO, the only way to convince people to use it is to offer it as a service, i.e. as something you can get (let's ignore the cost until we agree on this, is my view) with a few taps on a smartphone, hosted somewhere in the cloud. If all we produce is a nice package with a wonderful manual on how to install it manually on your own server, it's useless.

• "where and how we are going to collaborate and publish": as fas as I am concerned, that is the last of the problem. I could do that anywhere, for all I care. What I personally need to do it is being paid appropriately, for long enough to produce something decent. Otherwise I cannot afford to spend so much time on this, it's as simple as that. Of course, without good howtos, studies, etc, it is waaaay more difficult to find sponsors, I know that very well. It is the chicken and egg problem that has me stuck since about 2013. And is the reason why I have been saying from the beginning that whoever can do this http://per-cloud.com please DO go ahead by yourself with my thanks, just give credit where credit is due.

• This said, I've done a bit of thinking in the past about this. See for example the "looking for sponsors part" of http://per-cloud.com/percloud-proposal-2017/ , and then the rest of that website, starting from the current version of the proposal in the sidebar. Hopefully that is useful starting points for doing what Stripey describes.

@strypey Group conveners could also make use of the Loomio Gold 'tag' function now available in this group. And some pinned threads?

@strypey "I would prefer to be using a free network service, one not owned by a monopolistic corporation with a history of fighting against software freedom" Yes! In addition . . as a non code-hacker, I don't find Git repos generally easy to access and to find stuff in. That may be culture and lack of practice on my part. It's partly the (small) barrier of getting a login to get access. So . . pls think quite broadly and 'publicly' about "where are we going to collaborate on such texts, and publish polished recommendations"?

"make more use of the editable context boxes at the top of each thread" Definitely, exploit the thread headers. It might be that Git repo users don't routinely do much of this recurrent reframing, which might account for the difficulty I have finding my way to human-readable content and over-view?

Seems to me, the important overviewing @strypey is proposing needs to be done in ordinary English, in spaces shared with app users? As distinct from dens of code?

There have been at least two or three threads through this group:
* hosted collections of usually existing open source apps that may share a single signon (or not, but I think they usually do);
* hosted collections of usually existing open source apps with a dashboard and some navigation and some other shared features;
* flocks of usually new open source apps that work together via common protocols and vocabularies.

Examples of all three approaches continue, sometimes announced here, sometimes not.

And I might have missed an approach or two...but I can identify all of those.

Harvesting the discussions would be a wonderful idea.

One other thing regarding housekeeping, @joshuavial, @gregorycassel, or @richarddbartlett may be able to correct me on this, but as I understand it, the original goal for the OAE group was to produce a code commons, which is why there is a link to a GH repo on the front page.

I think most of us now realize that the code (like the truth) is out there, and the real challenge is to strap it together, and convince people to use it instead of the datafarms. So the outputs of this group need to be knowledge commons; reviews, case studies, HowTos, handbooks, and so on. But beyond that, where are we going to a) collaborate on such texts, and b) publish polished recommendations for the people we hope to make use of them?

We could use that GH repo, but text can be stored almost anywhere, and I would prefer to be using a free network service, one not owned by a monopolistic corporation with a history of fighting against software freedom. For a start, I'd like to suggest again that we make more use of the editable context boxes at the top of each thread, to harvest the cream of each discussion.

@mfioretti again I encourage you to start a new thread where can discuss the details of your PerCloud proposal and related issues. Just go to the main page of the Loomio group (https://www.loomio.org/g/exAKrBUp/open-app-ecosystem), and click 'new thread'.

I know it doesn't seem to make a big difference if when using Loomio by email. But when we work together to make sure our comments are appended to the relevant thread, it's a lot easier for folks to follow the conversations using the web interface. Opening new threads on new topics, allows us space to dive deeper into them, and makes it easier for new members to find the discussions most interesting to their projects.