How do a bunch of Open Apps become an Ecosystem?
I have not seen this defined very clearly yet. This thread about defining Open App Ecosystem touched on the topic, but I'd like to focus explicitly on that angle.
There's a lot of open apps in open source land. What do we mean by Ecosystem?
Do we mean something that all these apps have in common? Or do we mean they can all work together in some way? Or both?
If they can all work together, how can they do that?
Anything else that might make them into an ecosystem?
@draft thanks for taking a shot at the question.
I really need a bunch of apps that can interact with each other economically, to form and conduct economic networks. And I think @gregorycassel has in mind apps that interact with each other to form and conduct agreement-based organizations.
SSO is good, but not enough. For example, the Mutual Aid Networks (one of the contexts we work in) use more than one system: @matthewslater 's Mutual Credit software, and a modified version of Wezer, which is a modified version of Odoo. They want SSO for both of those systems, but they also want economic interactions to happen between both of those systems. Matthew's new API is part of the puzzle, but Wezer will need to work with it, and the Mutual Credit system will need to work with the Wezer system.
And Fair Coop is even more complex: more systems, more interactions between systems required.
All of the organizations we know of have similar problems.
I really need a bunch of apps that can interact with each other economically,
If you need it, it will be done, we'll make actions to achieve it ;)
SSO is good, but not enough.
I completly agree :D
For the second part of your post, I don't know theses organisations, their needs, and their systems. So I can't tell much :D
I believe that the systems you are talking about could be improved to make them interoperable by nature. But that's just a belief as I don't know them.
What I see is we have a lot of actions to do and it could concern the apps, but the organisation behind them too. We need to create method to interoperate them all. And I do think these methods have to be as simple as possible.
For instance the action you will do with Tibor will be very useful for the objective we try to achieve together. The more you will do, the more we will get closer to the objective.
SSO is a possible way, not the only way. Let's experiment this one, and maybe we'll keep it, or find another one, we never know ;) Let's do it, we'll see if it works or not :D
Was it clear enough ? Did I answer to your interogations ?
2 others important goals for me are :
- having a friendly and very simple user interface for non computer addicts like us !
- having this Open App Ecosystem very quickly done and improve it continually
That's why I would like, personally, to start simple and easy to be done so we can quickly start using it with the ability to go in the direction we want.
The important thing is the philosophy : we need to have the same global objective. We could write a common charter and all we need after is to always develop new functionalitys respecting this charter.
to start simple and easy to be done
I think it's a nice way of working. It reminds me of the Mad Scientist Method of @ahdinosaur . Let's find something achieval and do it :D
I don't think a charter is a good idea. We just need a clear objective. For now here what it is :
The goal is to create an ecosystem of interconnected independent open source applications easy to use, install, configure and contribute to. This ecosystem will enable :
* the new economic and social system to come.
* to connect those who are building and using open systems.
* individuals with the same goal to work together.
How people do is up to them, everyone is free to make actions that s-he thinks is good for the objective.
The objective is pretty clear for me, but we can improve it if you want ;)
I agree with @bobhaugen, having an SSO and a plugin for each app is not enough to represent an ecosystem. If this is the goal we could just create a bot that centralize all the authentications in one single signup and create a dashboard to manage all the apps after the login.
But in this way apps would be still separated and would not interact togheter.
To create an ecosystem, imho all the apps should talk the same language, share the same protocols, and most of all they should share data among them.
Eg. a user could retrieve the list of his active tasks (previously created on his project management tool) from the chat app and create a new task directly from there, and adding the task deadline on his calendar. Another user could retrieve the list of her/his project collaborators from his wallet and sends some token...
all the apps should talk the same language, share the same protocols, and most of all should share data among them
I think it's too much technical for me. But it seems with a good API you can make interoperate apps. You just need to improve the API (here symbolized by the plugin for instance)
Eg. a user could retrieve the list of his active tasks (previously created on his project management tool) from the chat app and create a new task directly from there, and adding the task deadline on his calendar. Another user could retrieve the list of her/his project collaborators from his wallet and sends some token...
With a good API, it's easy to do.
To create an ecosystem, imho all the apps should talk the same language, share the same protocols, and most of all they should share data among them.
+1 !!
I think we have to figure out how to balance the goals of a true ecosystem (voiced clearly by @ivan116 ) and the goal of starting simply and iterating from there (voiced by @funkycram and others). I think the answer will be very specific to each step or problem.
For example, to me the SSO is something that can mostly just be done, it is the most stable method we have right now for authentication, as far as I can tell (although I am certainly not an expert). As long as it is done in a way that a different method of authentication can be swapped in in 10 years if technology goes a different direction, then we are good. (I understand one goal of the open app ecosystem to be to have smaller more modular apps so this type thing can happen, although authentication has some tentacles into everything for sure.)
On the other hand, some of the base connecting technical architecture I think we need to think through a bit. How do the apps communicate? Semantic web data, plugins, other? How do we get them to share vocabularies and protocols? Should we agree on vocabularies? Should we consider mapping vocabularies using a standard structure? To some extent we can just start and iterate, but not in the same way as writing one small app of many. And is there some way we can also make connecting methods flexible and optional? I hope we have the technical expertise to answer some of these questions, and the ability to figure out what might be best for the future in a somewhat volatile technical landscape in the P2P world.
Thoughts?
To some extent we can just start and iterate
Yes ! :D We just need to do things and documentate about it, then we'll see how this ecosystem works ! We can't see it clearly now, it's just by doing things that it will get clearer.
What do you think ?
What do you think ?
That's why I wanted to list what is happening now. I think more is happening than what has been listed so far. Where's @mikey for example? I know he and https://www.rootsystems.nz/ are working on a bunch of things that are most likely part of the open apps ecosystem. He was one of the original OAE founders.
Yes ! :D We just need to do things and documentate about it, then we'll see how this ecosystem works ! We can't see it clearly now, it's just by doing things that it will get clearer. What do you think ?
I think it depends on the question at hand. I think we need to thoughtfully distinguish between what we can do very much with Agile, and what we need to step back and do a bit of design for. I'm not suggesting waterfall methodology by any means, just to be a bit careful and make the best collective decisions we can when needed, especially as we ramp up.
"Doing things" requires many hours of actual work on the part of devs, in most cases unpaid. I've certainly thrown away my share of code in the interest of getting something people can use so I can get feedback, and I see that as often necessary. But some ecosystem wide decisions can imply a huge investment of code before we figure out it was a bad idea - as well as to discourage some people from joining if they are not-well-thought-out decisions.
Let's take it case by case for a bit and include as many people as we practically can, but continue to move steadily forward and not get stuck. And understand our own individual and collective state of knowledge, what do we know and what don't we know.
Good for you?
I think we need to thoughtfully distinguish
Why shall we distinguished ? If you want to design a method (or process, or protocol, or rules, or norm, or something that people will do in your action), you can do it :D
to step back and do a bit of design
Designing something is an action ;)
make the best collective decisions
How can we make the best decision ?
on the part of devs
Not just dev ;)
huge investment of code before we figure out it was a bad idea
The method I propose put the right to make mistakes in his foundations. You can't really know something is a bad idea until you make it and realise it was a bad idea. What you need to do in this case is come back to a previous version which works (thanks to the documentation you have made) and continue your work.
to discourage some people
The method create the contrary actually, when it's well assimilated. People, thanks to the freedom they have, will be more creative, and they will do more actions than if they were in a classical decision making method.
The method was designed to not discourage people, by making small actions they can achieve and historise their work to always go back in time.
If you try to make collective decision (which can take forever), and impose the decision to the group, you will discourage people. It happens all the time.
When people are in the action, and free to do whatever they want, it's totally different, and they can't be discourage, cause they are doing what they truly think to be good to fulfill the objective.
But I mean, you could ask people their opinion about your action. It's not another method that impose a vision. You are free to do whatever you think to be good for the objective.
We could test what I wrote here to start, and then see if it works, if it doesn't, let's try something else.
Perhaps we both need some time off. :) I took your statement as kind of let's each just go off and do what we want without thinking or discussing. I see you didn't actually mean that as you explain it more.
It's good we work some of this out, sometimes it's hard in text.
Yeah, and english in not my native language :D So it gets even harder ! But at some point we manage to understand each other ;)
the action you will do with Tibor will be very useful for the objective we try to achieve together
Hope so.
I mean :
* either everybody uses it, and it's good
* either nobody uses it wich means we found another vocabulary even more good
In all the cases : your work will be useful
What we are finding is that although common vocabularies are important to communication, it is really difficult for everybody to agree on the same vocabulary, so an experiment with mapping between vocabularies might help.
And then there's also common protocols, which I find difficult to get people to understand. But when different apps try to do things together, they will run into the protocol problems, and then they will understand. It's like the Internet is a set of protocols. Very few people knew they needed such a thing until it happened...
[edit] but for apps to work together organizationally and economically, we need another layer of protocols on top of those that already exist.
protocol = method ?
Protocol = message sequence, messages and responses, leading to a result.
HTTP is a request-response protocol between a client and a server, where the client can issue a message using one of the standard HTTP methods (Get, Post, etc) and the server will respond accordingly. It is one of the layers in the Internet protocol suite.
OSI defines 7 layers. Layer 8 is either economics or governance, depending on who you ask.
Conversation for Action is an example of a layer 8 protocol.
All of the algorithms we list here become protocols if used in a P2P network. All the participating nodes need to understand what they are supposed to do.
If they do, we can get something like this:
.
I didn't quite understand your explanation about what you propose as protocol :D
I surely don't have the skills to understand. Or maybe I just need a week off :P
You do have the skills to understand. I haven't found the 30-second explanation yet.
Think of conversation for action as, I request something from you tomorrow, and propose what I will do in return (give you a kitten). You respond, "how about next week? And I don't really want a kitten." So I say, ok, next week, and how about a cake? You say, ok, good. Then next week you fulfill my request and I give you the cake and we decide if we are both happy with the result.
Better?
Why do you request from me ?
Why don't you request from anyone ? And anyone could do it for you.
And if the person who did something for you need something, he will request the same way.
I'm not sure what we are talking about, protocols ?
I really think I need a week off :D
I'll come back stronger !
Sorry, I seem to be communicating really badly with you. I was trying to give you a simple example of the kind of protocol I was talking about. I wasn't really asking you to do anything, and I will not actually give you a kitten or a cake. Those were intended as silly parts of the example, hopefully for fun. Apparently not so much...
@lynnfoster (and I agree ) is talking about a "small" master plan :) . Without a plan well designed, mapped out, and fully realistic , the ecosyst&éem will remain a theory and hard to acheive.
@bobhaugen @mikey what is OAE ?
what is OAE ?
Sorry. Open App(s) Ecosystem
Now think of that conversation conducted between two or more apps...
P.S. @matthewslater 's API for offers and wants might be the starting point for those kinds of conversations between apps. But the API needs the whole conversation flow to match and agree on and satisfy the offers and wants.
I'd love to learn more about your work @matthewslater , sounds interesting
and compatible , with what we are doing o our end as well
It could be cool for each or any of us here , to do a recorded session explaining what we are working on, with screen shares etc , in a max 25min format , wdyt ?
always better than a list of words explaing what we are doing , no ?
I made a picture to start thinking about what this really could start to look like. It is very simplistic, and needs to go much further to support @ivan116 's view above of what an open app ecosystem could become, quoting:
To create an ecosystem, imho all the apps should talk the same language, share the same protocols, and most of all they should share data among them. Eg. a user could retrieve the list of his active tasks (previously created on his project management tool) from the chat app and create a new task directly from there, and adding the task deadline on his calendar. Another user could retrieve the list of her/his project collaborators from his wallet and sends some token...
But I hope it will at least start us thinking about it. I attached a png (couldn't see how to include it in the comment). And it is editable by anyone with the link, feel free!!! I used draw.io, but it is saved in a google drive, sorry! https://drive.google.com/file/d/0B6Rd5fQ-CZheYWJITFpqZGFwM0k/view?usp=sharing
One interesting thing I realized is that there will (hopefully!) be lots of functional open apps that will make themselves interoperable in the open apps ecosystem. But there are also core "utility" apps that every functional app will probably need to interact with to become interoperable within the ecosystem.
Do the core utility apps need some kind of OAE governance? I'm not in a hurry, just food for thought. Or, do we support multiple SSO apps for example, and there isn't really a difference between "utility apps" and "functional apps"? Thinking out loud....
Seems like a nice start to me :)
Btw, it's always good to update the first thread, like that anyone who didn't follow the first answers can catch up very easily ;)
Like a summary of what have been said for now, and what we kind of agree on.
Do you want to do it ? Or do you prefer me to do it ?
@draft please feel free
Basically an ecosystem is a system of interconnected system (a network of system). Here, the systems are the apps (I'm sure you knew, but it's just to clarify ;) ).
Here we need to find what kind of interconnections we do want for this ecosystem.
The @funkycram 's idea is to create an SSO for the whole ecosystem, which means when you connect to one app you connect to all of them.
The second point is to create a plugin for each apps of the ecosystem, it would enable the possibility to activate a top menu bar in every apps of the ecosystem. This menu would provide the best way to reach all the apps in the ecosystem.
For example, I contribute to three actions at the moment :
* Open App Ecosystem
* Communecter
* Commons Transition
Thanks to the open app ecosystem, I could easily see all the apps in connection with these three actions.
For instance, for Open App Ecosystem we use several apps :
* Wekan as an action manager
* Loomio as a discussion manager
* Riot as a chat
We use pretty much the same for communecter :
* Wekan
* Loomio
* Rocket Chat
* Gitbook for the documentation
For commons transition :
* Loomio
* Mediawiki for the documentation
With the Open App Ecosystem, I could manage my actions really easily, see who contribute to it, easily reach the apps related to my actions thanks to the top menu bar.
I've not been exhaustive because I will introduce this idea when I'll finish all the documentation about it. I take a week off right now. So it will be ready in two weeks normally ;)
Feel free to answer us back anyway :D