Melvin Conway famously said that organizations design systems that mirror their own communication structure. But how about Conway’s Law applied to the entire industry rather than a single company?

The tech industry, and open source (OSS) in particular, are mostly shaped now around the dominating communication structure — GitHub. Nadia Eghbal’s book “Working in Public” does a great job at explaining how OSS’s centralization around a big platform mirrors what happened everywhere on the internet, with us going from personal websites to social networks.

Another huge shift in organizational and communication structure, especially in Open Source, has been the increasing coalescence of maintainership: we historically talk about “a loosely-knit group of contributors” but most OSS nowadays is written by employees of big companies.

The commit stats in big projects like the Linux kernel indicate this, as do GitHub stats and the like. There’s a long tail of small independent contributors, of course, but by quantity major projects are dominated by those hired full-time to work on it.

One thing I haven’t seen discussed a lot is how much this reality changes the way projects are run and developed. Sometimes we see it coming up in particular cases, such as the relationship between Amazon and Rust, but this is a general phenomenon.

When Canonical came into the scene back in 2004-2005, I remember distinctly noticing their impact on OSS; it wasn’t just “more getting done” (yay?) but also what and how—various projects shifted direction around that time (GNOME comes to mind); it didn’t feel like a coincidence.

I don’t mean to imply it’s all bad, just that we don’t discuss enough about how the influence of Big Co development styles affect, in a “Conway’s-law-way”, the development of OSS, and even tech in general, since both open and closed development are so linked nowadays.

OSS has a big impact on how tech in general works (though the reliance of every company on OSS dependencies), and Big Cos have an impact on how OSS works (through their huge presence on the OSS developer community), so in this way they affect everybody. People bring in the experiences they know and how they’re used to working, from coding styles to architecture and deployment patterns to decision processes.

One great example where this is more evident is the “monorepo” discussion, which happens to projects of many sizes nowadays, and where Google and FB experiences are often brought up.

“help our codebase is too big” no, your company is too big. try sharding into microservice entities operating as a cluster in the same management substrate rather than staying as a monolith

— @myrrlyn on Twitter

The tweet above is such a great insight: we often see conversations about how to deal with huge codebases (using the likes of Google and FB as examples) AND we often see conversations about Big Tech monopolies — and how they’ve grown way beyond the status at which other monopolies were broken up in the past — but those two topics are hardly ever linked.

If we agree that some aspects of Big Tech as organizations are negative, how much of those do they bring into tech as technology practices via Conway’s Law? OSS seems to act as a filter that makes this relationship less evident, because contributions come from individuals, even though they work for these companies, and often replicate their practices, even if unknowingly.

These individuals will often, even if unknowingly, replicate practices from these companies. This is after all, a process of cultures spreading and influencing each other. It just seems to me that we as an industry are not aware enough of this phenomenon, and we probably should be more attuned to this.

Written in the early 2000s, “The West Divided” is a collection of interviews, newspaper articles and an essay by Habermas about post-9/11 international politics and the different approaches taken by the US through the Bush administration and the EU, through a philosophical lens.

The structure of the book helps the reader, by starting with transcripts from interviews and articles, which use a more direct language and establish some concepts explained by Habermas to the interviewers, and then proceeding with a more formal academic work in the form of the essay of the last part, which is a more difficult read. Habermas discusses the idealist and realist schools of international relations, aligning the idealist school with Kant’s project and the evolution of the EU, and opposing it to the realist school proposed by authors such as Carl Schmitt, a leading scholar from Nazi Germany. Habermas proposes a future of the Kantian project which lies in the ultimate development of cosmopolitan (i.e. worldwide) juridical institutions, such that cosmopolitan law gives rights directly to (all) people, rather than as a layer of inter-national law between states.

