It really depends on the project. Some projects like Linux and jQuery are core societal infrastructure. But there are loads of hobby open source projects languishing on Github.
If you spot a need for something that doesn’t exist yet and build it, that can potentially be a huge contribution (Linux is an example, but there are smaller examples of cool clever things getting attention on the Hacker News homepage all the time).
If you create another solution where other solutions already exist, I’m not sure if you’re adding value. There used to be lots of JavaScript frameworks like jQuery. In the past few years, jQuery has emerged as the clear winner. It’s arguable that all the non-jQuery solutions actually subtracted value. For example, the company I work for rewrote its old Prototype-based frontend code to use jQuery. If Prototype hadn’t existed, maybe we would have used jQuery to begin with. Some say competition and fanboyism in open source can be better for users as it leads to developers adding features to their tool in order to make it the best one. I’m not sure how true this is.
If you fix bugs, improve documentation, or add features to an open source project that’s the best in its class that seems pretty clearly positive-impact. But in my experience, best-in-class open source software is generally best-in-class for a reason—it’s already fairly bug-free and featureful. (Improving documentation probably has more low-hanging fruit.) Apache Hive stands out to me as an unusually crappy piece of open-source software, but it may not be best in its class. (If you became a core Hive contributor that would be a very good thing to have on your resume since it makes use of a lot of difficult and sexy Big Data concepts, but this is probably out of range for all but the most brilliant teenage programmers.) There may be a sweet spot of project obscurity where it’s not so obscure that no one uses it, but it’s obscure enough that the project has not gotten the care it needs.
One way to think about finding high-impact opportunities is seeing it like hunting for opportunities in the economy. If open source project X is widely used and really needs feature Y, someone will probably add feature Y soon for their own satisfaction. To have an outsized impact, predict which projects could potentially see heavy use and help them get there by fixing bugs and adding features, or create some clever solution to a problem people didn’t know they had.
Thanks for the long and thoughtful comment! We’ll be referring to it repeatedly as we learn more about contributing to open source software as an extracurricular activity.
You’re welcome. Please don’t read in to it too much… although I am a professional software developer and have made use of open-source software lots, I haven’t contributed to it much. So there might be things I don’t know. (Would appreciate it if someone who has contributed to open source could weigh in and say what I got right/wrong!)
I would add only that the early proliferation of Javascript frameworks was not a bad thing. Not at all! Sure, libraries like Prototype turned out to be evolutionary dead ends, but:
We didn’t know that at the time. All we knew back then was that web programming was a tragic mess, and that we wanted to get away from the status quo as quickly as possible.
jQuery won in large part by adopting and refining the best ideas of the other frameworks. For example, you’ve probably never heard of Behavior.js, but here’s John Resig in late 2005, discovering from it how awesome pseudo selectors are and then thinking through ways to better present them to a general audience.
Without Prototype and frameworks like it, jQuery would never have existed. It still sucks that you had to port it, though; my sympathies for that.
Makes sense. But from a utility maximization standpoint, if I have some cool idea like pseudo selectors that I want to introduce to more people, I’d argue that I’d often be better off trying to improve the best-in-class tool (even if it’s initially just a fork/branch/etc.) than creating another competing tool.
In a sense, they did: everybody wrote Javascript frameworks, instead of writing new languages which compiled to Javascript.
But all kidding aside, it’s hard to predict in advance which cool-sounding ideas are actually cool, and it’s very hard to maintain a best-in-class tool if you’re willing to merge concepts that haven’t been battle-tested elsewhere. This is another reason jQuery won: its plugin system gave it a way to cultivate ideas that could be awesome but that weren’t yet ready for the big show.
It really depends on the project. Some projects like Linux and jQuery are core societal infrastructure. But there are loads of hobby open source projects languishing on Github.
If you spot a need for something that doesn’t exist yet and build it, that can potentially be a huge contribution (Linux is an example, but there are smaller examples of cool clever things getting attention on the Hacker News homepage all the time).
If you create another solution where other solutions already exist, I’m not sure if you’re adding value. There used to be lots of JavaScript frameworks like jQuery. In the past few years, jQuery has emerged as the clear winner. It’s arguable that all the non-jQuery solutions actually subtracted value. For example, the company I work for rewrote its old Prototype-based frontend code to use jQuery. If Prototype hadn’t existed, maybe we would have used jQuery to begin with. Some say competition and fanboyism in open source can be better for users as it leads to developers adding features to their tool in order to make it the best one. I’m not sure how true this is.
If you fix bugs, improve documentation, or add features to an open source project that’s the best in its class that seems pretty clearly positive-impact. But in my experience, best-in-class open source software is generally best-in-class for a reason—it’s already fairly bug-free and featureful. (Improving documentation probably has more low-hanging fruit.) Apache Hive stands out to me as an unusually crappy piece of open-source software, but it may not be best in its class. (If you became a core Hive contributor that would be a very good thing to have on your resume since it makes use of a lot of difficult and sexy Big Data concepts, but this is probably out of range for all but the most brilliant teenage programmers.) There may be a sweet spot of project obscurity where it’s not so obscure that no one uses it, but it’s obscure enough that the project has not gotten the care it needs.
One way to think about finding high-impact opportunities is seeing it like hunting for opportunities in the economy. If open source project X is widely used and really needs feature Y, someone will probably add feature Y soon for their own satisfaction. To have an outsized impact, predict which projects could potentially see heavy use and help them get there by fixing bugs and adding features, or create some clever solution to a problem people didn’t know they had.
Note: I don’t consider myself an expert.
Thanks for the long and thoughtful comment! We’ll be referring to it repeatedly as we learn more about contributing to open source software as an extracurricular activity.
You’re welcome. Please don’t read in to it too much… although I am a professional software developer and have made use of open-source software lots, I haven’t contributed to it much. So there might be things I don’t know. (Would appreciate it if someone who has contributed to open source could weigh in and say what I got right/wrong!)
I would add only that the early proliferation of Javascript frameworks was not a bad thing. Not at all! Sure, libraries like Prototype turned out to be evolutionary dead ends, but:
We didn’t know that at the time. All we knew back then was that web programming was a tragic mess, and that we wanted to get away from the status quo as quickly as possible.
jQuery won in large part by adopting and refining the best ideas of the other frameworks. For example, you’ve probably never heard of Behavior.js, but here’s John Resig in late 2005, discovering from it how awesome pseudo selectors are and then thinking through ways to better present them to a general audience.
Without Prototype and frameworks like it, jQuery would never have existed. It still sucks that you had to port it, though; my sympathies for that.
Makes sense. But from a utility maximization standpoint, if I have some cool idea like pseudo selectors that I want to introduce to more people, I’d argue that I’d often be better off trying to improve the best-in-class tool (even if it’s initially just a fork/branch/etc.) than creating another competing tool.
In a sense, they did: everybody wrote Javascript frameworks, instead of writing new languages which compiled to Javascript.
But all kidding aside, it’s hard to predict in advance which cool-sounding ideas are actually cool, and it’s very hard to maintain a best-in-class tool if you’re willing to merge concepts that haven’t been battle-tested elsewhere. This is another reason jQuery won: its plugin system gave it a way to cultivate ideas that could be awesome but that weren’t yet ready for the big show.