What kind of culture, and systems do we want in this loomio group?

I've been thinking about your question @elfpavlik. And l'll use it to talk about comms in enspiral in general.

Projects in enspiral will generally have a loomio group and a hipchat channel. Small-scale comms also happens through hangouts and and network-wide through a private g+ community.

Many projects are client-related and not open-source so having private channels (hipchat) makes sense for these. Hipchat is also user-friendly for non-devs and the main open free alternative (irc) is not. This makes less sense for open-source projects, unfortunately the network effects of everyone being on hipchat seem too great at this time to get people to switch :(. If its a code project then very specific stuff will occur on github comments with webhooks being routed back the group's hipchat stream.

Most things are do-ocracy based, in that the people doing the thing get to make, and are trusted to make, all the decisions about the thing. Occasionally, you won't know the answer to a highrer-level question, or you need team-wide buy-in, or you realise what you're doing has downstream impacts, or you need to make an announcement and want to ensure everyone will see it. For these things we start a loomio discussion. @bobhaugen's discussion on Corporate biases in LOD standards is a good example of this.

@joshuavial has made this repo: enspiral agreements for explaining some of the inner workings of enspiral.

Related: @ahdinosaur passed this on: async teams

I want to propose a bare-minimum about sticking to free/libre/open commons. Every single mention of the use of proprietary tools should come with an apology.

If you use GitHub or Google+ or Google Hangouts or any other proprietary tool, you should repeatedly and consistently feel obliged to say, "sorry about this proprietary tool…" and continually open the discussion to how to escape it or at least making everyone clear why the compromise was taken.

I understand and respect that we compromise often. So be it. But we should never have someone show up and just tell them, "oh go join this Google+ group". It should be at least, "oh, we use Google+ even though it's proprietary. It's not ideal, but it's how things are at the moment. Anyway, join us at …"

Similarly, it's not a bad thing (although less essential) to continually reference how nice it is when we use tools that are Free/Libre/Open (FLO) commons. We can say, "come join us at Loomio, a fully FLO platform!" As long as this issue is a major concern, we need to keep it front and center. Too many people avoid addressing it and stay oblivious.

Respectfully,
Aaron

To add further context re: FLO at enspiral.
Enspiral as a whole has no policy on the usage of FLO. Some ventures are based on proprietary software, (relatedly some Enspiral companies are traditionally structured companies). Loomio and Craftworks are probably the main centres of FLO culture within Enspiral and Aaron makes a good point for what those companies/teams could decide to do.

The dilemma for Enspiral is that comms platforms (and policies regarding them) are dictated by the the network as whole. So its debatable whether craftworks' people could introduce a pro-FLO policy network-wide.

The selfish dilemma for me personally is that if some of open-app comms shifts to an irc channel (which could be a good idea as much of the comms in the LOD thread is chat-like) it will be less connected to enspiral and I'll have to more effort into being 'the bridge' between the two.

Ignoring my selfish dilemma, what do people think about Aaron's bare-minimum policy? What comms platforms will work for OpenApp?

@simontegg my 2 cents in answer to your questions:

Re. FLO, I think all software recognized as part of Open Apps should be required to be open source, as well as all software used in the stack(s). People running any part of Open Apps should be able to use all FLO software. As a policy decision of the group.

Software used by Open Apps, such as for communications, I don't feel as strongly about. I agree we should make best efforts to use FLO options, and we at Mikorizal plug away at that as a sideline, but we don't let it become too much of a distraction. Even though our purpose is change of economic relations, our time seems more useful writing software, connecting with OA, etc.

I think loomio is a fine place to carry on discussions, I'd just as soon not be using different channels for related discussions. And I don't see any reason for @simontegg to spend useful time bridging the communications.

Agree that all the software in the open app ecosystem should be FLO and that we should have an aspirational target to migrate all supporting systems off proprietary providers.

I don't think being forced to apologise for using proprietary systems is the most productive way to go about migrating though. Instead documenting all the systems we depend on, identifying and monitoring alternatives and checking in on a quarterly basis feels like the way to go.

I also think it is reasonable to expect the FLO alternatives to be equivalent in terms of features and ease of use before we switch.

To clarify, I mean "apology" in the most literal sense. An apology is a formal justification. It doesn't have to be associated with self-shaming. The point is that people should accept the burden to pause whenever choosing to use proprietary tools, especially when it's a group thing where their use encourages others to use them. And we need all proprietary vs FLO tools to be always identified so that people acknowledge the issue.

Anyway, I do not agree that FLO options should have to meet complete equivalence. A FLO option that is truly feasible should be preferred over proprietary even if the proprietary option offers some non-essential benefits.

Loomio and Github are currently the only supporting software for the OA Ecosystem as whole. Loomio is FLO. Github is not. I suggest we park general FLO policy until this becomes more of a problem. Or someone can start a discussion on Github specifically.

It seems more pressing (to me) to have a better subgroup setup. I took the liberty of creating an 'Economics' subgroup as there's interest.

Another one would be a 'Open Vocab'.
I haven't been active in this area so I'm reluctant to 'meddle' in the processes of the people who have :). What say you people of open standards and deep interoperability :)?

@simontegg @ahdinosaur @lynnfoster and anybody else who is interested: I started a sub-discussion in the Economics subgroup to separate the idea of reciprocal value networks for software from the reciprocity license as a tactic to get there.

@simontegg I was going to start an Open Vocab subgroup, but when I actually looked at the whole structure, it was a bit of a happening. (Not a criticism, just the way things develop naturally.) For example, Linked Open Data and Open Vocab are related, Open Vocab could be a sub of Linked Open Data perhaps, or maybe they are just the same thing. But Linked Open Data is a discussion, not a sub-group. Unclear how to proceed. @ahdinosaur @bobhaugen @elfpavlik @tiborkatelbach and other LOD/vocab people, any thoughts? (Partly I'm just trying to learn about the loomio dynamic too.)

i've been thinking about subgroups like the Open Vocab group and am feeling there are at least two types of subgroups with the Open App Ecosystem:

1. groups focused on a single deliverable (valnet, craftodex, ipotables, etc.)
2. groups focused on a single dimension of intersection (Linked Open Data, Network Economics, Interface Design, etc.)

@lynnfoster as for specifically Open Vocab versus Linked Open Data, i see them as more or less the same. i started calling it Open Vocab because i got the openvocab GitHub org, but it's intended as a way for us to collaborate on the intersections of our Linked Open Data, in whatever way makes sense for the various teams involved.