Fri 10 Oct 2014

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

Simon Tegg Public Seen by 189

I've been thinking a bit about this loomio group and Derek's and Kurt's recent comments.

My sense is that we need a shared understanding of processes in this group. Forming working groups in specific areas (which already seems to be happening in the Linked Data discussion) is one active idea. Another one is regular (monthly) updates from different teams.

Sitting behind these are cultural practices like the way we communicate with each other.

What kind of practices do you think would be valuable for us?


Simon Tegg Fri 10 Oct 2014

I came across this little blog post the other day and the follwing quote seemed relevant.

"The ideal forum is when a bunch of people who are individually working away on their own personal projects--whether songwriting or photography or any other endeavor--get together to share knowledge. Each participant has a vested interest, because he or she needs to deliver results first, and is discussing it with others only second."


Caroline Smalley Fri 10 Oct 2014

@simontegg: possible to set up a cobudget account for proposing jobs with related budgets for integration tasks? is part of what I'm wanting to help fund through sponsored hangouts. why not get the process started now? get the wishlist going in a way that enables us to discuss proposed solutions in open / transparent way. @joshuavial ?


Simon Tegg Fri 10 Oct 2014

@carolinesmalley cobudgeting tasks is possible.
But I was thinking at a more basic level. Specifically to how this loomio group functions.

For example, there are currently 3 subgroups: Stakeholder needs, Interface Design and Technical. They're not used very much. Perhaps, these aren't appropriate? Perhaps there are others that would be more appropriate?

I also notice that I am starting the most of the discussions, and the discussions often wander over a variety of different topics. This can make the group hard to engage with for the casual reader, and harder for the group to come to clear outcomes.

I am suggesting that if we had smaller, more focused, actively-used subgroups we could be more effecive.

Related: http://www.businessinsider.com/science-behind-jeff-bezos-pizza-rule-2014-9?IR=T


Alanna Irving Sat 11 Oct 2014

I think I'd like to see some clarity around who is here, what they are working on or interested in, and how the group as a whole could support subgroups to effectively work on various areas of the ecosystem in ways that complement each other.

For example, people focused focused on technical research could be guided by outputs from a group exploring on the conceptual/philosophical level, and could create outputs like guidelines that other groups working on specific software implementations could use as a resource. To get different groups forming, they need more of an identity around what's bringing them together, how they want to function, and what their goals are.

To complement and resource other groups in the ecosystem we'd need subgroups to do good communications, reporting back, etc. It's an interplay between looking at the big picture, and focusing down on achieving something specific.

As I typed that out, it occurred to me that many of us have spend a long time building up an ecosystem with exactly the supports needed to facilitate autonomous groups brought together by shared values to collaborate and enhance each other's work, including communications, pooling finances and funding shared projects, and leveraging a shared brand and network to have bigger reach and opportunities. It's called Enspiral.

Is there a reason why OpenApp wants to be separate? Because it seems like we'd need to redundantly reproduce a lot of the same structures for OpenApp subgroups as already exist at Enspiral.


Apostolis Xekoukoulotakis Sat 11 Oct 2014

I would suggest to start from a specific problem and then split it into its sub parts etc. The root of this tree should have the goals of each project, and at the leaves, we would have the code. All discussion should be technical, even when we talk about the goals.

The point where we start having an opinion is the boundary of our ignorance. Since we are all ignorant of many things, the lure for discussion is big.
But ignorance goes away with experimentation. We do things, we find where they fail and we fix them or rebuilt them.

For this to work, it must be possible to create subgroups of subgroups and preferably allow all to be able to join by default.


Bob Haugen Sat 11 Oct 2014

@alanna - how do most of the people in Enspiral think about the OpenApps Ecosystem?
As part of Enspiral?
As something started in Enspiral that wants to be bigger than Enspiral (like, Enspiral would be part of it but not the only part and it might go global)?
As a distraction from getting the daily work done which is not about OpenApps but about existing software products?
Something else? All of the above depending on who is talking?

And what do you think of the discussion around it so far? I'm trying to parse some of the comments from Enspiral people and wanting not to do the wrong thing. I feel like I'm in Enspiral's house and possibly misbehaving.


Alanna Irving Sat 11 Oct 2014

@bobhaugen a bit of all of the above, I think! There's never one answer to "what does Enspiral think" because there will always be diverse perspectives, all of which are valid.

I think this take is probably common:

As something started in Enspiral that wants to be bigger than Enspiral (like, Enspiral would be part of it but not the only part and it might go global)?

