Why Computing Students Should Contribute to Open Source Software Projects
cacm.acm.org
cacm.acm.org
Universities are not vocational education facilities though. Time a student has in university is better spent on getting deeper understanding of things that are hard to pick up in the workplace, and that give you a better picture of the industry in the long run
Conversely, Jira-fu, unit testing, peer reviewing etc. is something a junior engineer learns in their first year at work. And burdening open source maintainers with training students in these issues is hardly a good idea. In my (probably unpopular) opinion, it's better to start contributing to open source projects after having some experience with real projects at work, not the other way round. Just because at work one has a supervisor and optionally a buddy/mentor, which open source projects have no opportunity to provide.
I found one recently that does some interesting stuff, a formal verification library for Rust: https://www.pm.inf.ethz.ch/research/prusti.html
1) No, universities shouldn't waste too much time preparing people for the job; they should prepare give people the more scientific types of skills that one doesn't really pick up on the job: Data structures, algorithms, paradigms like OOP and FP, etc.
2) Unleashing a horde of yet incompetent newbies on the open source world with a mission to contribute won't be helping FOSS; what's more, if this was the norm, it would cause much more harm than good by spamming projects with low-quality contributions. See Goodharts law.
I do also wonder what people *precisely* mean when they talk about "data structures and algorithms" in context of academia
You talk from perspective of competitive programming?
It's dependent on the job, but anyway they can learn this stuff not only during work hours (learning hours or whatever it is called), but also in their free time
It's not like only Academia is authorized to teach DS&A, FP
It shouldn't be the default that university teaches you job skills and leaves you to learn the theory on your own.
Honestly, I really don't see a solid case there.
University teaches you about theoretical computer science, not problem solving skills for software engineering.
No university teaches you about how to assess an engineering problem, how to break it down, how to create at timeline/estimate, etc.
Many of them do actually. Obviously you will not be very good at it before having actual work experience, but it is useful to be open to thinking about it.
Yet that's the opposite of what the article focuses on: mostly soft-skills and all the fluff that surrounds the actual engineering work, like dealing with project maintainers, figuring out github, etc.
This approach, when taken to the extreme*, would lead people to be very good at explaining why they opened a certain pull request, but couldn't even merge it on the CLI because that's not something you need for a FOSS contribution.
* note this part
Have you taken a senior/graduate level DS&A class before? Part of it is about proving the correctness of the algorithms and making guarantees about the DSs. It's not about competitive programing or acing leetcode interviews at all.
In the class I took we didn't write hardly any actual code.
I've taken DS&A class during CS Eng. degree, it was bullshit about sorting algorithms while using 1-indexed arrays in languages that used 0-indexed approach, nothing fancy.
I wish it were about TLA+ and formal proving
In my opinion, there are far too many people enrolled in CS programs who would be much better served by a software engineering degree or program. However, modifying the way CS is taught us not the answer. A separate niche needs to be carved out.
Nowadays there are even bridges to "proper" universities if you want to pursue a more academic MSc after your vocational BSc.
The whole bachelors -> masters -> PhD process is just winnowing out the unworthy and stupid. The ones who survive this and go on to publish papers are the entire point.
The entire IT industry is a byproduct of CS research, not the point of it. The point of it is to explore the intellectual realms enabled by the mathematics of CS.
Reducing this to "university CS departments exist to train programmers" is ridiculous.
Slightly tongue in cheek, but not too much.
Also, most of their money.
Or don't start by contributing code. There's a lot of work to do in areas like bug triage, reproducing issues or creating setups which do that.
I used to be part of a commercial, but open-source project. Unfortunately we didn't have the resources to scrutinise every pull request that arrived and I think few projects do.
I see this argument a lot; universities would like to not be vocational education, but unavoidably they are. Certainly for all the older class of professional job: engineer, actuary, lawyer, doctor. For those you absolutely have to go to university to even begin your vocational training.
Programming is different in that the degree is less of a hard requirement (but still mandatory for your CV for a lot of employers), and you can get by with a three-year degree. But the history of non-university vocational training for programmers is a bit controversial (e.g. Lambda school https://news.ycombinator.com/item?id=25415017/ ) and there's not that many of them even in the US. What's the UK equivalent to Lambda School? The French equivalent?
> Conversely, Jira-fu, unit testing, peer reviewing etc. is something a junior engineer learns in their first year at work
A formal apprenticeship model would be great for programming, but there's a lot of obstacles to that.
University is a time to explore new ideas and old ideas at a level of detail that one hopes they can maintain throughout their career, but most likely once one enters a career they are focused on the needs of their employer, which is not necessarily the best for personal advancement or the advancement of software as a whole.
likewise germany has the fachhochschule, which is also expressly for vocational education at university level.
i would not call those equivalents to lamda school, mostly because lambda school is private profit oriented startup, whereas french and german engineering schools are established government funded public schools with a history of more than 50 years.
one could argue that maybe US community colleges should be the US equivalent of those schools with a focus on vocational education.
I do some TA in such schools (ENSEIRB) and every year I make students contribute to OSS, generally by writing small plug-ins to an existing software, it always works fine. Not a lot of them keep going afterwards though.
" En breve:
Diferencia entre politécnico y universidad.
• Las universidades tienen un enfoque más amplio y enseñan materias con énfasis en impartir conocimientos básicos con muchos aspectos teóricos con un poco de trabajo de proyectos y tareas de laboratorio..
• Por otro lado, los politécnicos son más prácticos en su enfoque y toman cursos más pequeños que son específicos de la industria y no se enseñan en las universidades..
• Así que además de los títulos de ingeniería, hay una gran cantidad de otros cursos, diplomas y certificados que se ofrecen en estos politécnicos que son de menor duración y ayudan a los estudiantes a obtener empleos en industrias. "
For the english speaking crowd, https://translate.google.com/translate?sl=es&tl=en&u=https:/...
I just think universities should give their alumni focus on the big picture and long term, they will get enough exposure to mundane tasks like reviews at work.
You want some CS concepts, with emphasis on what is fashionable the work market, you got into a three year degree in a vocational degree.
This changed a bit with Bologna, but the overall process is mostly the same, just now the Enginnering order requires the master degree (which is the old 5 years degree).
(I had only heard of the city in Italy and the type of sausage so was confused, this was the most likely sounding thing that came up on a search)
Is there? The standard for the locality I live in, around the University of Michigan, is that students seem to be trying to pick up internships every summer now, including their first summer after being a freshman. It also not uncommon to see people who graduated with several internships on their resume. When I graduated ~2000 the general standard was one in your last summer.
France has *tons* of vocational dev training, through a variety of systems. They are mostly split between :
- Public technical schools (ran by the state) that deliver degrees with ECTS credits (pan-European degree system) over 2/3 years.
- Technical training schools, mostly private, that deliver titles validated by the Ministry of Work. ie. industry certifications only valid domestically. Over 6/12 months.
French engineering schools are a completely different beast and would be considered part of the university system in the US. They issue masters degrees over 5 years valid pretty much everywhere and the title of Engineer (it's illegal in France to call yourself an engineer without it !).
I don't know how famous/big they are, but I have already heard about it from more than one person, which makes me think that they are gaining traction.
programming is much much more that being proficient in the current tools of the day.
It exists since 1997-1999, varying on the country. An apprenticeship takes nominally between 3 and 3½ years, concludes with a level 4 EQR and the rules and by-laws are determined by the chamber of commerce, who also holds the examinations. It is treated as a trade, similar to blue collar professions like heating installer, lathe operator etc.
the problem is that this doesn't matter, because all the industry expects is programming skills, and while any fachhochschule, french engineering school, or even a US community college could provide those programming skills, the university provides them too, and as a result, a university graduate has more job options than a graduate from those other schools.
if i can, i will prefer the school that gives me more options later on. that also explains why everyone wants to get into the top schools, because those provide even more options.
computer science students would have to have a bad reputation as programmers in order to stop companies who need programmers from hiring them.
or we change the system such that you always start with vocational training as a programmer on a school dedicated for that before you decide to either get a job or move on into academics. requiring that academic researchers have relevant industry level training doesn't seem like a bad idea.
I don't think it is unreasonable to have alternatives to the university education model. But I also think that employers would be very foolish to demand that junior engineers have prior experience with git.
Becoming a senior engineer usually takes lots of on the job experience, one can't really train for it. A PHd helps, but unless it models the same shared industrial scale codebase, there will be gaps in the schooling vs a large engineering org.
One could get a masters (extra year in the US) in the missing semester skills. Learning to refactor could be a 5 credit course. Same thing with testing, could cover property testing, ci/cd pipelines, incremental repeatable builds, fault injection, gradient descent, rollback, fuzz testing, formal methods, proof systems etc. but in a practical way.
It is one thing to know about a skill vs having actually used the skill to solve a problem. It takes years to actually learn how to use Git well. Same for most processes and tools, a formal education in those areas would accelerate the state of the whole industry.
Two things should probably happen. One for early education and second for post hs.
The whole k-12 education system should get more rigorous, front load the early education and get everyone on a rock solid foundation. Like everyone exiting 5th grade can read the international phonetic alphabet and are fluent in a second language at at-least the 2nd grade level.
For post highschool academic education, the credit hours to graduate should be extended or be made variable depending on the degree. Some "hard" science degrees already do this, by declaring 5 credit courses as 3 credits. Still 90 credit hours to complete but the difficulty is much higher. Basically the 4 year degree is now the 5+ year degree. This is ok.
We have or did have a huge commercial market for computer jobs in the "code camp/school" space. All these new participants showed up because there was a huge need for these skills. They mostly teach the missing semester stuff and build a ton of context so they don't get shunned at the new job for the huge gaps in their knowledge.
I think the commercial votec school system does need to get some form of accreditation.
I will not discuss the levels of foolishness by employers in their hiring practices. Utter insanity.
i was not aware that the french engineering schools were at that level.
so in fact that means that france has achieved what everyone else should aspire to.
The problem with trying to have all students (not "some exceptional students", but all students) going out and engaging with the real world of open source is that the degree of difficulty in navigating different open source projects is enormous and may not be obvious to the professors nor students ahead of time.
Some students may wind up working on projects with nice guard-rails, helpful communities, plenty of up-to-date high-quality documents for how to contribute. Others... maybe not so much. It will be very hard to judge whether students have been successful and to compare their performances against each other (a perennial chore of academia, but one that people seem to insist on: grades!).
Otherwise it creates absurd situation in which highly expensive institution is demanding that part of teaching is done by third parties for free.
That said, I would love if the professor would reach out so I could recommend specific issues and let them know whether I'll be particularly available for more in depth PR mentoring this semester.
It does seem like they're accounting for the burden put on maintainers as well:
> Getting a contribution accepted is not a prerequisite for passing the assignment
> a small-scale contribution is the only realistic goal. The key to making the course's assignment work, is to have what are, on first sight, very low ambitions for the students' contributions.
That may be the case, but the job market for grads is fierce (or at least was when I went through the gauntlet 5 years ago) and projects absolutely help students stand out.
>burdening open source maintainers with training students in these issues is hardly a good idea
I've had exactly this happen - a random Argentinian student I met on Reddit modernised a whole lot of my project's codebase and we went through the review process together etc. "Burden" is not the word I'd use; it was a positive experience without a doubt and the contributions he made were generally of a high standard.
In that context, it's not surprising that many public universities do see post-college employment metrics (employment rate, median salaries) as an extremely important measuring stick of success. Many of these programs do make efforts to include vocationally-applicable education in the core curriculum, because it helps to keep those numbers up.
Apart from the top ivy league schools, many schools are not going to teach the theory stuff well anyway.
And teaching the tools (not JIRA but, say git and docker) are not dry carpentry, there are concepts which a computer science student should be equipped to understand.
Last time I remember, an MIT course on programming tools gained traction on this site.
As for not contributing to OSS projects right away, I agree, universities should rather have a project after each course completion so that students get to exercise the concepts.
Open source projects do not, and have never, gone out of their way to teach these things.
Ofc doing it for a grade is silly
But if you contribute to open source, you must follow the etiquette or your PR is denied etc.
What inexperienced programmers get from open source is that experience where they better learn how to fit in effectively, or they get bounced.
In the nicest possible way, open source is a great way for people on the HS/college track to take responsibility for themselves.
It doesn't require much active effort on the part of the open source community to deny a PR or exclude a bad apple if that makes sense.
And I'd say the majority of open source communities long ago put systems in place to deal with bad apples (or should have).
I'd recommend it for someone/student who feels like their technically competent but never got the chance to work with an already built codebase and a team because it really puts you up to the test.
This depends on your country. In many countries they are.
Also even in countries were the undergrad system is intended to be broader (e.g. US, Canada), politicians typically discuss it as if it were a job training system.
Their prices say they are. There is no way they could be as expensive as they are, except that they are capturing a lot of the value of the vocational education they are expected to provide. Their prices speak louder than high-falutin' principles.
I'll permit University's their "we're not vocational training facilities" argument when their prices come back down to something like a 1980s level and reflect their expectation that they are not doing vocational training.
In US Engineering is framed as a very practical, "how-to" oriented, to the point that people can be surprised to learn that engineers do research and publish papers.
I am surprised that more Computing departments haven't embraced Open Source. It seems like it would be a great way to introduce students to larger projects, and act as a great advertisement for their core areas of expertise. After all who hasn't heard of BSD, or X11.
It ought to be out there along the ASME's racing events where students design and build race cars. Why shouldn't Computing students design video or audio codecs, raspberry pies, or other things for real world experience?
"Hey, can you merge this PR? I'll fail if you don't review and merge this by tomorrow morning. I'm sorry I left it until the last minute but I had a bunch of work do to in another class and couldn't get to it until today."
"Hey, I ran everything through flake and black and spent the past 72 hours getting my test coverage (and the coverage of the rest of the project) to 100%. /Now/ will you approve this PR?"
"Hey, you stopped responding for the past week, are you on vacation? Is there any chance of approving this PR by Friday?"
I for one wish my university had a few extra classes that were 'practical'. I eventually picked up those skills because I had to. I am not talking 60+ hours of it. Like 5-10 would have been more than plenty. Those skills would have been directly applicable to everything I did while I was there as well. Something simple like 'what is source control', 'practical examples of code organization and refactoring' would have saved me more than a few times in college.
But yeah picking an opensource project to dump these skills classes onto will end up as a bad time. Unless the prof/ta is in the mix and helping that project. From my exp from some profs, that is not going to happen.
A better option would be to require students to work on projects which depend on eachother, and practice pull-requests on eachother's student projects.
The instructor forks a real open source project, with an existing license, contributor guide, etc. The instructor then picks an issue from the issue tracker with a known solution, but no PR yet.
The assignment is to submit a PR to the instructor's fork of the project that fixes the issue, and the PR itself is the final project submission. Points can be deducted, according to a rubric, for failing to pass the test suite, failing to follow contribution guidelines, etc.
Choosing an issue that has not been publicly resolved in code should prevent obvious cases of plagiarism.
I'm not sure if this could scale up to a big lecture-type course with TA is doing the grading, but I think it could be a fun assignment.
The risk of course is that there is some unforeseen problem preventing the "known" solution from being valid. But maybe that in and of itself is part of learning exercise...
I think if you want your university program to teach real world skills, a co-op program is the only non-abusive way to do that.
I paid my way through university with co-op jobs.
or maybe the teacher/professor IS on the maintainers list?
But not all students in training are skilled, and making code contribution a required part of a program seems certain to reduce the average quality of PRs. The problem is that somebody has to review those PRs, and often interact with the proposer for quite a while, to teach them the approach that is desired for the individual project. PRs that go against the grain are not always worth the effort.
In the scenario of the article, open-source developers are saddled with a new task: teaching students, many of whom will be unmotivated by anything more than a grade.
No thanks. Hard pass.
If professors want students to learn how to interact in a group setting, then the students ought to be designing their own software. If there's a perceived need for larger-scale projects, the professors ought to set them up and maintain cohesion and momentum across terms. If the professors don't have ideas for such projects or the time to spearhead them, well, then that's a bit of a sign.
...
> Choosing realistic contribution goals. (Initially students tend to wildly overestimate their ability to contribute to a project.) This is a key activity in agile development sprints;
...
also
> Try to contribute a trivial fix as a warm-up exercise and as a way to test your ability to follow the project's workflows.
Finding trivial fixes is no trivial task though. Some projects do have a tag like `good_starter_bug` but most don't. Projects that actually have lingering trivial fixes tend to be rather huge too.
But yeah, I'm not looking forward to a future where every inexperienced student needs to be guided through the basics. There is already quite a lot (too much, IMO) being put in the shoes of volunteer maintainers with very little concrete in return, and this will only add to that.
To put it bluntly, I am not your unpaid teaching assistant, and would consider it dubious if I was used as such without consent.
Meanwhile Huawei is a real big contributor. https://news.itsfoss.com/huawei-kernel-contribution/
Some of my colleagues do something similar to this, where the students work on an open source project which is maintained by academics. They do get some amazing patches which add significant new features, but there are also some students who need help. It's a valuable learning experience for the students (which it should be, they are at University!), and at the end they are much more ready to usefully contribute to open source projects.
However, I wouldn't feel it was fair to impose that on another open source project, as almost all projects are "reviewer time poor".
Personally I can say it was a really good experience and it certainly made me look at open source development (and programming in general) from a more nuanced perspective - and I suppose it would definitely be a good idea to introduce such courses when students are sufficiently prepared for them, in the more advanced stages of their study programmes.
[0] - "IN4315 Software Architecture" (https://se.ewi.tudelft.nl/delftswa/) [1] - "DESOSA 2019" (https://se.ewi.tudelft.nl/desosa2019/) [2] - "AOSA" (http://aosabook.org/en/index.html)
Thank you for sharing, and I am really excited to dig into the 6 (and counting) books the students of this course have produced.
Reviewing even a trivial PR, making sure it doesn’t introduce any regressions, costs time. Every added functionality needs to be maintained until it’s retired.
I hope students who do that understand that contribution to an open source project is not a trivial thing.
Documentation is also a good thing to add. The perspective of a fresh user is precious and only lasts so long. Documenting the onboarding process can point to documentation shortcomings that are great to fix.
Both doc and test have the advantage of not breaking stuff for other users. Sort of, adding huge tests that make CI timeout or bogus doc is not ideal either.
But at least both of those are on the starting path of understanding how the project works, which is a pre-requisite for contributing code.
I just want to add that this kind of documentation is worthwhile even for experienced developers.
I've come across so many projects in my career in which the hardest task of all is figuring out where to start looking at the code. The entrypoint is often non-obvious and starting at main() often fails to elucidate the narrative of the program.
To rectify this moving forward I've started keeping something of a development journal with new software I write. It's a cross between a README and a changelog and a sitemap; like printed MapQuest directions for my code.
https://xenaproject.wordpress.com/2018/10/07/what-is-the-xen...
* Send nice bug reports, with foolproof reproduction steps. Err on the side of too foolproof. People underestimate the importance of bug reports, but they are very helpful. Try to see how they fixed it, so perhaps next time you understand where the error is and perhaps fix it. (Sometimes navigating the project structure is hard, and it's difficult to even find the file where the error is.)
* Send PR fixing typos. Typos in the docs. Typos in comments. Typos in error messages. The nice part is that it's an easy fix, it's probably correct, and it has a high chance of being approved. (English has a few spelling variants, check that it's not just a en-uk vs en-us difference.)
It's also helpful because you must learn how to clone the project, use github (or gitlab, or the mailing list, or whatever system they are using), and how to interact with the maintainers.
* If you have a feature you want and can implement it, it's a nice PR. Start with easy and short features. Don't spend more than one or two days building it (4 to 8 hours, or even less). Nobody guaranties that it's correct, that it's in the vision of the maintainer, that the maintainer is not a moron. If it's not merged, you've only lost one or two days. If the maintainer likes the idea but want a different implementation, you've only lost one or two days.
Some people recommend to ask in the mailing list or an issue in github/gitlab if the maintainer likes the idea. My English is not so good, and some features are difficult to explain. So I prefer the alternative method of just writing the PR, but only short PR that need one of two days of work.
Be prepare to fix your PR. There are implicit local rules about the code, like tabs vs spaces, trailing spaces, indentation, ... try to follow the local conventions. Also, you may need to add some new test for the new feature or a regression test, and other testing. So expect that sometime you will need additional work to polish the PR.
* For big features, discuss them with the maintainer first. Again, nobody guaranties that it's correct, that it's in the vision of the maintainer, that the maintainer is not a moron.
This reminds me of that in some ways, and I think its success depends a great deal on how people are incentivized. There's a tremendous amount to learn from doing this - and it is nice feeling like your assignment is actually something useful - but it's really important people don't feel like they have to get some big change merged to get full marks. That can lead to unpleasant situations.
Software design and implementation is FUN. Now I know not everyone agrees, but a self contained game etc (no it does not need to be reusable package that are 'useful for other people/future'!) is a very helpful experience for software implementation.
Lately I have been observing an endemic problem in the Python world, this problem is that the demand for open source project maintainers is higher than the number of people that want and can maintain open source projects. This leads to cool pieces of software being abandoned after a few years. Maybe the focus should be on solving that problem.
With that levy you should get it from the government tax free and with minimal hassle.
Oh wait just realized why it would not work...
I can see the appeal of this idea, but what it's ultimately doing is optimising for spam.
For people worried about an influx of low quality PRs on their projects, you have the right to reject bad PRs and you can also help out newbies with nice labels as "good first issue" in Github on issues that they could do. I'm sure if people show up willing to put in some time, there will be lots of OSS projects that can benefit from this.
I certainly do, but I'm worried about the signal to noise ratio on PRs sinking through the floor. After all, it's not as if the difference between a good PR and a bad PR is magically known to me before I open it and read the patch. The maintainer has to spend a certain amount of time to see if the PR is any good, and if there are a hundred PRs more than usual, then the maintainer going to be much more likely to mass-reject all the PRs from a given institution, regardless of how good they are.
We've seen exactly this situation with Huawei and the Linux Kernel, where the kernel maintainers threatened to reject all patches from Huawei because it became apparent that engineers at Huawei were optimizing for the number of patches in the kernel, rather than quality of patches. In the same manner, if a university mandates that a student must have at least one patch to an open-source project in order to graduate, then there is a rather large population of students who will spray patches at every open source project available to them until one of them happens to accept their patch, intentionally or not.
Now, that said, I'm not opposed to the idea. Writing patches to an open-source application could be good as part of a larger project. Have the student pick out an open source project (it doesn't have to be big) and write up a report about the architecture used, the reasoning behind the design, and what issues they see. Then, as part of that process, have them write a patch against the project. This patch should be reviewed by the instructor, and should be graded on its own merits. Then the student should submit the patch to the project. At that point, while acceptance of the patch would certainly be nice, the professor should have enough data about the student's ability to evaluate an existing software project and make a meaningful contribution to it to grade the student even if the patch is not accepted by the time the semester ends.
For open source projects, when someone submits a PR, that cost of time is done by volunteers. For larger projects, reviewing even a "trivial" PR could incur a few hours of work by the reviewers and maintainers. For a non-trivial PR, this is even more of an investment of time by the maintainers.
I'm not trying to say "don't contribute" but rather "be mindful of other people's time."
The "students should contribute to open source projects" and similar "have a class go and contribute to Wikipedia" or "have a class ask and answer Stack Overflow questions" pushes the responsibility of reviewing that material out to volunteers.
The costs of Hacktoberfest and similar "contribute to open source" as a KPI for some organizations are very hard to calculate - but they're there and should not be ignored. This cost is increased when the person is doing it as a one off contribution rather than ongoing as, again, the costs of onboarding the contributor to the workflow for the project is borne by volunteers.
They never went for it.
>The most common problems faced by the students over their assignment are the inability to build the project
sounds like somebody tried to build llvm
With languages like Rust, D or any webdev project it's much easier, because you can go "cargo build" and it will autodownload dependencies and build everything, no matter the OS.
If, however, the university would provide resources to ensure that contributions have the required quality and can assist maintainers with the added load, then it would possibly work! I could imagine that a direct link between maintainer(s) and university supervisor/lecturer would work well, so that maintainers can express their needs and priorities to someone who can handle/govern them in front of the learners.
1. It puts the onus on figuring out what to do on the student. And since there's no promise of guidance from the project, the student could spend on their time flailing around and accomplishing nothing.
2. Large OSS projects require specialized knowledge. It can take years to develop the knowledge necessary to make meaningful contributions to a project. There shouldn't be an expectation that students have the requisite knowledge to contribute. So the student is probably going to be relegated to minor bug fixes, documentation, or other kind of mindless tasks that no one else wants to pick up.
3. It takes time away from learning fundamentals. I think most students would benefit from building their own project rather than contributing to OSS. For example, building a working web server will teach a student a LOT more than a few commits to Django ever would.
Contributing to open source is great for certain students. I love the Google's Summer of Code and the like, where students have an idea of what they want to create, and the project is incentivized to provide a mentor to the student because they get funding. But expanding that model to every student is foolish and hurts less privileged students a lot.
A good middle ground would be to have a course use open source code as a foundation for a project, but not require contributions back to the project. I had a computer security course lab that required us to find a specific exploit in an old version of sudo and create a patch for it. The issue was many years old by this point, so giving the patch back to the project was pointless, but we still learned the fundamentals of working on an OSS project; how to document issues, how to create patches, how to create test cases, etc. And since it was a lab, we could ask other students if we got stuck.
Co-op work is not classwork, so it removes the incentive for students to submit lazy contributions for bad grades. Yet co-op students actually benefit their companies because said companies continue to hire them.
Of course, the main difference with open-source is that nobody is paying the student. But still - either investors in FOSS can "hire" students to work on various open-source projects, or the students can choose to work unpaid (perhaps for less tuition, or part-time work on the side, to make ends meet). But I really think adopting a co-op model would be easier and more effective than trying it in the classroom.
> Future CS Course Already Here In his “President’s Letter” (“Computer Science Education in the 21st Century,” Mar. 2006)
> David A. Patterson suggested creating a course that would leverage high-quality examples from open source software. I’ve been teaching just such a course for the past three years at the Athens University of Economics and Business. The lectures (see www.dmst.aueb.gr/dds/ismr/)focus on how students comprehend, evaluate, maintain, and enhance large software systems.Students’ grades are derived by assessing their contribution to an open source project they select based on their own interests. The course’s theoretical background is covered in my books Code Reading and Code Quality: The Open Source Perspective (Addison-Wesley, 2003 and 2006, respectively); all the examples I use come exclu-sively from large existing opensource projects. Two of the soft-ware systems I use for drawing examples are the very ones Patterson mentioned in his column:BSD Unix and PostgreSQL.
> I also use the source code of other systems (such as the Java HSQLDB database engine, the Apache Tom-cat application server, the ACE networking framework, the X Window System, ArgoUML, and Perl) to cover subjects like object-oriented programming in Java and C++, networking, language processors, and graphics.
> Diomidis Spinellis. Athens, Greece.
Communications of the ACM, 49(8), August 2006, pp 11–13. doi:10.1145/1145287.1145299 https://dl.acm.org/doi/pdf/10.1145/1145287.1145299
I don't know the 'Athens University of Economics and Business', but it sounds pretty vocationally oriented to me.
Open source computing will quite likely be the bulk of computing, with the "closed" parts being but special purpose islands in an ocean of open code (or multiple oceans if you want to navigate licensing differences)
The precise manner and degree that this will happen is not clear. It will depend on how business models on both the open and closed side of the fence evolve, but, from the point of view of an academic institution, equiping students with options to navigate this emerging future is quite sensible.
Open source is not for new coders. Flat out. They are definitely great learning tools for students, but not things they should be touching yet. Unless they can demonstrate they know what they're doing.
- Choose a project with several active contributors.
- Choose a relatively popular project (some GitHub stars).
- Avoid very popular projects.
- Verify that you can build and run the project on your computer setup.
- Ensure the project regularly accepts pull requests from outsiders.
- Try to contribute a trivial fix as a warm-up exercise.
- Look for project issues marked as "Good first issue".
Open source is a great source of learning; architecture choices, battle tested real-world software. So, if a student asks for my opinion, I would say fork it, clone it, study it and if you find something to contribute, great submit your pull request.
In my opinion, employers should start investing in their employees again, as they once did. It's neither morally laudable nor enlightened self interest to throw someone in the deep end and expect them to swim. And in our capitalist system, it's self-indulgent to say that you want something without paying for it. That is ultimately what the article is proposing: that open source contributors sacrifice their spare time to be the mentors companies should provide.
In fact, many of the companies that really prioritize those types of screening tests, don't seem to care much for your side projects - or even your major.
Universities have existed across social eras and political regimes. They should not be catering to the contemporary commercial interests of powerful market forces. They should teach principles, and basic skills, and deeper fundamental knowledge - with concrete programs or programming projects buttressing this goal rather than being the end-all in themselves.
However, collective and collaborative work on a joint project, in particular a software project, intersects that sphere to some extent - so there's a place for it in a curriculum and as a means of practice.
IMHO, however, student involvement in FOSS projects should be voluntary rather than mandated by such a course. It will also help those students who go on to work as professional programmers, but even for the researchers - help to counterpose what they have learned in theory with how you get things to work in practice.
Moreover, and no less importantly: FOSS projects need developer time. So students should contribute to them because they need contributions (and - they're benefiting the public typically more than non-FOSS projects, so better to contribute to the former rather than the latter).
At Mozilla we can tell when each semester begins because our bug tracker receives an influx of bogus bugs that were obviously filed by students who were asked to do so as part of an assignment.
GNU high-priority enhancements: https://www.gnu.org/help/priority-projects.html
GNU looking for maintainer: https://www.gnu.org/server/takeaction.html#unmaint
Why do engineers put up with this?
I could see this as maybe something for a small software engineering course to do. maybe. I think in those cases it might even be better to split the class into teams and have them develop a product idea, elect people to various roles, and execute the plan as a semester long project. Midterms, quizzes, etc become sprint reviews and plannings. It would be great if you could get some of the b-school kids to roll over for a combined class where they takeover PMing.
Admittedly I am cynical. But the way I got into programming was many, many years before I started my CS degree. I just built cool things I needed. I got into reverse engineering because being a lazy high schooler I wanted to build trainers for video games so I could get a high level without actually working on it. Call it pathetic - sure. But playing video games is so boring. It's much more fun to get them to play for you :).
What ever happened to just being interested? I hesitate to suggest this but could it because a lot of people are getting into computer science strictly for the job? So that they reach the terminal points in the program and are completely without direction?
I dunno, just rambling I guess. This just strikes me as so odd.
Nowadays it seems to be perceived as a yet another way to highly paid jobs
It totally exists, but back in our day you built the one computer you had and that was that. Now everyone has lots of computers. So maybe you don't make your own laptop but you can absolutely make a "computer" and hack all kinds of fun things.
See: Arduino, Raspberry PI, STM32 et al., Teensy, BeagleBone, TinyFPGA, etc. etc. etc.
Honestly, I am kinda jealous. You can buy more random electronics than I could've dreamed of as a kid with paper route money (do kids even still do that?). Test equipment too.
Oh, the great and omnipotent marketplace! How we worship thee. Tell us, oh benevolent enabler of civilization, what you require of us, that we may provide it!
I've been a web dev since graduating in 2007 and no longer have the desire to compete in an oversaturated, increasingly complex industry.
If i have to work for someone else, I'd rather take the path of least resistance. Try to be on easy mode. That's just me. I lost my passion for all of it.
We recently started hiring for a junior front end, and I had to review the test results. 95% of the applicants are unable to perform the most basic tasks.
I blame this on all the bootcamps and learn to code courses. There is a flood of unqualified people in this field and it's just tiring for me to imagine the future. One where my experience has zero value and I have to keep proving myself over again. Who needs it.
Of course unqualified people apply a lot, it's because the secret is out that a bunch of lazy people can get paid obscene amounts in this field! There's a flood of unqualified people because you won't put a salary amount in the ad that will actually attract the right talent. There's tons of ways you can weed out the unqualified people but you won't because there won't be any applications left after that.
It's been like this for as long as I remember, and was probably even worse 20 years ago before the dot-com crash where anyone who could sum up numbers in Excel was a programmer and anyone who knew how to defrag their C:\ drive was a sysadmin. I am exaggerating only very slightly with this.
The essential problem is that the industry has been growing so fast and there are never enough senior programmers to train the junior ones. This is a field that has been doubling in size every 10 years or so for the last 40 years. You're bound to have problems with growth numbers like that :-/