It was especially timely to read this book in the wake of the Russian invasion of Ukraine in February 2022, and to have this theoretical background at hand when watching John Mearsheimer’s talk from 2015 on “Why Ukraine is the West’s Fault”. Mearsheimer, an American professor in the University of Chicago and himself a noted realist, gives an excellent talk and makes a very important point that in international conflict one needs to understand how the other side thinks — instead of “idealist” vs. “realist” (which are clearly loaded terms) he used himself the terms “19th century people” to refer to himself, Putin, and the Chinese leadership, as opposed to “21st century people” to refer to the leaders in the EU and in Washington.

It is interesting to see Mearsheimer put the European and American governments in the same bucket, when Habermas’s book very much deals with the opposition of their views, down to the book’s very title. Habermas wrote “The West Divided” during the Bush administration, and the Mearsheimer talk was given during the Obama years, but he stated he saw no difference between Democrats and Republicans in this regard. Indeed, in what concerns international law, what we’ve seen from Obama wasn’t that different from what we saw before or afterwards — perhaps different in rhetoric, but not so much in actions, as he broke his promise of shutting down Guantanamo and continued the policy of foreign interventions.

As much as Mearsheimer’s analysis is useful to understand Putin, Habermas’s debate that there are different ways to see a future beyond endless Schmittian regional conflicts is still a valid one. And we get a feeling that all is not lost whenever we see that there are still leaders looking to build a future of cosmopolitan cooperation more in line with Kant’s ideals. Martin Kimani, the Kenyan envoy to the UN said this regarding the Russian invasion of Ukraine:

This situation echoes our history. Kenya and almost every African country was birthed by the ending of empire. Our borders were not of our own drawing. They were drawn in the distant colonial metropoles of London, Paris, and Lisbon, with no regard for the ancient nations that they cleaved apart.

Today, across the border of every single African country, live our countrymen with whom we share deep historical, cultural, and linguistic bonds. At independence, had we chosen to pursue states on the basis of ethnic, racial, or religious homogeneity, we would still be waging bloody wars these many decades later.

Instead, we agreed that we would settle for the borders that we inherited, but we would still pursue continental political, economic, and legal integration. Rather than form nations that looked ever backwards into history with a dangerous nostalgia, we chose to look forward to a greatness none of our many nations and peoples had ever known. We chose to follow the rules of the Organisation of African Unity and the United Nations charter, not because our borders satisfied us, but because we wanted something greater, forged in peace.

We believe that all states formed from empires that have collapsed or retreated have many peoples in them yearning for integration with peoples in neighboring states. This is normal and understandable. After all, who does not want to be joined to their brethren and to make common purpose with them? However, Kenya rejects such a yearning from being pursued by force. We must complete our recovery from the embers of dead empires in a way that does not plunge us back into new forms of domination and oppression.

Words to build a new future by.

Earlier today, statistician Kareem Carr posted this interesting tweet, about what people out there mean when they say “algorithm”, which I found to be a good summary:

When people say “algorithms”, they mean at least four different things:

1. the assumptions and description of the model

2. the process of fitting the model to the data

3. the software that implements fitting the model to the data

4. The output of running that software

Unsurprisingly, this elicited a lot of responses from computer scientists, raising the point that this is not what the word algorithm is supposed to mean (you know, a well-defined sequence of steps transforming inputs into outputs, the usual CS definition), including a response from Grady Booch, a key figure in the history of software engineering.

I could see where both of them were coming from. I responed that Carr’s original tweet not was about what programmers mean when we say “algorithms” but what the laypeople mean when they say it or read it in the media. And understanding this distinction is especially important because variations of “the algorithm did it!” is the new favorite excuse of policymakers in companies and governments alike.

Booch responded to me, clarifying that his point is that “even most laypeople don’t think any of those things”, which I agree with. People have a fuzzy definition of what an algorithm is, at best, and I think Carr’s list encompasses rather well the various things that are responsible for the effects that people credit on a vague notion of “algorithm” when people use that term.