I don't think you're in "Enspiral's House" at all, really. We are more of a bazaar than a house. Enspiral functions more like an open source project itself - you can make a pull request and join the main branch, or fork it and do something else using the parts of the structure that you like, or whatever you want really. There will likely be subgroups and projects that exist in the OpenApp ecosystem and are vary much part of Enspiral, and others that aren't.

If OpenApp did want to reproduce many of the structures we've developed to facilitate internal collaboration, but not be part of Enspiral per se, that's totally fine - I'm just concerned that there might be needless redundancy in doing so since everyone has limited time and resources, and there's a real benefit to joining something already ongoing instead of reinventing the wheel - but only if that's right for the project.

One thing I'm excited about with OpenApp is that it seems to be a magnet for other groups and people outside Enspiral to come together around these ideas, and there's potential for some of their DNA to come into Enspiral. I want us to share what we're doing, but also learn a lot from what others are doing. There's a technical side to all of this, but personally I think the real powerful stuff is about pioneering new group processes to facilitate effective open and decentralised collaboration in conscious ways.


Bob Haugen Sat 11 Oct 2014

@alanna - "One thing I’m excited about with OpenApp is that it seems to be a magnet for other groups and people outside Enspiral to come together around these ideas,"

Yes! That's us.


Simon Tegg Sat 11 Oct 2014

@alanna I lean towards the more open end with "subgroups and projects that exist in the OpenApp ecosystem and are vary much part of Enspiral, and others that aren’t."

I think there are identity issues with having the ecosystem almost wholly within enspiral. There are groups and people with established identities. if the locus was within enspiral they might feel less ownership and this would limit scale and contribution. This happens a fair bit in open-source projects when the code is hosted by an established company.

I would characterise Enspiral as small-to-medium teams and companies with a medium-to-strong shared common identity. Supported by cultural practices that support this identity (retreats etc), and reaping the benefits that come from this.

I was thinking of the ecosytem as an experiment to see if small teams with a small-to-medium shared identity where we "just agree where we intersect" could scale with a deliberately lighter touch on the organisational side.


Simon Tegg Sun 12 Oct 2014

I would also add that I think we're doing ok, its just that the outcome-focused comms aren't so publicly visible whereas the "blue-sky" and "visions" focused comms are.

For example, the main area we need to "agree where we intersect" is on vocab. This working group is already up and running and producing outputs, despite sub-optimal usage of loomio ;). I take this as a good sign.

Another area of coordination is building microservices, components and tooling to support the ecosystem. Colab.coop peeps and other contributors are interested in this side, but coordination comms with them and within openappjs are through hipchat, email, hangouts, and github issues.

If different groups made a commitment to form subgroups, and consolidate reporting back to the main group, I believe we could get ease the main tensions people might be feeling.


Alanna Irving Sun 12 Oct 2014

Monthly reports would probably go a long way, and wouldn't be that hard to coordinate. Even a paragraph long report from each subgroup would be awesome.


Simon Tegg Tue 14 Oct 2014

@elfpavlik @bobhaugen @lynnfoster @tiborkatelbach @carolinesmalley @jonrichter would love to hear your thoughts.


Lynn Foster Tue 14 Oct 2014

@simontegg and all - Sorry for the silence, a bit heads down now, and sometimes not conscious enough of communication. Responses to the discussion so far:

I would also lean towards the more open end for this work, to make it feel more like players interacting as peers, rather than visitors to Enspiral. Not that visiting Enspiral is bad.... :)

Small sub-groups seem to be working well, from my corner of visibility into the process. @bobhaugen and @ahdinosaur and I have been working on pieces of open vocab, and making nice progress.

I agree monthly or more frequent reports would be really nice. I appreciated Simon's last report. That would help us not be too isolated, and people could jump in with concerns etc. without going through the pain of sitting through the nitty gritty detail.

I would be interested in what groups have formed in Open App and what each of their goals are.


Jon Richter Wed 15 Oct 2014

Still thinking. As my thinking is based on slowness and long-term causality, I will present my views when time's ready. Patience is a virtue.


elf Pavlik Wed 15 Oct 2014

Thanks starting this discussion and for mention @simontegg!

I really appreciate your sensitivity to identity issues. I agree that many people may feel more comfortable to engage with Open App ecosystem than Enspiral organization.

