> in the 21st century programming proficiency on its own is neither representative of the skills that the marketplace requires from computing graduates, nor does it offer the strong vocational qualifications it once did.
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.
> Universities are not vocational education facilities though
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.
>What's the UK equivalent to Lambda School? The French equivalent?
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 !).
france has a lot of engineering schools, which are not universities. autoconf is one famous project from a french engineering school.
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.
VLC is another such project coming from a french engineering school AFAIK.
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.
• 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.
"
I don't mean universities should teach some very abstract computer science and exclusively prepare people for research career. But I don't think that vocational learning process as if you train an apprentice to work on the latest model of a lathe is a good model for engineers either.
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.
That is why in Portugal you want the full learning package, CS with enough programming projets, you go into a 5 year degree in an university, certified by the Engineering order.
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).
The French equivalent to Lambda school is https://www.42.fr/ which actually predates Lambda by 3 years and is operating at larger scale (29 campuses worldwide). It's also free unlike Lambda.
"A formal apprenticeship model would be great for programming, but there's a lot of obstacles to that."
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.
Yes - but that's an informal system, not a formal one, and linked to being a university student. Accessing it without having gone through university admissions is harder.
> A formal apprenticeship model would be great for programming
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.
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.
The taxpayers want skills education and that's what they are paying for. The ones receiving the taxpayer funds want to promote fringe ideas and revolutionary societies. So this is a typical principal-agent problem -- the universities take public funds and public guarantees and then try to redirect those for their own private agenda.
This seems very shortsighted. The fringe ideas as you call them are the modern ideas in many cases. Companies can equally benefit from these new ideas coming from recent grads.
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.
"Universities are not vocational education facilities though."
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.
This is more of a US problem. In the EU much of higher education is very cheap or free. Some students even get paid a small amount of money and have access to loans with low interested and great terms so that it's easier to focus on school and everyone is on a more even playing field.
Yes, and in various countries universities have a solid theoretical and scholarly approach to STEM topics.
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.
Universities are not vocational education facilities though
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.
The french "engineering schools" are actually considered the elite scientific education in France. They are infinitely more selective than universities and provide much better job options. Equating french engineering school with US community college makes no sense whatsoever, and saying "a university graduate has more job options than a graduate from those other schools" is plain wrong (in France).
they are not equivalent, and they couldn't be, shouldn't be, and won't be. Most engineering schools recruit after two years of highly theoretical education in mathematics and physics (classes préparatoires) and the level in mathematics and physics is much higher than the undergraduate level in the university.
You're being misled by the term "engineering school" which makes it sound like this is some practical / technical education, when it's in fact the exact opposite.
The industry expects programming skills, yes. But a lot of the missing semester skills (how to use git, how to write unit tests, how to write a design doc) are very easily taught on the job. Topics like data structures and operating systems are more difficult to teach on the job because they do not come up every day and therefore do not get repeated practice.
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.
Teaching the "missing semester skills" are indeed learned by most people on the job because they are often site specific because everyone is self taught in them, so the cycle continues.
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.
In France, an engineering school graduate has far more prospects than a university graduate at masters level. Completely different systems. Schools are for engineering, universities are for science.
Universities are of course nowadays also vocational education facilities (with a strong track on research). I'm always flabbergasted where this misconception about higher education as some form of romantic ivory tower comes from.
I don't really see why they shouldn't be understood as both. Specially in fields like CS, engineering, law, medicine and economics and so on. There is need for highly skilled and educated people in industry even for regular roles. On other hand there is also need for scientist and researches. Both roles are somewhat different, but I dont' see now reason why they couldn't be trained at same facilities.
Well I'll take a stab at why CS should not be vocational. The field is first and foremost a branch of applied mathematics. The tooling taught in a CS program only has utility insofar as it serves to teach the fundamental mathematical concepts. This is especially true for undergrad.
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.
In many European countries, vocational schools (usually called universities of applied sciences, for instance Fachhochschule in DACH, IUT in France) offer just that.
Nowadays there are even bridges to "proper" universities if you want to pursue a more academic MSc after your vocational BSc.
Because universities see themselves as research institutions - that's where they get their prestige and status from, not from teaching. Teaching people to code doesn't do anything for them (except pay some of the bills).
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.
I agree. Further, to the extent that students need to learn "Jira-fu, unit testing, peer reviewing, etc." they can learn this in a controlled environment run by the university.
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!).
And also, open source maintainers are not free teachers. If university expects them to teach students, university first should ask open source maintainers whether they are ok with it.
Otherwise it creates absurd situation in which highly expensive institution is demanding that part of teaching is done by third parties for free.
As an open source maintainer, I'm happy to have contributions from first time contributors, even if they aren't completley familiar with the workflow. It's how I learned, and I'd love be able to pass this experience on.
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.
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.
Yes, there is already a significant amount of it; and that's good. My opinion is that academia should not waste too much time preparing people for a job, but give them as much as possible of precisely the kind of problem solving skills that they won't be picking up on the job.
> 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.
> How can you learn to solve engineering problems without doing engineering?
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.
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
> mean when they talk about "data structures and algorithms" in context of academia
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.
>Have you taken a senior/graduate level DS&A class before?
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 agree, personally as a CS Student, I gave contributing to open source a shot and I felt like it really helped me a lot. Joining a project's slack, chatting with maintainers, developing features with docs and tests and code reviewing really makes you feel like you're an actual software engineer. It gave me quite the confidence boost that I can do this after years of internship rejections and never knowing what I was doing wrong.
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.
> Universities are not vocational education facilities though.
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.
only rich people say this. For poor and middle income, yes universities are vocational. at least in my part of the world. But I've heard lots of privileged people say this, and only them... which is true for them is not true for the pop in general.
> 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.
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.
The CACM Viewpoint proposal doesn't mean that students have to work on the kind of open source projects that businesses will assign developer labour to. The open source projects can be chosen to complement the educational aims of the course.
Maybe not in your neck of the woods. Over the course of my education I attended three separate universities. All of which had Industrial Councils to make sure that their programs were teaching skills relevant to industry. All of them had industry partnerships to get their students exposed to what was current in industry. That was across the entire engineering spectrum not just Computing.
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?
>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
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.
There's a difference between a vocational school, and a university program which teaches vocationally relevant skills. Many land-grant universities especially, were explicitly founded to teach practical, technical, economically relevant skills in the context of a broader liberal arts.
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.
I agree with most of your points. But disagree with the fact that universities should teach only theoretical aspects.
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.
I really liked the separation of the theory and higher learning from classes vs learning the hands-on real-world programming from summer and co-op jobs. Even before I had those, I was already a hobbiest programmer on my own time. The difference these days is that people go into CS/software development as a career job and expect a degree to prepare them for it. I'm all for effectiveness so it would be up to each institution, but hopefully they're not continually churning out programmers who would have been good to have 5 years ago.
I agree with your point of view, it does seem to shift some of the teaching burden from instructors to project maintainers. I generally like the way student performance is assessed, with more emphasis on the technical quality and presentation rather than the binary "was this contribution accepted or not?". However I still think that, depending on the initial choice of the project and the issue to work on, some students may receive a lower grade through no fault of their own, e.g. a PR not getting accepted by deadline, changes required at the last minute, etc. These problems are not present with traditional assignments isolated from the "real world", and I believe those can teach the student just as much as open-source participation, if done right. Take group projects, for instance, where students are expected to collaborate using project management tools, set up unit tests themselves, etc.
Very interesting comment. Having initially taught a more theoretical software engineering course and now teaching this one, I've realized that grasping the theoretical aspects of software engineering without practicing them in a realistic context is difficult and results in pretty shallow learning.
How would this work? How many project maintainers would sign on for this?
"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 have also seen some projects where the maintainers do not suffer fools lightly. Pick the wrong project and you would be in for a bad time.
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.
Yeah I think this is a huge issue. It might be good for the students to get this experience, but it would be horrible for the projects. People working on a project to check a box is not going to lead to good outcomes.
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 that would work. Then the instructor (or a enterprising student) could push the PR back to the real project if it turns out to be worthy of a real merge.
My schools senior projects were group projects done for real people out in the world. A similar thing could be done where the instructor would solicit a dozen OS projects that would be willing to trade labor for responsiveness.
Hmm I don’t feel that strongly. But the status quo in schools is forcing people to pay money to work on problems that get thrown away. Why does it become abusive when it might be useful for somebody instead?
Skilled students can make some very fine PRs when they are working on something that intrigues them enough that they get very immersed in the code.
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.
I only hope it would not be some kind of common sentiment "you have to contribute to an open source project to earn better grade or get a job". It will end up as Huawei Linux kernel "contributions" - a lot of pointless commits that are only a pain for project maintainers and bring zero actual value.
You'd hope that in a more guided environment where people are actually rated on the quality of the contributions things wouldn't be quite so bad.
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.
From the article, and up to your point. On the expected learnings there is:
...
> 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.
> 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.
We're already creeping in that direction. Everyone wants some work for free, or at a discount rate and enough people are willing to offer that in hopes of rapid advancement, so we'll keep ratcheting the value of our skills to the bottom, starting with passion projects and moving to desperate make-work hustle. Not even mad about it, it's the way of things.
I would not consider "inflicting" this on an open source project, unless I had discussed it with the maintainers in advance.
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".
On similar lines I had a course on software architecture [0] during my Master's in which students had to choose a sufficiently complex open source project and analyze it from an architectural perspective, summarizing their findings in the form of chapters to be compiled in a book [1] inspired by [2]. We were also highly encouraged to raise PRs though it wasn't compulsory. Most student groups did end up raising PRs and getting them merged, albeit most were understandably minor ones given the short timeline (~2.5 months for the entire course).
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.
Wow. The Architecture of Open Source Applications series of books has been a long time favorite of mine. So the premise of this course, that each student will produce a chapter for a similar book, is absolutely fascinating!
Thank you for sharing, and I am really excited to dig into the 6 (and counting) books the students of this course have produced.
Lovely. I hope university teachers help with reviewing the PRs too.
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.
Not even that is 100% sure. You still need to vet the tests.
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.
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.
Commenting on documentation and maybe updating is a good point yes. Onboarding docs can get quite stale.
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 have seen a few big bang 'lets test everything' go horribly wrong. Where you were unsure if the tests or the code were broken. Test code is code. It needs to be reviewed too. It is also dead easy to go too far with it (I know I have fallen into that trap more than once).
I would argue that the more pernicious result is tests that are correct and do pass at the moment they were written but are brittle, test internal interfaces and data, and generally ossify the design of the project because making any change now involves making the change and fixing the dozen tests the change breaks. It's hard to say no to those tests, because, on the surface they appear very thorough, and look brilliant on objective metrics, like branch/function coverage tools. It's only later, when every change, no matter how trivial, requires at least five or six files to be touched, that you come to realize the tarpit that you've ensnared yourself in.
On the other hand well written tests are awesome. When I have a pull request to review that makes change to a code I'm not familiar with, I always go to see the changes in tests first, to see what has actually changed on the interface level.
This has worked very well in mathematics at Imperial College, London, having undergraduates provide machine-verifiable proofs in the Xena project. They use a nonconstructive axiomatic framework (so not really "software", I suppose) in the Lean logical framework.
As a relatively inexperienced undergrad with some basic knowledge in C and python, can anyone recommend how I should go about to start getting involved in any project? I dunno how to work alongside anyone on anything useful or "real" and all I have done is making line drawing algorithms, sorting algorithms, avl trees and some basic games and simulations in python. I am kind of interested in lisp and functional programming but no experience with it..
My first recommendation is to send them to a project you use and care about. If you try to send a PR to a project you don't use, it's difficult for you to understand the jargon, the hidden assumptions, the vision, and other high level stuff that are obvious (or easier) if you are using the project.
* 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.
If you don't mind learning a new language (golang and it's not particularly a difficult language), then you should consider joining our Kubernetes SIG Instrumentation meetings (https://groups.google.com/g/kubernetes-sig-instrumentation). We're particularly well suited for people who want to get their feet wet, and despite our focus being instrumentation in Kubernetes, the kind of work that we do varies a bit, we've written hand-rolled parsers for promql, CLI tools, static analysis tools which analyze metrics across the kubernetes codebase, etc. That google group should have a calendar link on top, if you subscribe, you'll be auto-invited to our meetings :) Hope to see you there!
Students contributing to open source to get better grades should have a flag on GitHub so project maintainers can easily recognize them and treat their contributions with an extra bit of care. I've been consulted by students (and PhDs) regarding their final project (not strictly IT related) and the song was always the same. The primary objective of that person is to get uni finished. Quality or usefulness of their work is always second place. What counts is the grade they get in the end. I always felt used if not "raped". These days, I turn all students down.
I had an awesome professor for a QA course at SFU, who for a project had people choose some piece of open source software at their leisure and work on something substantial for it related to QA. (Adding a different test suite, improving the existing tests, writing some documentation, etc). There was no pressure to actually send the work upstream, but people doing so made him happy. I thought that was a good model, where you get to spend some time with a lived-in software project, you discover the wonderful world of sending patches if you want to, but in general nobody's time is being wasted.
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.
In my opinion, the Hacktoberfest controversy last year points at the opposite being true. A computing student is not likely to understand the processes and etiquette of the industry. Open Source projects are not toy projects, billions of $ depend on them running smoothly, and I don't think we should expect someone with no industry experience to have assimilated this fact.
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.
This seems like another argument for "Private copying levy" but for open source developers that create useful libraries. So maintainers would be receiving some kind of stipend and not abandon projects.
Something's clearly not working when extremely wealthy people pay less taxes than a little freelancer. But (in Europe) we are supposed to be grateful because startups across 27 countries are getting 4bn.
Sending out a horde of half-competent people with hammers in search of a nail with their degree on the line will lead to many screws being hammered in.
I can see the appeal of this idea, but what it's ultimately doing is optimising for spam.
Not the worst idea for students to learn to communicate in the open, which is a hard requirement for OSS contributions. Also the more proactive students would in any case be doing this. And making things a bit more realistic motivates people as well.
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.
>For people worried about an influx of low quality PRs on their projects, you have the right to reject bad PRs
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.
While we don't often look at it that way, each PR has a cost associated with it. If its job code and I spend an hour going over the changes, that's an hour of cost and the org is aware that reviewing PRs is part of my responsibilities and I get paid for that.
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.
I felt the same when I studied Biology, I proposed to the prof to let students write Wikipedia articles, instead of making them write so much text that ended up in a bin. It would mean a meaningful contribution to the world, + a prof was going to check it already anyway, so it would probably result in a good Wikipedia article.
I finished my PhD and am still mostly at a loss for finding notable Wikipedia articles I can contribute to. I'd fear a day when undergrads are writing Wikipedia articles with perverse incentives.
Because then the students would have to spend additional time to navigate Wikipedia culture and maintainers. That is not the course goal at all. They would also ended up fighting among themselves if multiple students ended up picking similar topics.
I agree with this, although I would hate for someone's grades to suffer because they were hacking on open source. The next ACM article should be "Why Computing Professors Should Give Credit for Contributing to Open Source Software Projects".
The ability to build any project is a strange thing you learn after a few years as a software engineer. As a jnr. dev I was completely awed at my co-workers ability to understand build/compiler errors. Well you basically get that for free banging your head against a wall long enough, and being paid for it!
Many open source projects are hard to build, especially C/C++ ones because these languages don't have a standarized package manager and a proper package ecosystem. C/C++ projects often use Makefiles which rely on bash commands. If you're on Windows, good luck. Sometimes you get lucky and there's a CMake file which can create a Visual Studio solution for you.
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.
I think if the course instructors are more or less experienced contributors and put a focus on meta-aspects such as respectful communication (valuing maintainer time), this could work. Of course, this also means that at the moment, many schools do not have teachers with relevant expertise, I suppose...
Students can make very big and positive contributions to Open Source and contributing to Open Source with a primary goal of benefiting the project is great. But if this is just a secondary goal, then I would politely say "no" to the offer.
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.
I have to say that I'm against this strategy for a number of reasons,
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.
This looks a lot like existing co-op programs, where undergraduate students are hired as (typically paid) interns and take a break from classes while they work. AFAIK these programs usually work really well, to the point where my undergraduate college became very competitive and popular solely because of its co-op.
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.
A lot seems to turn on exactly what kind of open-source project might be used. The author refers to a letter from 15 years ago:
> 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.
Students approach the course and its assignment with trepidation and complete it with jubilation. Ensuring students can make meaningful contributions to an open source project requires balancing their inexperience with the fast-paced sophistication of modern, open source software development.
I'd go one further and have dedicated courses on open source, its history, evolution, business models, challenges etc.
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.
How do you recommend a student contribute to an open source project when many people don't even accept pull requests on their basic github repos? I had a teacher that tried this and it backfired immensely. Basically every student wasn't able to get one so my instructor had to change it last minute and just make us do a coding project in a different language.
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.
Sure, every PR will not get accepted, thats fine. It would be best if the instructor helped students curate which projects is good candidates, and motivate students not to choose only one. The advice in the article for how to choose projects is really good imo:
- 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".
IMHO students will more benefit from studying/reading open source software code than trying always to contribute. University is a big time commitment with coursework, exams, labs, which is unavoidable to graduate.
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.
It isn't the education system's job to produce model employees. Nearly all the "modern skills" mentioned in the article all squarely fall under the moniker "industry knowledge", which is... the industry's job. Those that don't fall under the umbrella of maturity, which only experience can teach.
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.
Imagine this: A name for a new type of application is coined that crudely described would work like this: a group of students pick a simple but very useful application and write it from scratch, it is to be maintained by them for the duration of their career and should be proudly listed on the resume. Some will be to busy with their career to contribute much while others will have time to expand the project.
What seems to give the best ROI, in the current climate, is to read and understand Data Structures and Algorithm books from cover to cover, and grind standard leetcode/hackerrank problems.
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.
I paritally agree with the bottom line, but completely disagree with the author's business-and-market-focused outlook.
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).
If instructors are going to ask their students to do this, they need to make sure they are doing so meaningfully.
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.
I don't agree with this argument. Open source contribution is a fine art. Half-baked pull request is a nightmare for already-strained code reviewers. It does not help open source community as a whole.
What ever happened to exploring computing through just building small, cool, things? Maybe I'm old now, but this trope has been parroted here and elsewhere as a panacea. Need a job? Contribute to open source for the CV experience. Need something to do? Contribute to open source.
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.
> What ever happened to exploring computing through just building small, cool, things?
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.
> 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.
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 :-/
You can't leave this industry because frankly no other industry will coddle it's overpaid, dunning Kruger workforce like software. Go to a law firm or a plumbing gig and complain that their task management is literally the hell and see what happens.
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.
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.