I’ve always found the early Internet era to be particularly alluring. Something about the culture of it seems so wonderful. Usenet forums, dial-up, IRC channels, groups of engineers who, by and large, did this for fun. As Raymond himself writes, the “users are hackers too.”

That’s one of the largest grievances I have with the modern internet - it feels like everyone is on it. It’s become a commodity, but as a result, there’s no community for the nerds who build it anymore. At least not outside of the Slack channels of massive tech conglomerates. As someone who’s always identified with the types of opinionated, awkward, and tech-obsessed people who built these platforms, writing like this essay makes me nostalgic for a community I never got to experience. The idea of building alongside Richard Stallman and Linus Torvalds is incredible.

With that being said, my largest takeaway from this reading was that community is the most important part of an open-source project. Large tools meant to serve developers shouldn’t be built by one developer sitting in his room by himself, it should be built by a community and modified by each developer for their needs. And the community of an open-source product isn’t just the developers. It’s the users as well. Users (who, as Raymond points out, are often easily converted to developers, especially in technical use-cases) are the most valuable target for a developer to have. The people you’re building for are the people to listen to.

I can see this with the project I’m working on, Nanobot. Nanobot is exactly the type of project Raymond is discussing here. The users are almost exclusively engineers and tech-fanatics. It’s a community of nerds, always hoping to make changes - including my team.

Unfortunately, this community is very fast-moving and not all that coordinated. Earlier this week, I selected an issue to work on. Unfortunately, by the time I had understood the problem, a fix had been opened. The reality of the community is that, while it’s great for the project, for an individual hoping to contribute, contributions moving too fast means I have very little strike time.

So, I’m going to try a different approach. I’m going to contribute the features and fixes I’ve personally identified, so I can fix those and make the product better for myself. As Raymond writes, users can easily be converted to developers. And I’d extend that to the following: developers should be users themselves.

PS: It was funny to find the origin of the “Given enough eyeballs, all bugs are shallow” quote. And just as fun to try telnetting into the ccil.org page.

I think our project compares really interestingly to the selection from the class - I’m in particular super excited to see what the P5 team does in terms of navigating the large organisational codebase. In comparison, our project is super small, and it’s managed by the Hong Kong University Data Science program, so it’s mostly collaborative with other students from schools around the world.

This week, we’ve made some great progress. Everyone has nanobots running locally now, and I’m even thinking of getting my own Raspberry Pi setup to run it constantly. We’ve also built a live issue feed, and I think we’re going to also just set up an automatic system to tag issues so we don’t have to do it manually. Most of the issues seem to be small and fixed relatively quickly, and even though we’ve scraped all the issues and tagged them, we regularly see issues we’re thinking of working on solved relatively quickly. It’s worth keeping this in mind as we go forward, because we’ll need to either do more challenging issues (not really a problem) or react fast to new issues (which is quite doable).

The emphasis on code quality is huge, we’ve noticed, so this should train us to write clean code by the standards of other skilled engineers, as well.

However, I do think it’s going to be a bit difficult identifying exactly what we want to build because Nanobot gets a lot of concurrent contributions because this is a really fast-moving space. I’m a bit worried that by the time we pick something, someone else will start working on that. However, I feel like there’s a lot of work that can be done, so I’m really not too worried that we’ll be stuck. I think there’s a lot of great stuff we can do here, especially in terms of adding new functionality, and minor bug fixes are always, of course, rampant for us to clean up.

Another minor thing I’m aware of, however, is the fact that even though this is a fast-moving project, they care a lot about code quality. We want all of our code to be as high-quality and as compact as possible, because they seem to really care about having readable, concise, and maintainable code. That’s something that I think is especially applicable for this project versus other projects.

So far, we haven’t really built any actual code. We’ve done a lot of setup for our environments. All of us have set up our OpenClaw tokens, and we’ve all set up local Docker deployments, so it seems like we’re making pretty good progress on getting to work on our development pipelines. However, actually making contributions is going to take a couple of days, probably, because we need to identify exactly what our targets are.

We haven’t had any conflict yet either. It seems that everyone’s pretty aligned in what we’re trying to do. The one thing I’m worried about is that, in the longer term, there might be a bit of competition over who gets to do what. I think that can happen when the project is so new and so interesting. However, as long as all of us remain humble, I think that shouldn’t really be a problem. I know that I personally would be fine with doing something less glamorous as long as it means that I get to contribute to something so important here. Also, typically higher impact projects require more difficult code, so it really comes down to who is willing to sacrifice more time for that.