Booch also added that “it’s appropriate to establish and socialize the correct meaning of words”, which simultaneously extends the discussion to a wider scope and also focuses it to the heart of the matter about the use of “algorithm” in our current society.

You see, it’s not about holding on to the original meaning of a word. I’m sure a few responses to Carr were of the pedantic variety, “that’s not what the dictionary says!” kind of thing. But that’s short-sighted, taking a prescriptivist rather than descriptivist view of language. Most of us who care about language are past that debate now, and those of us who adhere to the sociolinguistic view of language even celebrate the fact language shifts, adapts and evolves to suit the use of its speakers.

Shriram Krishnamurthi, CS professor at Brown, joined in on the conversation, observing that this shift in the language as a fait accompli:

I’ve been told by a public figure in France (who is herself a world-class computer scientist) — who is sometimes called upon by shows, government, etc. — that those people DO very much use the word this way. As an algorithms researcher it irks her, but that’s how it is.

Basically, we’ve lost control of the world “algorithm”. It has its narrow meaning but it also has a very broad meaning for which we might instead use “software”, “system”, “model”, etc.

Still, I agreed with Booch that this is still a fight worth fighting. But not to preserve our cherished technical meaning of the term, to the dismay of the pedants among our ranks, but because of the observation of the very circumstances that led to this linguistic shift.

The use of “algorithm” as a vague term to mean “computers deciding things” has a clear political intent: shifting blame. Social networks boosting hate speech? Sorry, the recommendation algorithm did it. Racist bias in criminal systems? Sorry, it was the algorithm.

When you think about it, from a linguistic point of view, it is as nonsensical as saying that “my hammer assembled the shelf in my living room”. No, I did, using the hammer. Yet, people are trained to use such constructs all the time: “the pedestrian was hit by a car”. Note the use of passive voice to shift the focus away from the active subject: “a car hit a pedestrian” has a different ring to it, and, while still giving agency to a lifeless object, is one step closer to making you realize that it was the driver who hit the pedestrian, using the car, just like it was I who built the shelf, using the hammer.

This of course leads to the “guns don’t kill people, people kill people” response. Yes, it does, and the exact same questions regarding guns also apply regarding “algorithms” — and here I use the term in the “broader” sense as put forward by Carr and observed by Krishnamurthi. Those “algorithms” — those models, systems, collections of data, programs manipulating this data — wield immense power in our society, even, like guns, resulting in violence, and like guns, deserving scrutiny. And when those in possession of those “algorithms” go under scrutiny, they really don’t like it. One only needs to look at the fallout resulting from the work by Bender, Gebru, McMillan-Major and Mitchell, about the dangers of extremely large language models in machine learning. Some people don’t like hearing the suggestion that maybe overpowered weapons are not a good idea.

By hiding all those issues behind the word “algorithm”, policymakers will always find a friendly computer scientist available to say that yes, an algorithm is a neutral thing, after all, it’s just a sequence of instructions, and they will no doubt profit from this confusion of meanings. And I must clarify that by policymakers I mean those both in public and private sphere, since policies put forward by the private tech giants on their platforms, where we spend so much of our lives, are as effecting on our society as public policies nowadays.

So what do we do? I don’t think it is productive to start well-actually-ing anyone who uses “algorithm” in the broader sense, with a pedantic “Let me interject for a moment — what you mean by algorithm is in reality a…”. But it is productive to spot when this broad term is being used to hide something else. “The algorithm is biased” — What do you mean, the outputs are biased? Why, is the input data biased? The people manipulating that data created a biased process? Who are they? Why did they choose this process and not another? These are better interjections to make.

These broad systems described by Carr above ultimately run on code. There are algorithms inside them, processing those inputs, generating those outputs. The use of “algorithm” to describe the whole may have started as a harmless metonymy (like when saying “White House” to refer to the entire US government), but it has since been proven very useful as a deflection tactic. By using a word that people don’t understand, the message is “computers doing something you don’t understand and shouldn’t worry about”, using “algorithm” handwavily to drift people’s minds away from the policy issues around computation, the same way “cloud” is used with data: “your data? don’t worry, it’s in the cloud”.

