List of all the open apps which could be great in the ecosystem

app topics i'm interested in, in order of general to more specific:

(i wrote these down somewhere, but off the top of my head...)

• person / group directory: Holodex
• secret management
• blobs (file attachments, media)
• notifications (emails)
• async discussions
• real-time chat
• decisions / polls / ideation
• time tracking
• knowledge management
• inventory management
• offer / wants (intents)
• memorandum of understandings (commitments / contracts)
• invoicing ("hey, here's a payment request")
• accounting ("what is happening now?")
• forecasting ("what do we expect to happen over the next few months?")
• tracing ("where did this come from, where is it going?")
• ...

supply chain product ecosystem, from what we're interested in working on at Root Systems:

(each is fractal: can be applied as person, group, or group of groups)

• buying: Cobuy
• finances: Nanox
• growing
• selling
• transport / tracking
• warehousing
• processing

I put your ideas in a google doc. If you have time, could you be more precise about the needs you see in this ecosystem (the one of the new world we are building) ? And then we could choose apps that answer to this need. Here is the document : https://docs.google.com/document/d/1Be7Z4zt6AGoGNcddObV1Z1njzlyivWlwZW39mTBStb8/edit?usp=sharing
Thank you ! ;)

supply chain product ecosystem, from what we're interested in working on at Root Systems

Do you know open food network ? I don't know in what way, but I think you could work together ;) (They are specialised in the food supply system)

https://www.loomio.org/d/C9Omyp6R/new-effort-architectural-mapping-of-software-tools

Do you know if there are any documents creating thanks to this thread ? Maybe @lynnfoster knows ?

See u ! ;)

oh yeah, i was thinking of this discussion: https://www.loomio.org/d/C9Omyp6R/new-effort-architectural-mapping-of-software-tools

As I believe I mentioned recently in a related Loomio discussion, there's a detailed list of ideas here: https://cta.hackpad.com/Survey-Canonical-tool-functions-sE0UyxlDMrn

That doc was developed by collective informal brainstorming during relatively intense discussion early last year in Collaborative Technology Alliance on Hylo. It closely parallels @ahdinosaur 's well-developed list in some ways, and includes some other concepts.

I note sometimes that there isn't any inherent need for many or most of these communications & organizational functions to be developed in separate applications. In theory, most of them could be achieved through a very small group of intentionally generic open source signaling and storage tools. I often focus on laying groundwork for such tools through the development of open standards.

https://cta.hackpad.com/Survey-Canonical-tool-functions-sE0UyxlDMrn

The best would be to fork this document and be more precise about the needs and how we can fulfill it. I prefer using google doc because it's the best shared document tool I know.

I'm gonna transfer the interesting datas from the hackpad to the google doc.

I note sometimes that there isn't any inherent need for many or most of these communications & organizational functions to be developed in separate applications. In theory, most of them could be achieved through a very small group of intentionally generic open source signaling and storage tools. I often focus on laying groundwork for such tools through the development of open standards.

I think that most of the tools exist, we just need to connect them together and put the same top bar in every applications to enable the possibility to switch between them very easily ;)

The best would be to fork this document and be more precise about the needs and how we can fulfill it. I prefer using google doc because it's the best shared document tool I know.

Google Docs is far from perfect, but I'd have used it instead of hackpad if I'd created those documents. Anyway, anyone can do anything they want with it. I backed it up a long time ago as a reference "check list" of desired functions, subject to ongoing editing.

I think that most of the tools exist, we just need to connect them together and put the same top bar in every applications to enable the possibility to switch between them very easily

You're referring mostly to tools which are directly maintained and controlled by exclusive development teams. Some of them, including Google Docs, are available only through proprietary licenses distributed by for-profit corporations. Also, while some of the platform toolsets offer currently unique functions, most of them are mostly redundant with other inefficiently exclusive efforts.

Nonetheless, creating such interoperability could certainly be useful. I'm currently too busy to invest directly in that goal, but I'd like to follow efforts.

You're referring mostly to tools which are directly maintained and controlled by exclusive development teams

I was refering to open source apps ;) I'm only using proprietary apps, because they are ergonomic that's all. My goal is to be able to work really easily on my labtop with open source apps, that's why we need to create this ecosystem ! :D

I'm only using google doc because it's far better than hackpad (I mean the suggestion and comment features are so great !). I prefer having a good environment of work than a bad one :) But I think I dislike google more than you all :D

I don't really understand the document though. Where are the needs, and what are the apps associated ?

I was refering to open source apps

Problem is, open source apps are directly maintained and controlled by exclusive development teams. The people in those teams, like all humans, face financial and ethical challenges.

Open licensing does help however. It creates the potential to legally fork a codebase, and that reduces the risks of intentional exploitation. However, a forked codebase often needs direct maintenance (with security updates, etc) by a specific team in order to keep working as intended.

We don't have quite the same problems with open standards/protocols. Open protocols (including TCP/IP & HTTP) don't usually need updating. They can and IMO should be updated-- as simply as possible!-- but they don't usually need it in order to keep working. Rather, they create a baseline coordinating function which software developers incorporate in their diverse acts of updating.

Hope that seems helpful and of course feel free to reply.

I don't really understand the document though. Where are the needs, and what are the apps associated ?

The doc was developed to indicate "canonical tool functions" in an open app ecosystem-- specifically within the context of Collaborative Technology Alliance, which (mostly) sought to develop an open app ecosystem.

