Communicating Open App

That's great advice @richarddbartlett

thanks everyone for contributing to this awesome discussion. :) i'd love to hear more about our visions for OpenApp and how we can communicate our collective vision. who would be interested in a hangout? http://whenisgood.net/zg474i5

also, i want to emphasize that @simontegg or i only represent a part of the whole. constraining to any single vision is bad, opening up to a diversity of visions is good, as long as we agree where we intersect.

in my next comment i'll respond more on the current discussion points with how i feel and how it relates to what i want to work on with regards to OpenApp.

I'm a little torn here, because I think what @richarddbartlett said is really important and would like to have a whole discussion about that. Maybe we should start another one that just focuses on that, and not the technical aspects?

(@ahdinosaur - looking forward to your next comment.)

At the same time, I want to hear more about plugin ecosystem and federated architecture...

P.S. @ahdinosaur I am not seeing the timezone option on the whenisgood page (mentioned in their faq). Anybody know how that works, or what timezone I am seeing? I would like to attend that hangout.

Love everyone's contributions. Personally I like the idea of 'tools to organise commons-based peer-production communities' is the perfect focus for open app. Sure, more traditional organisations might find these tools useful but we're actually trying to outcompete the traditional model so let's just focus on what we think the future should look like and let the past catch up under it's own steam.

I think there's broad agreement about how we communicate OpenApp in general. Confusion may have arisen because the current document has focused on the tech part of OpenApp (because that's the difficult part to communicate, and I still think its more strategic to get developers/entrepreneurs on board than it is to appeal to people in our vertical)

@ahdinosaur - when I responded using the whenisgood page, I got an error. I'll try again tomorrow. Or here is another possibility: http://doodle.com/.

(@bobhaugen: i fixed the whenisgood to include timezones. @lynnfoster: hmm, i just did a test response and it worked, but if it continues to be a problem we can change or you can just message me with your availability.)

as @borisfilipov suggested, i think there is benefit in scoping out our roadmap in terms of what deliverables we want to achieve, and then building up our infrastructure as we deliver.

i'd like to amend this strategy to be a balance between:
1) our short-term deliverables
2) our long-term design

and personally i usually prefer to take more time on solutions that are congruent with a long-term design instead of quick hacks, but that's just me and i'm happy if others prefer whatever is necessary to get software in the hands of users.

this is similar to the process we've already been following:
1) the deliverable is to support using Loomio groups in Co-Budget, and along that mission towards the short-term deliverable i've learned a lot about architectures/patterns/designs i'd like to see in OpenApp and recently started to put together some long-term system designs and short-term implementations that are not exact but at least congruent with the long-term design.
2) the deliverable is to create a user interface for searching people, groups, and related items within a network, and our long-term design is to have a generalized CRUD interface based on triple-store graph queries, so we've been iterating on designs for a "directory" while being mindful of when there is more information than just people and groups.

i think then we should lay out what deliverables we want, lay out how we each would want our ideal team to function and prioritize, and then organize into teams in whatever way makes sense. in the ideal case we all work as our passion drives us. @borisfilipov's comment is good as to what specific questions we need to answer as a team.

as for crowd-funding, i'm happy to continue working full-time on OpenApp without external funding, but if others want funding so they can work on OpenApp more, i'm happy to support that. however, as @bobhaugen says, i would rather focus on assembling our network and developing solutions than try to achieve financial nirvana right now, but i support a team with a focused deliverable trying to get immediate funding.

i think @josefdaviescoates is on point that we need better communication towards non-developers. and even within general developers, maybe Linked Data isn't the right focus. this goes back to the melting pot of all of our visions for OpenApp, as with diverse messages we can target communication to different audiences.

i really enjoy @richarddbartlett's idea to focus our message on "commons-based peer-production". that brings us back to @borisfilipov's comment, we should be using OpenApp to drive OpenApp. i would love if some initial deliverables focused on the economic infrastructure of a commons-based peer-production network like OpenApp, as well as the general needs of organizations like Enspiral, Camplight, etc.

now i need to write up a better description for the long-term design of the OpenApp.js stack i want to build. :)

Regarding federated architecture and graph search:

Currently, when someone downloads Loomio's source code and starts a new instance users would need 2 logins to access content on this own instance and the original loomio.org instance. While they may have started their own instance motivated by security concerns they may also wish to form groups from users across instances and easily invite users to discussions across instances. Its likely that instances off the main one are quiet because users don't see that much content but we really have no idea what's going on because users can't share data across instances. Each one is a silo.

On a federated architecture users and groups can share data across instances. You get your security concerns allayed and you get access to all the content across the entire ecosystem (if its available to you).

Lets assume a federated and discussion-first architecture. Users could start discussions from ad-hoc group of users. Graph search would enable you to start a discussion with "People who live in Wellington and have an interest in social justice" (a graph query). Graph search isn't that useful in silos, but it would be in a federated architecture.

I've just used a loomio-focused example, but there's plenty of other applications. A more near-term might be Enspiral using OpenApp for time-banking (amongst other things) and then agreeing with the Welington Time-banking community (on another instance) that our credits are interchangeable. What I like about this is it keeps the focus on people's identities and works around the social psychology. I haven't joined the Wellington Time-banking community, but I might do so through enspiral (my stronger identity)

@josefdaviescoates pretty much put my thoughts into words:

I was kinda hoping this project would be a little less ambitious and a little more pragmatic (like Loomio and Cobudget seem to be). As a potential user I’m really not too bothered about “graph search across the emerging Giant Global Graph” in the short term. I just want functional tools to use now. I think part of my fear comes from having known and met lots of tech people over the years who’ve had very similar goals and have also had a inclination to perfectionism - resulting in very little running code ever actually getting released (at least from an end user perspective), despite oodles of talent.

It's not that the beautiful technology and philosophy isn't important - it is, and it needs to be the foundation of the design and the motivation for the project. But I think the best way to express that beautiful technology and philosophy is through working software. It's through interacting with the people that want to use that working software and learning from them that the project will be steered in the right direction, and that social impact can occur.

@alanna - We (Mikorizal) agree totally that "through interacting with the people that want to use ... working software and learning from them that the project will be steered in the right direction, and that social impact can occur".

On the other hand, we already got working software. The way we work is to cycle between the general and the particular. So for example we generalized from a few previous projects before we started the NRP project with Sensorica. Now we are almost done with that and ready to re-generalize again. Which means to rethink everything, including the architecture.

So we are looking at what you all are doing and thinking seriously about whether we should go your way (tiny apps etc.). And if we did that, how would we go about it? (Breaking a huge system into tiny apps).

We had a lovely chat with @derekrazo and apparently will meet with more of you later today, so we'll see how it goes. But if we do that, we would only do so in collaboration with actual groups that want to use the software. We don't do product, we only do stuff that some live group that we like wants to use now.

"Group that we like" means that we think they are moving in some significant way in the direction of social/economic transformation.