Carr is right, these are all things encompassing things that people refer to as “algorithms” nowadays. Krishnamurthi is right, this broad meaning is a reality in modern language. And Booch is right when he says that “words matter; facts matter”.

Holding words to their stricter meanings merely due to our love for the language-as-we-were-taught is a fool’s errand; language changes whether we want it or not. But our duty as technologists is to identify the interplay of the language, our field, and society, how and why they are being used (both the language and our field!). We need to clarify to people what the pieces at play really are when they say “algorithm”. We need to constantly emphasize to the public that there’s no magic behind the curtain, and, most importantly, that all policies are due to human choices.

This starts with the Beatles, but it’s not about them. It’s about us.

So, a friend tweeted earlier today the question “what is the final Beatles song“, and as usual, these topics lead to fun conversations. You see, the “end” of the Beatles is a fuzzy matter, because they recorded their last two albums in 1969 and 1970, but released them in reverse order — Abbey Road was recorded last and released first, and Let it Be was the other way around. And then, do the Anthology sessions from 1994 with Paul, George and Ringo playing over an old recording of John count? (I feel they do!)

As the conversation went on, she shared with me this little story (on everything2! they’re still around!!), which only drives its point home really deep if you’re a hardcore Beatles fan, but one element in it is that it imagines a Beatles album made from songs that the individual members released immediately post-breakup. That on itself is not very remarkable: building those imaginary what-if-they-stayed-together album setlists is a favorite pastime for Beatles fans. Invariably, the semi-obvious conclusion is that if you took the best tracks from each of the four solo albums from a given year, you’d make an album that’s better than the individual works. And as you can imagine, those playlists are widely available. Still, those always sound like compilations to my ears (and, without giving away too much, the story linked above addresses that beautifully).

To me, the fact that such fan-fictional albums sound like compilations and not like true albums has to do with the reason why I think collective works — be it in music or not — tend to be better in general than solo efforts. Because work done in a collective yields results of a different nature.

“People change like colors bleed,
As I sense a shade of you in me”
— “Color Bleed pt. 2”, from the album Color Bleed (2011)

Work done by two or more people always reflects that multitude, it’s always unlike any single person’s work. When I’m in a collective environment — and by that I mean any setting where my work is presented to and discussed by others as it is developed — even when I’m doing work completely on my own, even before I’ve had my first piece of feedback, I feel a sort of mind game playing in my head where I “play the part” of my peers and imagine what their feedback would be, be it consciously or subconsciously. I’m doing the work not only for myself, but for others too, whose opinions I care about. That affects in subtle and not-so-subtle ways the results of what I do. Even the work I do alone, when in such environment, is different and better than the work I do alone-alone.

When I recorded Color Bleed, I invited my friends who had played in a Pink Floyd cover band with me to join in. Even though I wrote all the songs — some written years prior, some written as the project took shape — all of them ended up influenced by the fact that I was playing the songs with them, and even though I tried to venture away from the cover stuff we were doing, there are clearly some floydian moments here and there, which maybe don’t sound so much like Pink Floyd to my ears, but certainly alluded to our favorite moments on stage together (and let me tell you, playing keyboards along with another keyboardist is really cool!) — by the point we were recording the original songs, the point was never to sound like the cover band, but for it to sound like us. So even if that wasn’t truly a “band effort” in the idealized sense that we imagine “four people in a garage”, it was never a lonely project: from the very beginning it was me and Coutinho, who was the other keyboard player in our band, who also owned the studio and took the role of producer/engineer, and then the other folks joined in contributing parts as we went. The end result was much better than anything I could achieve on my own, and most importantly, even the things that I did were better than if I had done them on my own.