This project choice overall aligns quite well with my taking stock exercise because I really did express a lot of interest in deep tech and AI, and I think this is a pretty good synthesis of that.

I think I’m particularly interested in developing skills in low-level programming, so I’d love to do something that uses either Rust or Go, or some other low-level systems language. I want to do some really hard tech stuff, and I’m thinking along the lines of either financial high-frequency trading or deep AI work. However, all of these are difficult to work with teams, considering that it requires a relatively high level investment from everyone.

Overall, I think I’d love to contribute to the Google Quantum Project; that one’s really cool. I’m also seeing a lot of really cool stuff in the AI space, especially with OpenClaw. Though my understanding is that their codebase is a horrible mess to navigate, I think something like Nanoclaw instead would be really cool as well.

In the Browser Extension Project, I was in charge of building out a system that would identify the score portions, calculate running tallies and keep track of this data in browser memory. That was pretty cool to work on. It wasn’t difficult actually, and it was just kind of something that nobody else really wanted to handle that I found kind of fun.

Issue with the smaller contributions I’ve made is that they don’t feel very fulfilling. It’s mostly been like reporting an issue here, fixing a documentation issue there, adding some stuff to Wikipedia or fixing mistakes… I feel like I’m not really building any skills in the process, and yeah, I’m making valuable contributions, but I think I really measure my success by what I’m developing in the process personally as well as to the community. I feel like these small contributions don’t really give me as much of the personal skill growth. By going into the open source contribution section of this course, I really want to contribute to a difficult piece of work that will help me build actual hard engineering skills.

I’m super happy with the project, and progress, my group has made too. Our project is genuinely super useful to me - I can see so much value in being able to predict my final grades accurately. I want to add a few more features though, especially one to change the weights.

One thing I’ve noticed is super valuable in the presentations I’ve watched is confidence in your expertise. Having confidence makes it easier to be present in the presentation, and even treat it as more of a conversation - and that’s what made so many of these presentations engaging. Especially in Linus’s presentation, having seen his actual talks, I know he’s a fairly awkward speaker but in conversation he does great. Being able to adapt that mentality to any talk is valuable.

This lesson, however, exposed the gap in my understanding pretty well. While I might know how to use git, how it works is another question. In particular, I’d never understood what the git hash meant. The fact that files are hashed by content and therefore have the same hashes with different content, was, for example, completely new to me.

Overall, this lesson definitely tightened up quite a bit of my git knowledge, and will definitely help in debugging annoying git issues going forward.

Project Evaluations

I wasn’t there for project evaluations in-person this week, as I wasn’t feeling very well. But I did the project evaluations on my own afterward, reviewred others’ contributions, had some interesting thoughts on their insights.

One interesting thing I noticed was the correlation between large organisations and very clear contribution paths. React, for example, has a huge contribution pipeline with tons of templates and resources, but commits take forever to get approved. Leaner teams have less infrastructure but accept commits faster - provided, of course - that the maintainer is open to those contributions. One thing I found funny was in the description of Kitty’s contributions culture: the student who wrote that one described it as “friendly.” However, I’ve tried contributing to Kitty in the past (in particular merging some image support compositor stuff from a branch into mainline) and the creator, Kovid Goyal, was anything but friendly. I think my takeaway from that though was less that small teams are unfriendly but that small teams are much more dependent on the temperaments of a few key individuals.

Our idea is fairly approachable. We plan to make a Gradescope score calculator, to make determining our final grades easier. It seems to be very approachable, but I do wish we’d taken on something a bit moore challenging. One idea I had was a suite of tools to make Gmail on Web better-designed. I have some qualms about the UI and I’d have loved to fix those. In any case, we have some fun design decisions and Easter eggs ahead, so I’m very excited to keep working.

Open Source Contributions

This week, my main open-source contributions have been cleaning up misinformation on Wikipedia. I made a number of changes on the pages of musicians I follow (though for a good 50% of them I forgot to log in…) I also made a number of changes for photographers as well. I recently received a new Daido Moriyama print, and I noticed a few mistakes on his Wikipedia page, so I had to fix those.

And one of the most important factors in facilitating cooperative environments for open-source projects is ensuring that people feel safe to contribute. The way many projects have chosen to do that is with Codes of Conduct. Codes of Conduct define what behaviour is acceptable or tolerated within a project’s community. And they’re instrumental in ensuring contributors feel safe to push new ideas and new changes.

Go’s Code of Conduct