I would also like to ask if people heavily engaged in Enspiral tend to gravitate mostly around discussions here or you also engage in various mailing lists, other forums (many projects host dedicated discourse instances), issues in github repositories etc. When we talk about decentralized systems I see a challenge that no one can position oneself in a center of such development :D

I must admit not knowing so much about organizational practices of Enspiral. I would like to learn more and compare to how groups like http://www.youcoop.org , http://engage.is etc. operate. Do you have some information about Similar Organizations or event some analysis of similarities and differences?

When it comes to group work, I'll try to reflect on my experiences with W3C, OKFN, OuiShare and some other networks and share some more feedback then!


Bob Haugen Wed 15 Oct 2014

@simontegg - hope you won't interpret my commenting silence for unhappiness. Everybody is saying a lot of good stuff, I'm just signifying with likes.


Tibor Katelbach Wed 15 Oct 2014

I agree with Elf , but to answer specifically Simon's question , The Group should be as open as our apps should be .
for any community that wishes to follow an open App dynamic.
Since it is quite hard to give structure to such a distributed initiative while everyone keeps their autonomy, I think glue that links us all is in our common goal and beliefs that working together, on identical and interoperable semantic technologies and open Apis is the way to build this common initiative.
I really beleive in frequent meetups with short term goals.


Caroline Smalley Wed 15 Oct 2014

Hi friends. Just wanted to let you know I'm laying low at the moment. Had to say goodbye to 4-legged love of last 14 years Friday just passed. Time of transition.

That said, I am getting back into things. Focus is on the proposal I'm developing in relation to CM that's based on very similar intentions as expressed through this group. I'll endevour to share an exec summary with you sometime in next 4/5 days.
In appreciation, C


Simon Tegg Thu 16 Oct 2014

Sorry to hear that @carolinesmalley, look forward to your update.


Caroline Smalley Thu 16 Oct 2014

thanks @simontegg .. much appreciate


Simon Tegg Tue 21 Oct 2014

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


Aaron Wolf Tue 21 Oct 2014

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.



Simon Tegg Tue 21 Oct 2014

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?


Lynn Foster Wed 22 Oct 2014

@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.


Joshua Vial Wed 22 Oct 2014

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.


Aaron Wolf Wed 22 Oct 2014

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.


Simon Tegg Thu 23 Oct 2014

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 :)?


Bob Haugen Thu 23 Oct 2014

@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.


Lynn Foster Thu 23 Oct 2014

@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.)


Mikey Thu 23 Oct 2014

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.


Lynn Foster Thu 23 Oct 2014

@ahdinosaur said: as for specifically Open Vocab versus Linked Open Data, i see them as more or less the same

I'm completely good with that.

In terms of our process, does that mean that we should create a sub-group in loomio, which corresponds to our (somewhat disjointed yet) group working on LOD? And/or one for each working group, like network operations, agent/person/org, etc? Or some matrixed type thing per your 2 sets of groups?


Bob Haugen Thu 23 Oct 2014

@ahdinosaur @lynnfoster

I like Mikey's two subgroups, but have some questions:

A. Some deliverables will have significant intersections on the same dimension, e.g. ovn and ipotables in economic networks (not sure that is the same as Network Economics, but if it is, good). How do we deal with that?

(I do want to get valnet off the table, I don't want the ovn vocab to be about a single software project except where we can derive ideas from that project. I think other people are also working on OVN software, or situations that are roughly similar. Valnet is limiting.)

B. Are LOD, Network Economics and Interface Design similar enuf to be in the same dimension? Or is Network Econ a different dimension? (As in the concurrent discussions about various methods of funding.)

C. Where would you put the LOD issues that are not about vocab? Or are they so much the same that they can be combined? E.g. like the meta-discussion about corporate biases, or noobie questions like which domain do reciprocal relations live in, etc.


Mikey Thu 23 Oct 2014


A. each team is independent and autonomous, they are free to do whatever feels right. some teams might want to focus more on delivering their "product", some teams might want to focus more on expanding the collective knowledge of the dimensions they are in, but both approaches are valuable and i think teams with different approaches will benefit from cross-pollination.

B. i think those are all different dimensions. i'd rather we have many narrow dimensions than a few really broad dimensions. for example, i'm starting to think the Technical subgroup is too broad, instead maybe it's more appropriate to have many groups for the various high-level protocols we interoperate with, such as Linked Open Data.

C. i think you should do what you feel is best, in my opinion these groups should be loose and flexible, not rigid and static.


Bob Haugen Thu 23 Oct 2014

@ahdinosaur - I'm good with that (A, B and C)