That feeling of being “in a band” is not exclusive to music. I definitely felt it as a software developer as well. At my last job, I made the interesting observation that it was the third time in my career that I was part of a team called “Core Team”. The first one was back in college, and it was the most special one — maybe because it was the first, maybe because it was the experience that shaped the rest of my career: the Core Team for GoboLinux, my first successful open source project.

Looking back, it’s funny how it started very much like Color Bleed. Back in 2002, I was at the university and I had this idea for a crazy Linux distribution which would require recompiling the entire system from scratch. A friend joined in and we did it together over the course of a weekend. One by one, more friends joined in, switched over their systems, created bootable CDs, made kernel patches adding cool features, we were just having lots of fun tinkering with the OS. Then we were slashdotted (think “HN frontpage x10”), then we were on a magazine cover, photo shoots and all, then we were invited for internships in Silicon Valley, all the way from Brazil. I never took music seriously, but at least in tech I had the “indie band having its one-hit-wonder moment” experience. And yes, it was as cool as it sounds.

Cover story! And a cool band pic!


There we are, next to KDE and Gentoo! We’re “for real”!

The second Core Team was at a local startup, where I worked with Guilherme, who was also in GoboLinux. Since we already had the chemistry from that project, this really felt more like a side project than a new band — think Petrucci and Portnoy doing LTE away from Dream Theater (yes, I just blatantly made that comparison haha).

In between the first and second Core Teams I got my Masters degree, and between the second and third, I got my PhD. I loved it at PUC-Rio (or else I wouldn’t have gone there twice!), and made great friends each time, but it never felt like a band. In both occasions we had a research group, but each person was running their own project, with little or no overlap. Opportunities for collaboration were limited, everyone was on a different schedule, and while we created a great environment which I’ve called home for many years, it just wasn’t “a band”.

The third Core Team was at my last gig, at Kong. Again, that felt like a band — a scattered group of hackers from all over the world — China, Finland, Spain, Brazil, Peru, Canada, US — brought together because of their Lua knowledge to maintain this open source project. Each one with very different skills and backgrounds, and it was complimentary: it felt like each one of us played a different instrument. And doing creative work as part of that group felt like doing it in a band context: even when I did stuff on my own, I had it in my mind that it is was being done for that particular team to review and maintain (even if each of us would still put our personal flavor to the code). I had a great 3½ years with that team, where I learned a lot and played different instruments—I mean, roles, and then I put in practice something that I learned from the many bands I played since I was a teenager: leave on a high note. Looking back, the only regret I have is that… apparently we never took a picture of our team? (To be honest, I’m not sure we’ve ever got my last lineup of the team together in the same room — it was supposed to have happened in 2020, but then the pandemic hit. Maybe a pic of some previous lineup at least?)

Not all of my coding projects were “bands”. Even though I had tons of pull requests with contributions over the years, the process of developing htop was always a solo endeavor. I liked it this way, for a good while it was my chill-on-my-own thing away from everything and everyone. But then I drifted away from it, and free/open source projects (FOSS) projects need maintenance. From a distance, I feel like that the new team who picked it up works like a band. I’m happy for them!

Maybe it’s better if FOSS projects work more like bands than solo projects — bands often outlast their members, after all. But then sometimes you just want to pick up an acoustic guitar and do stuff on your own. There’s got to be a place for that too. Now that I think of it, I’ve never been part of a really huge FOSS project — I have a tendency of starting projects rather than joining established ones! — and I don’t know if this “band mentality” of mine has prevented any of my projects from growing (whenever I read about the structure of the Rust project, even before the Foundation, it seemed super sprawling!) but I know that a team can only feel like a team when it is about the size of a band, and I know that a team feels best when it feels like a band.

Not all teams feel like a band, and to be honest, not even all bands. But when it happens, it’s somewhat magical. It’s something that build memories that you take with you forever, and which change you in some way or another. Whenever I listen to the solo works from my favorite artists who left my favorite bands, I can always tell that the influence of their old bandmates is always obviously there, whether they want it or not, whether they’re Paul McCartney or John Lennon, David Gilmour or Roger Waters. I’m sure the influences from all the great people from my past history are there whenever I play, and whenever I code.