We, in particular, looked at Go’s code of conduct. It’s a good example of how a project can actively shape its community. It lays out the values the community expects: be patient, respectful, thoughtful, and responsible. Healthy disagreement is fine, but harassment, insults, or other disrespectful behavior aren’t tolerated. It also establishes the leadership structure, making it clear who handles issues. Project stewards and committees are given these responisibilities, so enforcement isn’t vague. The code of conduct is designed to keep the environment welcoming and safe, making it easier for contributors to engage and collaborate without worrying about drama.

However, the Go conduct code outlines the “Gopher Community” values, which apply both inside the project and when representing Go elsewhere, recognizing that your behavior outside can still affect the community, which is something that might be overlooked by contributors if not stated explicitly here. This is a valuable addition, as it realises that the community image expands beyond just the product itself, especially in a user-facing product like Go, which depends heavily on being trusted and favoured by the developer community.

Eclipse

In contrast, Eclipse is much more formal and legalistic. It’s designed for a large foundation with corporate members, so it reads like policy and governance rules. It defines more committees, directors, board positions, oversight, staff roles and responisibilities - all things you’d see in a corporation’s bylaws. In effect, this is like bylaws. However, instead of applying only to employees, it applies to all members and contributors, in accordance with open-source philosophy.

Sugar Labs

The Sugar Labs Code of Conduct considerably different in its approach. It’s based on the Ubuntu Code of Conduct and, in accordance, focuses more on collaboration and learning than strict enforcement. It emphasizes being considerate, respectful, and flexible, and encourages contributors to ask for help and resolve disagreements constructively. It’s not built around what not to do, but rather what to do.

As such, instead of listing “bad behaviors” in detail, it frames everything around how to work together effectively. It does still have committees and procedues (in particular, an Oversight Board and ombudsman to handle disputes) but the format of these roles shows the project values guidance and mediation over punishment.

OpenRC

OpenRC’s code of conduct, however, is interestingly chosen. It’s adapted from the Contributor Covenant v2.1, which is unusual given the type of project it is. For a project built by a small community of passionate contributors aiming to replace something they felt was “too corporate” and “scope-crept,” you would expect a minimal code of conduct outlining ideal behaviours, rather than a list of things to avoid. However, the OpenRC code of conduct, too, seems to focus extensively on preventing “bad behaviours,” outlining strict penalties, systems and councils to enforce penalties and ensure community order and structure, and leadership systems. It emphasizes what types of behaviours OpenRC contributors should not engage in, and outlines penalties and consequences for violations.

Though maybe it makes sense for a project built so heavily around what it’s not (systemd) to have a Code of Conduct that reflects that mentality.

My history with free software (you’re welcome, rms) goes back to elementary school when I first installed Linux Mint on my old Thinkpad. It was a desperate attempt to keep an aging computer alive. Mint survived all of two weeks before I was onto Ubuntu, then Kali (as all tech-obsessed 11-year-olds do), then ElementaryOS, then Manjaro. By tenth grade, I was hopping between Discord servers, arguing over init system elitism and building custom desktop environments with unholy mixes of compositors and window managers held together with duck tape, staples, and a ton of scripts. I was living, and loving, the free software community.

I slowly became disillusioned with much of the space when I realised one huge issue - free software developers kept getting screwed. It was not at all unusual to hear about someone I knew contributing to some huge project, only for that project to be used by Amazon in their latest surveillance tool. It was disheartening, and depressing. When I realised I was doing Google’s job for them, building out Flutter tools, I started switching my code over from MIT to AGPL, prompting arguments with my friends.

To me, open source reminds me of the unsung heroes keeping our engineering world alive. It’s the guy who wrote left-pad, keeping the entire rest of npm alive. But as I’ve gotten older, I’ve realised just how much more symbiotic that relationship really is. After all, Google, Apple, Microsoft - these are all some of the most important contributors to the open source world.

Projects

I use open source projects every single day, and not in some abstract, indirect way. My daily browser is Librewolf - a free software fork of Firefox with an extreme emphasis on privacy. I might be a macOS user now, but my window manager is Amethyst, an open source gem for people trying to replicate their Linux glory days on a far more restricted OS. I’m running open source streaming servers, writing code with open source languages (special thanks to the Python, Rust, and Julia development teams for keeping my entire engineering career afloat), and watching videos with VLC, which, thanks to the VideoLAN team, is still free and open source despite the millions of dollars they’ve been offered.

I wouldn’t be here as an engineer without the world of open-source development. And neither would any other engineer.