CTA was directly inspired by the "Open App Ecosystem" concept, which goes back maybe 4-5 years & is the subject of this group.

That hackpad doc deliberately avoids associating functions with specific apps. It was meant as collective brainstorming to illustrate the digital communications & organization tools which various well-informed people perceived to be necessary for diverse global communities.

With that in mind, we're a bit off of your intended topic of "open apps" per se. Both Mikey and I referred to specific (but intentionally generic) functions insteads of applications.

There are no apps I'm aware of which I'd directly identify as an "open app". There are many open source apps however, and you should feel free of course to focus on them if you desire to. For me, an open source license is just one prerequisite in developing a fairly inclusive community software tool.

How would you describe an open app ?

How would you describe an open app ?

I haven't directly thought about that in a long time. I did mention (as an afterthought, really) that there are no apps which I'd directly identify as open apps... however, it's often easier to identify that an element or entity is not part of a set (or type) than it is to comprehensively identify the limits of that set.

For whatever it's worth, however, the following detailed and demanding description of "open source" seemed rather popular in Collaborative Technology Alliance in 2016. Perhaps it seems relevant:

6 freedoms (1) to run the program, (2) to study and change the program in source code form, (3) to redistribute exact copies, (4) to distribute modified versions, (5) to have access to their account data, (6) to use without charge for non-commercial purposes.

Additionally, I'd suggest that any development teams which officially release a "finished" (i.e. not alpha or beta) open app should use some specific open organizational principles, including clear standards for processing potential contributions to the code base. However, I haven't attempted to create a comprehensive list of such open organizational principles, because I've been too busy with other work.

Problem is, open source apps are directly maintained and controlled by exclusive development teams. The people in those teams, like all humans, face financial and ethical challenges.

Yes.

Open licensing does help however. It creates the potential to legally fork a codebase, and that reduces the risks of intentional exploitation. However, a forked codebase often needs direct maintenance (with security updates, etc) by a specific team in order to keep working as intended.

Yes.

We don't have quite the same problems with open standards/protocols.

Yes. But it's a "yes, but". The open protocols that work globally and are the easiest to join are the WWW stack. In order to collaborate in economic networks (as some of us want to do) or even social networks as probably most of us want to do, we need something on top of the WWW stack. We might also want to explore other protocols, like SSB, but even there, you need some software that will allow you to use the protocol, and it's harder to install than the Web browser that came with almost every device you might have these days. And to interact as an economic network, more needs to be developed on top of SSB, that the Scuttlers are just recently starting to experiment with.

So apps of some sort will be needed. I'll assume they need to be open source unless somebody wants to disagree. And they will need to interoperate in various ways if they are to be an ecosystem instead of just some random individual apps. So some standards will be required, that don't quite exist yet.

Then there's the financial and ethical challenges. Money is a double-edged sword. Can't live without it in this economic system. But if your project is funded by somebody else, they will want to call the tune, and they might not share your vision and values.

I'm thinking that communities who are developing cooperative economic systems will start to support software developers who are part of the community to develop apps for the community. Fair Coop is starting to do this, and the Mutual Aid Networks are trying.

Mapping out all the open source apps, possible apps which could form part of the Open App Ecosystem and the various 'layers' (of the stack) on which they sit seems like useful work, it also seems important to specify the technology they use...

The Digital Life Collective seem to have made the best effort in this general direction: https://kumu.io/DigitalLife/digital-life-collective#our-network with what they have built on https://kumu.io

For example, they even specify the Programming Languages, Software Licensing and level of the stack for each application they list e.g.
https://kumu.io/DigitalLife/digital-life-collective#our-network/metamaps

The "Cluster by" and "filter by" (bottom right) drop downs make this a little more useful too... although I don't think DLC use Linked Data, so this resource will only ever be as useful as how well it is updated.

I particularly like the way they own up to which tools they are using and how well they are "aligned" or "antithetical" they are https://kumu.io/DigitalLife/how-we-work#tools

It would seem to make sense for everyone involved / interested in the Open App Ecosystem to collaborate on keeping THE SAME LIST up to date... but I guess people would have to be members of DLC to contribute to their map ...? Maybe @shaunfensom can clarify?

Does anyone else think a listing / mapping project is a good plan?
And have thoughts on how it should be implemented?
This reminds me of @lynnfoster 's plan "Architectural mapping of software tools" https://www.loomio.org/d/C9Omyp6R/new-effort-architectural-mapping-of-software-tools

Ultimately I think something like https://stackshare.io/ but for open apps, and OAE apps would be most useful...

Oli

this is also a great list
https://wiki.p2pfoundation.net/Alternative_Internet_Projects

and the summary here is useful
https://wiki.p2pfoundation.net/Category:P2P_Infrastructure

As is this
https://redecentralize.github.io/alternative-internet/

but ultimately they would be more useful as a database of related objects, which would be easier to search and find related projects etc...

Does anyone else think a listing / mapping project is a good plan?

I guess we will need it at some point

Does anyone else think a listing / mapping project is a good plan?

This would be a good discussion topic in our video call, where we can have some more immediate back and forth. I'll add it if it is not on the agenda already.

Nice ressources guys !

I put everything here : https://www.communecter.org/#page.type.projects.id.596d0ef440bb4e83147b23e6.view.urls . We could centralize all the URLs we need here.