André Garzia made a nice blog post called “Lua, a misunderstood language” recently, and unfortunately (but perhaps unsurprisingly) a bulk of HN comments on it was about the age-old 0-based vs. 1-based indexing debate. You see, Lua uses 1-based indexing, and lots of programmers claimed this is unnatural because “every other language out there” uses 0-based indexing.

I’ll brush aside quickly the fact that this is not true — 1-based indexing has a long history, all the way from Fortran, COBOL, Pascal, Ada, Smalltalk, etc. — and I’ll grant that the vast majority of popular languages in the industry nowadays are 0-based. So, let’s avoid the popularity contest and address the claim that 0-based indexing is “inherently better”, or worse, “more natural”.

It really shows how conditioned an entire community can be when they find the statement “given a list x, the first item in x is x[1], the second item in x is x[2]” to be unnatural. :) And in fact this is a somewhat scary thought about groupthink outside of programming even!

I guess I shouldn’t be surprised by groupthink coming from HN, but it was also alarming how a bunch of the HN comments gave nearly identical responses, all linking to the same writing by Dijkstra defending 0-based indexing as inherently better, as an implicit Appeal to Authority. (Well, I did read Dijkstra’s note years ago and wasn’t particularly convinced by it — not the first time I disagree with Dijkstra, by the way — but if we’re giving it extra weight for coming from one of our field’s legends, then the list of 1-based languages above gives me a much longer list of legends who disagree — not to mention standard mathematical notation which is rooted on a much greater history.)

I think that a better thought, instead of trying to defend 1-based indexing, is to try to answer the question “why is 0-based indexing even a thing in programming languages?” — of course, nowadays the number one reason is tradition and familiarity given other popular languages, and I think even proponents of 0-based indexing would agree, in spite of the fact that most of them wouldn’t even notice that they don’t call it a number zero reason. But if the main reason for something is tradition, then it’s important to know how did the tradition start. It wasn’t with Dijkstra.

C is pointed as the popularizer of this style. C’s well-known history points to BCPL by Martin Richards as its predecessor, a language designed to be simple to write a compiler for. One of the simplifications carried over to C: array indexing and pointer offsets were mashed together.

It’s telling how, whenever people go into non-Appeal-to-Authority arguments to defend 0-based indexes (including Dijkstra himself), people start talking about offsets. That’s because offsets are naturally 0-based, being a relative measurement: here + 0 = here; here + 1 meter = 1 meter away from here, and so on. Just like numeric indexes are identifiers for elements of an ordered object, and thus use the 1-based ordinal numbers: the first card in the deck, the second in the deck, etc.

BCPL, back in 1967, made a shortcut and made it so that p[i] (an index) was equal to p + i an offset. C inherited that. And nowadays, all arguments that say that indexes should be 0-based are actually arguments that offsets are 0-based, indexes are offsets, therefore indexes should be 0-based. That’s a circular argument. Even Dijkstra’s argument also starts with the calculation of differences, i.e., doing “pointer arithmetic” (offsets), not indexing.

Nowadays, people just repeat these arguments over and over, because “C won”, and now that tiny compiler-writing shortcut from the 1960s appears in Java, C#, Python, Perl, PHP, JavaScript and so on, even though none of these languages even have pointer arithmetic.

What’s funny to think about is that if instead C had not done that and used 1-based indexing, people today would certainly be claiming how C is superior for providing both 1-based indexing with p[i] and 0-based pointer offsets with p + i. I can easily visualize how people would argue that was the best design because there are always scenarios where one leads to more natural expressions than the other (similar to having both x++ and ++x), and how newcomers getting them mixed up were clearly not suited for the subtleties of low-level programming in C, and should be instead using simpler languages with garbage collection and without 0-based pointer arithmetic.