Types of collaboration: 1. Publish your code. Other people (who you may not know) can discover your code, reuse it, remix it. Centralized version: github public repository. Decentralized version: IPFS, plus a discovery mechanism. 2. Share your code with members of your team (but don't share it outside your team). Centralized: github private repository. Less centralized: Run your own git server, with authentication and a user account for each team member. Decentralized: Each team member has their own git repository, shares patches with other team members. 3. Real time collaboration. Several people editing the same code base at the same time. Centralized: The true version of the code exists on a central server. Decentralized: Each person has their own copy of the code, and a peer to peer protocol keeps them in sync. 4. Collaborative live coding. Several people editing the same code base while the program is running. Or, in a video/music performance, outputs of one live coding session are taken as inputs to another live coding session, in real time.

I've been thinking about this as well. Collaboration isn't a simple thing, there's multiple axes to it. You've identified two so far: level of synchronicity and level of centralization. I wonder if there are others. Somewhere out there is a paper with a comprehensive list. @Bosmon, any ideas?

(@Kartik Agaram well, I guess I am also biased by my philosophical view: we lack emphasize on collective. And as for our subject here, I see value to bring more collaborative behaviour in programming activity. And maybe I must clarify this once like you then shut up too... 😉 anyway: thanks)

Are you an extrovert, @ogadaki? 😄 That may explain it.

Well, not at all, I guess I am more on the introvert side. But it is complicated... 😉 Let's say that I like to work alone but I also like creating stuff with others when the collaborative organisation works. The results are different and the collaborative ones are interesting. And I like a lot seeing how others are thinking about the creations/problems we work on.

git is a collaborative tool

Content warning: Unpopular opinion. 😉 Isn't git a tool that allows multiple developers to not have to collaborate with other developers directly, by carving out a part of a codebase where they can make changes with lower probability of affecting others? Instead of coordinating with others, we find it more efficient to separate us from them and let a merge algorithm do the cooperation for us. And when conflicts emerge, it's a problem, an exception we have to deal with, and we focus — consciously or subconsciously — on the negative connotations. Maybe our industry has a bias against collaboration? How many people here reading this are (a) working on their own project, and (b) how many of you here are working together on the same project? Or what's the first thing you think when you look at code from a different person? Is it more like "Oh wow, that's interesting — I wonder why they did it like that!" or more like "What a mess. I would do this differently." I had an interesting conversation with a film director last week and he was comparing our industry with his. He noticed how collaboration "isn't much of a thing for most developers". He is working on some software that's being developed for him, which is why he has lots of interaction with developers lately. He observed: when asked for help, they tend to give quick feedback and opinions, often without showing any empathy for the person seeking help by asking clarifying questions for the situation they're in. Compared to a film set, every person on that set needs to know what the movie is about and what everyone else is doing and it doesn't matter if you're the director, the sound person, in catering, or whatever — you'll frequently collaborate with other people outside your domain because everything is tightly connected to everything else. In software development, we're trying to untangle everything and ideally only have loose coupling everywhere — maybe the most important benefit of that has nothing to do with architecture, but with our desire to focus and work alone? Can't wait to see what such people come up with in terms of collaborative tools then… 😎 I know that's a dark perspective on our industry and collaboration, and I've been deliberately pushing it a little further than I really mean it to make a point.

Film-making is a short-term activity. Everyone comes together for an intense burst of effort, then disbands to unwind. Software (particularly the sort of tool-creation endeavor we discuss here) is a long-term activity. I think that explains why our industry rightly holds loose coupling in such high regard. (In principle. To me the high coupling of teams in the software industry (open-plan offices, historical reluctance to let people work remote, etc.) is a symptom of regrettable short-termism in outlook in practice. To be fair there's a lot of reason for short-termism in a startup. Which is why I'm suspicious of money, but I won't rehash that conversation.)

what's the first thing you think when you look at code from a different person? Is it more like "Oh wow, that's interesting — I wonder why they did it like that!" or more like "What a mess. I would do this differently."

Based on my browser history, here are some links to projects I spent time reading code for in the past few days: • https://idea.junglecoder.com/view/idea/274 • http://minimal.linux-bg.org (I spent 2 weeks understanding this to distill it down to https://github.com/akkartik/mu/blob/master/gen_iso) • https://nurpax.github.io/posts/2019-08-18-dirty-tricks-6502-programmers-use.html • https://people.kernel.org/mcgrof/kdevops-a-devops-framework-for-linux-kernel-development I still think your question is valid. I'm fairly unconventional in my interest in reading code, and I think the world would be a better place if more people were like me 👼 My project basically got started by frustrations in reading other people's code. Every codebase is like its own language, and it's too hard to copy/steal code from others. It doesn't help that people worry about IP law. I had someone tell me recently that they don't want to look at code without a license because of contagion worries for copyright. That's either insane or reinforces my determination to learn as little about IP law as possible. Anyways, I'll stop rambling here 🙂 Thanks for a great comment @Stefan.

@Stefan On git as an anti-collaborative tool. Here is a paper that makes this same point, when constrasting the design of git vs fossil. See section 2.5: https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki

I think both Cathedral and Bazaar are way more loosely coupled than making a film.

@Kartik Agaram I've worked in several software development environments where all the developers were on site in the same small team in the same office (no remoting), and where we had a "one true source" philosophy for the SCM system (no branches), and where accumulating changes for days or weeks at a time before checking in changes was discouraged. This required discipline and frequent communication between team members. Everybody had to know what everyone else was working on. At one place, we even had a scoreboard showing how long each team member had gone before checking in changes, to create peer pressure. I think this counts as a "cathedral" style. I think this style of work is far less common today, due to the effect of things like git and remote development on the culture. Today, I'm sure a lot of people can't comprehend how you'd develop a significant sized system without using branches. Just want to make it clear that this style of development has been practiced, and maybe still is in some places.

No disagreement. I'm not sure if you were trying to oppose my previous comment, but I'm not seeing any merge conflicts here 🙂 I've actually never used long-lived branches in any of my jobs. I assume y'all had some process for review before merging new code into the one true source?

@Kartik Agaram On your comment that "Cathedral is way more loosely coupled than making a film." Okay, it can be, but surely it must be possible for software development collaboration to be as tightly coupled as making a film? And maybe some developers are using tightly coupled collaboration and getting benefit from it? I think that is worth exploring, if we are making a taxonomy of collaboration styles. What about pair programming?

i find that the most difficult collaboration is also inescapable: collaborating with my past and future selves. i can’t even ask them a clarifying question!

Yep the only real collaborative way of coding I can imagine is pair programming. This is simply because it require lot of bandwidth between people to actually working with same problem together. Such bandwidth isn't available directly by (collaboratibe) code editor. Which is also behind that past and future me problem. So here we go again: How to bring actual thought process and code closer together?