Well said. You are correctly noticing that I am criticizing the original vision of the empowered individual in favor of the empowered community, because it's a much more important, alebit harder, problem. If we need to liberate users first as a stepping stone, I'm all for it. But I don't want us to lose sight of the fact that empowered communities is what we're aiming at

I weakly believe that if we had truly empowered individuals, communities would just work right by default. There may not be any more work to do!

I take the opposite view to @Kartik Agaram — communities make or break a programming language. I might even tentatively propose that historically, language design has been secondary to social/cultural/community factors when it comes to success or failure (otherwise how could something like c++ or JS be so popular 😉?) Though I think for end-users (and groups thereof) design matters a lot more than for developer-targeted languages, since clarity is paramount.

To be clear, I'm only talking about the technical affordances for collaborating over software. We definitely need lots more for a healthy community, social norms and so on.

Ah. I'd still say that matters a lot too, though— affordances can encourage/discourage trends in the community (including the tendency to share code or collaborate at all) by what it makes easy and what it makes difficult. Where to place or remove friction has a huge impact on how a community develops, especially given the nonlinearity of human interaction.

In my world of true EUP, the decision of where to place or remove fiction is open to everyone and perennially up for discussion. So we don't have to decide for everyone, and we don't have to get it right ahead of time. Just set the stage with the right individual capabilities and let them surprise you with where they take the world.

@tbabb I'll side with Tim. It's like designing protocols: it's easier to go from a network friendly protocol to a local version with a network size of one than to go from software that works locally to software that works for a network. Likewise, an end-user tool that is good for an individual is unlikely to scale to teams. In all examples I know (CAD, media processing, even Excel and Word) collaboration is hard because it is, at least conceptually, added as an afterthought.

I'll be very happy if someone can create a durable, scalable environment for collaboration. But this conversation has hardened my conviction that chasing collaboration lies in the same direction as "let's first make sure everyone has food to eat" or "let's first make sure everyone gets a decent math education". A noble goal, but less actionable and dissipative to focus. Ok, I'll bow out on that cheery note 🙂

Well, I'll get back to you on that once the community & collaboration tools for our valos system are ready. 😛 But yes, I would agree it is a quite telling that those are things to be considered in the future, while enabling single user (/team) is first on the list of things to do.

I'd love to read more about your plans!

I'm personally thinking the key might be to allow natural and non-aggressive ways of enabling the collaborators to bootstrap the collaboration, instead of the person who needs to be collaborated with.

Sounds like you're thinking about an asymmetric model of collaboration where one side has something and the other wants to access it. Interesting, I wasn't even thinking of that as 'collaboration'! Very curious to see how you crack that particular problem.

I guess the key things about the plan are that the infra makes it possible to just point to any part (resource-tree) of any other thing made by the infra (provided access is allowed), and use it in the code interchangeably from if it was within your code. (The client reading the infra will on the background automatically connect to and/or cache the remote content.) This is then coupled with the attempt at reducing any app complexity and supporting a structure for a layered approach to app creation that would naturally consist of interoperable parts within the app itself. This is then extended by the (infra-level support for) not just using remote code, but adapting it while maintaining the link. So in the short-term vision this leads to me (as a overly simplified example) creating an app that rolls a d6 die with having a Dice element, and then you creating an app that directly uses my Dice element but I adjust the value "6" to "10", yet maintaining the link. So then when a third party looks at your code, it'll lead to mine as well, and perhaps they take it and make the number a parameter that can be provided... But this leads to obvious issues about versioning and structural changes and authorship, and there's no inherent backward loop for improving my code (for easing further collaboration), etc. etc. etc. No silver bullet, this is a tough problem, but I have hopes something will develop out of this. The grander vision would be to have an IDE/software crafting environment which is built to support this sort of interaction, visualizes/conceptualizes the connections between apps and makes them more social, and has some capabilities the bridge gaps between commercial and open source software.

I'm just hoping that building in P2P networking from the start in the core of, and deep in the architectural principles of, the system will enable social networking (+empowerment, etc) above/around it.