Programming libraries and making them freely available, as in a large number of open-source projects seems to me like a definite positive. For instance, the jquery javascript library is freely available, such that learning it is a transferrable skill between jobs, a foundation that other projects can build upon, and means the messy work of ensuring cross-platform javascript compatibility only has to be performed in one place, instead of again and again. There are many other examples of useful pieces of programming infrastructure provided for by volunteer work, from graphics frameworks, to programming languages and so on.
I’d also contend that there is a lot of room for volunteer work within open source, for those looking to contribute in these ways. The project that doesn’t have more issues in their bug trackers than they have people can handle is rare, and often many of these bugs are simple enough that even a relatively new programmer could contribute.
I’m not too sure about that, actually. I’ve always wanted to volunteer in open source, but have found parts of the learning curve pretty close to vertical. As a high school student with substantial experience in programming and algorithms à la the USACO and other diversions but barely any in actual development (project organization, version control, etiquette &c.), I find it a bit of a Catch-22 that open source usually demands basic development skills but that the best way to acquire those same skills is apparently open source (or an internship). I’ve found [resources that are supposed to help with the process] but none of them really seem to lower the activation energy quite enough.
1) Get involved in big, professional open-source projects with small bug-fixes, documentation, and bug reporting. Not glamorous, but it will let you understand the software structure and development practices.
2) Get involved in a more marginal project where they need all the help they can get, and contributing a new feature is easier.
3) Make your own project, like a webapp, that’s more aligned with the typical design and features of project you might be interested in, letting you understand relevant aspects of design and version control that USACO won’t teach. Don’t expect anyone else to contribute, this is just a fun project for you to build your skills.
1) Get involved in big, professional open-source projects with small bug-fixes, documentation, and bug reporting.
For a high school student it’s not straightfoward to know the step by step process he has to go through to contrubute bug-fixes or even documentation.
If you want to edited an Wikipedia page that’s a lot more straightforward than editing the documentation of an average open source project.
I personally have edited Wikipedia plenty of time and can’t remember contributing to open source documentation because the complexity of figuring out how to go about contributing is too high to bother in particular cases where I see something that might be fixed.
A step by step guide about how to go about fixing a simple bug would be very helpful.
An easy first step is to just report the problem with the documentation when you find it. Something can’t get fixed if it’s not found, and reporting bugs should be pretty simple through the github interface for your standard project.
As for contributing fixes, you’ll need to have a little experience with forking, creating pull-requests etc, but the nice thing is that these are basically free to play around with for open source projects on git-hub (or bitbucket). Most documentation will be in one of a few basic formats in the project’s source code (markdown is popular, as is re-structured text for python projects). These are usually designed to be relatively easy to edit, and are fairly simple to find tutorials and introductions for.
Another way you can help out without fixing bugs is by triaging existing bugs. Not all projects need these, but a lot of larger ones have a problem with just sorting through bugs to find what matters, what’s urgent, what’s a duplicate, or a won’t fix etc. Many are more than happy to welcome a new volunteer on board who can just read through new tickets as they come in and set labels such as ‘duplicate’ or ‘blocker’. Being involved in the process in this way, you can then follow along seeing how the existing core developers go about fixing bugs, and pick up from there.
Figure out what technologies the open-source project uses, then google “X tutorial” for each such X. Or get an book on X. Build a simple app of your own using X, then start to extend it by searching an X reference for information on what you want to be able to do. Google ruthlessly whenever you run in to problems. (Professional software developers are Googling constantly.)
You may want to check out OpenHatch, a project that, among other things, organizes open-source projects you can help with by difficulty and language. This should help a lot with the learning curve. There are also some “missions” for beginners that teach development skills like how to use version control or apply a patch.
Edit: Huh, looks like all the available tasks are “bitesize” difficulty right now. I don’t recall that being the case before.
Working on your own projects first, even if they’re small things and not likely to be used by other people, could be an easier way to learn the basics. Building things from scratch can be easier than trying to understand someone else’s code.
The using git, installing things on Linux, and co-ordinating with people already on the project were the parts of the learning curve that I still struggled with after learning programming in college. If you have any friends who do open source, maybe ask them to help you get set up to work on the same project? For the technical difficulties, I had to just keep googling and trying other things until I figured it out, in a lot of cases. It took a lot of patience to do it that way.
Do you have a reference point for the magnitude of the impact? Would you expect someone to be able to do more good doing these things than as a software engineer? Is the effect on the same order?
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.
As John_Maxwell_IV says, it really depends on the project. A good recent example is the knockout javascript library. My last job was focused on building javascript/REST-API driven dynamic admin interfaces. Without knockout, having to use just jquery & native JS I don’t think it’s an exaggeration to say I may have been an order of magnitude less productive. Some of the more advanced features I was able to deliver would probably have been too complex to manage.
Of course, not everybody working away at their own new great idea should expect to be able to have anywhere near that level of impact, but I think it gives a good estimate of the sort of impact that is within grasp for the most successful experiments / projects.
Programming libraries and making them freely available, as in a large number of open-source projects seems to me like a definite positive. For instance, the jquery javascript library is freely available, such that learning it is a transferrable skill between jobs, a foundation that other projects can build upon, and means the messy work of ensuring cross-platform javascript compatibility only has to be performed in one place, instead of again and again. There are many other examples of useful pieces of programming infrastructure provided for by volunteer work, from graphics frameworks, to programming languages and so on.
I’d also contend that there is a lot of room for volunteer work within open source, for those looking to contribute in these ways. The project that doesn’t have more issues in their bug trackers than they have people can handle is rare, and often many of these bugs are simple enough that even a relatively new programmer could contribute.
I’m not too sure about that, actually. I’ve always wanted to volunteer in open source, but have found parts of the learning curve pretty close to vertical. As a high school student with substantial experience in programming and algorithms à la the USACO and other diversions but barely any in actual development (project organization, version control, etiquette &c.), I find it a bit of a Catch-22 that open source usually demands basic development skills but that the best way to acquire those same skills is apparently open source (or an internship). I’ve found [resources that are supposed to help with the process] but none of them really seem to lower the activation energy quite enough.
Am I approaching this from the wrong angle?
There are three ways to approach it.
1) Get involved in big, professional open-source projects with small bug-fixes, documentation, and bug reporting. Not glamorous, but it will let you understand the software structure and development practices.
2) Get involved in a more marginal project where they need all the help they can get, and contributing a new feature is easier.
3) Make your own project, like a webapp, that’s more aligned with the typical design and features of project you might be interested in, letting you understand relevant aspects of design and version control that USACO won’t teach. Don’t expect anyone else to contribute, this is just a fun project for you to build your skills.
For a high school student it’s not straightfoward to know the step by step process he has to go through to contrubute bug-fixes or even documentation.
If you want to edited an Wikipedia page that’s a lot more straightforward than editing the documentation of an average open source project.
I personally have edited Wikipedia plenty of time and can’t remember contributing to open source documentation because the complexity of figuring out how to go about contributing is too high to bother in particular cases where I see something that might be fixed.
A step by step guide about how to go about fixing a simple bug would be very helpful.
An easy first step is to just report the problem with the documentation when you find it. Something can’t get fixed if it’s not found, and reporting bugs should be pretty simple through the github interface for your standard project.
As for contributing fixes, you’ll need to have a little experience with forking, creating pull-requests etc, but the nice thing is that these are basically free to play around with for open source projects on git-hub (or bitbucket). Most documentation will be in one of a few basic formats in the project’s source code (markdown is popular, as is re-structured text for python projects). These are usually designed to be relatively easy to edit, and are fairly simple to find tutorials and introductions for.
Another way you can help out without fixing bugs is by triaging existing bugs. Not all projects need these, but a lot of larger ones have a problem with just sorting through bugs to find what matters, what’s urgent, what’s a duplicate, or a won’t fix etc. Many are more than happy to welcome a new volunteer on board who can just read through new tickets as they come in and set labels such as ‘duplicate’ or ‘blocker’. Being involved in the process in this way, you can then follow along seeing how the existing core developers go about fixing bugs, and pick up from there.
Figure out what technologies the open-source project uses, then google “X tutorial” for each such X. Or get an book on X. Build a simple app of your own using X, then start to extend it by searching an X reference for information on what you want to be able to do. Google ruthlessly whenever you run in to problems. (Professional software developers are Googling constantly.)
You may want to check out OpenHatch, a project that, among other things, organizes open-source projects you can help with by difficulty and language. This should help a lot with the learning curve. There are also some “missions” for beginners that teach development skills like how to use version control or apply a patch.
Edit: Huh, looks like all the available tasks are “bitesize” difficulty right now. I don’t recall that being the case before.
Actually, OpenHatch was going to be the target of the ill-formatted link in my comment. Sorry about that!
Working on your own projects first, even if they’re small things and not likely to be used by other people, could be an easier way to learn the basics. Building things from scratch can be easier than trying to understand someone else’s code.
The using git, installing things on Linux, and co-ordinating with people already on the project were the parts of the learning curve that I still struggled with after learning programming in college. If you have any friends who do open source, maybe ask them to help you get set up to work on the same project? For the technical difficulties, I had to just keep googling and trying other things until I figured it out, in a lot of cases. It took a lot of patience to do it that way.
Thanks.
Do you have a reference point for the magnitude of the impact? Would you expect someone to be able to do more good doing these things than as a software engineer? Is the effect on the same order?
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.
Economic impact of FOSS in general (the article actually mentions java script libraries): http://radar.oreilly.com/2012/07/open-source-small-business-report.html
EU study about the economic impact of FOSS (somewhat dated − 2006, but interesting to read in comparison): http://ec.europa.eu/enterprise/sectors/ict/files/2006-11-20-flossimpact_en.pdf
FLOSS market penetration is also high – a large share of private and public organisations report some use of FLOSS in most application domains.
Almost two-thirds of FLOSS software is still written by individuals
A presentation about FOSS effects (recent but a jumble of information): http://de.slideshare.net/SFScon/04-carlo-daffarasfscon
A published FOSS case study about economic impact: http://www.openhealthnews.com/blogs/groenpj/2012-07-29/latest-report-about-economic-impact-open-source-small-mid-size-businesses
Thanks! These are helpful links.
As John_Maxwell_IV says, it really depends on the project. A good recent example is the knockout javascript library. My last job was focused on building javascript/REST-API driven dynamic admin interfaces. Without knockout, having to use just jquery & native JS I don’t think it’s an exaggeration to say I may have been an order of magnitude less productive. Some of the more advanced features I was able to deliver would probably have been too complex to manage.
Of course, not everybody working away at their own new great idea should expect to be able to have anywhere near that level of impact, but I think it gives a good estimate of the sort of impact that is within grasp for the most successful experiments / projects.