Contributor performance considerations

It was around 2005 when I sat at my job and didn’t like it. I was head of web development at an agency in London that covered huge web sites and government portals. The pay was great, my team was top-notch and the products interesting. What I didn’t like was that my computer was a mess. I dealt with various products each with their own stack. Early .NET (with state stored in a hidden form field) here, Java Spring there, PHP on another. Flash generated from Apache Turbine from XML to use XSLT to build the HTML fallback. Everything was complex. I had no idea what all these files on my machine were and the hard drive was always 95% full causing blue screens.

There and then I opted to even more moving from random things on the backend to a standardised front-end. It makes sense to know what you use and to leave a lot of the weird things to the browser. It is an exciting task to cover the basic use case and enhance with more capable environments to run your code in.

Fast forward to now. We have won on the web standards front. We’ve never had more capable browsers. Most are evergreen and based on open source projects. The web is a roaring success. Open Source is a roaring success. Want to build something cool? Use an open source, web technology based editor. Host it on a Git based platform that allows people to contribute and you to document it. Check amazing documentation with contributors from huge corporations. And learn what’s possible and what may yet not be ready.

Things couldn’t be simpler, right? Well, yes, but we don’t embrace this enough.

Yesterday I found an excellent repository listing useful resources. I had written a few that fit the bill of this project. So I thought I’d go and contribute them. The project was on GitHub and there were clear and friendly instructions how to add mine.

So far, so hoopy. I forked the repo, I pulled the project. I ran the NPM command to get a CLI wizard to add my projects.

Then the project pulled down 670MB of dependencies. This included a full build of chromium to create a screenshot of my projects. Then my node/NPM setup needed updating as I had it left for a few weeks. Another few megabytes and install steps.

Now, I was in the Microsoft office when I did that, so – hey, whatever. Even at home I have 250mbit downstream, so that’s OK, too. My Mac has a 1TB hard drive, so no worries there…

But here’s the thing. For generating a 10 line JSON object that describes a web resource I spent all this time. I have truckloads of code on my computer I have no idea what it is, how safe it is and if I should keep it up-to-date to be safe.

Imagine me being a much younger, much more eager and gifted developer in a different place. A country where connectivity is at a premium, slow and costs an arm and a leg. An eager person that wants to prove themselves and has a lot to contribute. I can’t. I won’t. And I’d feel terrible for not doing so. I’d feel like I don’t belong. I’d feel like I am not good enough – no matter how much skill I have.

Back to 2005. I have no idea what’s filling up my hard drive. Complex setups are in the way of me contributing. I am not happy. That’s what anyone not as privileged as me would feel like.

We should be better. There is nothing wrong with trying things out. We should use experimental and complex technologies on fun projects. Not much is at stake, they are good for us to play with things.

But – we should not put up random barriers for people who could have fun with us and help us along the way. A small part of us puts a lot of dedication into improving the performance of our projects for our end users.

When you go open source, developers are also users. We should put as much effort into making it easy and fast for people to contribute to our projects. Unless we do so, we will not have any diverse and inclusive community. Let people show their skills – don’t force your devops needs unto them.