Slashdot Mirror
Open Source as Programming Exp. for College Students?
texatut asks: "With the computer industry in a slump, many college CS students nearing graduation are looking at pretty meek prospects. While 'formally' educated, few actually have concrete experience dealing with development of software. Many would like to have something concrete to put down on their resume or application to graduate school. However, starting their own project is a hard and time-consuming task. Obviously, the Open Source community is a perfect place for us to get our hands dirty. My question is, are there any resources that can help people with varying levels of experience connect with development teams in a way that would benefit both the project and the students?"
As someone who has hired a large number of software engineers in the last decade, I'd like to give a little perspective on this issue.
It is a very difficult market for engineers. There are far fewer companies than there were 24 months ago and those that remain have cut hiring right back. When I can hire I get flooded with applications, many of which are from people with a lot of relevant experience. A newly minted graduate is going to come up short against someone who has been building commercial software for 5-10 years.
Getting on a successful open source project and showing you can make a real contribution is going to help you stand out from the crowd. Choose your project wisely - if you want to be an operting system engineer then getting on board with one of the core Linux projects will be much more impressive than building yet another Quake level editor, and vice versa. You'll need to have people on the project who can vouch for you and the contributions you have made. The higher the profile the project and reference it provides you the better: having Linus tell me what a great job you did on the kernel extensions you built will help you a lot.
Bear in mind that to really make an impact on a substantive project, whether its commercial or open source, is going to take a while. Spending a week adding a couple of printlns isn't going to cut it.
Be aware that a good commercial software engineer has more than just technical skills. You need to be able to work under pressure, to a deadline and in a team. Just being a great hacker isn't enough. Use your time to demonstrate that you have these skills in addition to your coding abilities. One of the disadvantages of an open source project is that many (not all) of them aren't run with the degree of close teamwork and tight deadlines that are the staple of commercial software development. And of course, the one's that have established teams working on them may be the hardest for a newbie programmer to get into.
Yes, its rather Catch-22, but it takes a while to build up the reputation that will carry you into the better companies, roles and projects.
Sailing over the event horizon
I actually have always been a geek and programmed heavily before actually getting a job. In fact, I had more programming experience than most people at the first job I worked on.
But that didn't make me more productive. Working on a team in a production environment is very different than just programming on your own. I have always been told to leave Open Source stuff off of my resume. That doesn't mean you can't use it to refine your skills. I learned most of what I know on my own.
Now, by the same token, most college curriculums suck as far as CS is concerned. Realize that if you only rely on college to teach you how to program, your essentially going to an employer without knowing how to program.
I don't want to discourage OS programming, but do not do it with the expectation of having it help you get a better job. Do it because you either believe if in or because you really enjoy it. The last thing the OS community really needs are people who are just looking for resume builders (especially ones with little useful experience). If your really concerned about getting a job, get a co-op or internship.
int func(int a);
func((b += 3, b));
>>Income from Open Source means Consulting
>>and Services.
in other words, make your software so shitty and unreliable that people need to pay you so they can keep it functioning? And people bitch and moan about MSFT's subscription policies.... this is the same thing.
Here's a real world example:
The last company I worked for, we produced a very high end, specialized application with a limited user base (it is used for doing movie special effects). When we launched a new product recently, it was the work of about 40 developers, working full time for almost 4 years. That doesn't count people writing documentation, QA testers, support staff, the people that clean the toilets, etc etc etc. All told, probably between 150-200 people. So lets *conservatively* estimate the development costs at $15 million (and that is VERY conservative).
Now this work took FOUR YEARS. So when it comes time to release it, we should just give it away and expect and there will 'magically' be money to pay the rent and food for all these people? Cmon already. Should they survive on happy thoughts and good wishes?
This shows the mindset why Eazel was such a beautiful failure. They were paying these developers to produce work and had NO way to generate money.... they didn't even sell t-shirts. Yes it's very altruistic and benefits the community, but sooner or later it's going to flame out because it can't last forever - the money will run out.
If people want to give away their work for free -- more power to them. I write code for a living 9-5. And i also produce open source code after hours that I give away. And that works fine. I don't see any differentiation between giving away code you write and going down and volunteering at your local community center. People can definitely benefit from it, but don't expect that it's going to pay your rent. And don't declare that there is no right/future in charging for your work.
Software costs money to produce - you can't debate that. If you don't want to pay for your software, you're free to use the stuff that people give away and thats good. Same thought process that you don't have to pay for your groceries - you can go to a soup kitchen. Thats all well and good, but you lose the right to complain if you don't like whats provided.
I'll give you an example. We PAY to use Qt for our development. Why? It's an excellent toolkit. Sure we could use gtk for free --- but for the headache that Qt saves me $2000/year is a BARGAIN.
Same with compilers --- the open source crowd loves gcc. Hate to step on any toes but gcc is pretty sucky. Yes it is good for retargeting code, but the performance is terrible. To build the latest release of Qt on Win32 took about 45 minutes. On linux (exact same hardware) took 3-1/2 hours with gcc. Over the course of a year, the $200 we spend on Visual C will more than pay for itself. GCC will be going into the crapper as soon as somebody produces a good fast compiler for linux.
Closed source isn't dying - it's doing very well. Don't be a hypocrite/bigot. There's room (and NEED) for both commercial and free software in this world.
in other words, make your software so shitty and unreliable that people need to pay you so they can keep it functioning? And people bitch and moan about MSFT's subscription policies.... this is the same thing.
.... So when it comes time to release it, we should just give it away and expect and there will 'magically' be money..
No, in other words, make your software as beautifully clean and high quality as possible, basing as much as you can on existing Open Source software and extending as needed. You would not believe how many people are paying out the wazoo to keep *proprietary* software functioning. I'm proposing to do a better job on both ends.
The last company I worked for, we produced a very high end, specialized application with a limited user base..
I'm not proposing a solution to every situation. Nor am I talking about building specialized software from the ground up. In your case, however, it still doesn't mean that proprietary code is needed. One option for people (your customers) with specific needs is to form a sorta co-op group to develop the software they would need--in this case, movie effects software. Seeing as how you have a small user base, this is fully possible. It just requires planning and coordination. Why would your customers do this instead of buying proprietary software from whatever company you work for? Because it's cheaper for them if executed correctly. Nothing I'm advocating has anything to do with altruism or making programmers work for nothing. Yes, I fully agree that the Eazel people were a bunch of morons with no business model.
GCC will be going into the crapper as soon as somebody produces a good fast compiler for linux.
I agree that GCC needs work, but it's certainly not going away and I don't think it's quite as bad as you suggest. Qt takes nowhere near 3-1/2 hours to compile with gcc on my machine, and it's just a single-processor 1.4Ghz. Athlon. What matters ultimately, is the performance of the binaries and you nowhere mention this.
There's room (and NEED) for both commercial and free software in this world.
There is only need if people create the need--those people being customers who aren't aware of the possibility to get the software they need for less money by hiring either Open Source consultants or by organizing a sort of co-op. I'm not saying it'll happen tomorrow. But it very well could happen as more Open Source projects reach 'critical mass'
Being apart of the Clarkson Open Source Institute can earn you actual credit hours, we have projects that we do for the community and for the school. Linux training and tutorial sessions that provide newbies with a jumpstart into running linux. We also have several software projects underway that will help the campus and Open Source community at large. We provide a CVS server to the campus with tutorials on how to properly use CVS, as well as a central meeting place for recruiters looking for linux talent and others interested in linux in general.
The students here are not doing any of this for money, rather just fun and experience, I have a great time hanging out with the guys programming into the wee hours of the night. You're more than welcome to check out our webpage that explains a little about COSI (Clarkson Open Source Institute)
I think the idea of harnessing students to help out with OSS projects is a great idea. Now a lot of people on this thread have argued that OSS projects may be unsuitable to student involvement for various reasons. I would argue that while that may be true, the project leads running OSS projects should do what it takes to get students involved.
If you get a bunch of students working on OSS in school, there's a decent chance a few will stay with OSS after they graduate. This is the same concept used by industry to justify summer student employment programmes. And it works. You want to attract top talent to your organization whether you're for profit or not. That should extend to OSS. Why not compete to get the best minds working on your project in the future?
Now that being said, it does require some effort. Having hired summer interns in the past (I run a small IT dept), I am aware that you can't just expect them to be productive when they show up. It requires extra planning and patience. You have to take time to explain how things work in your organization, how they can help and what they need to do. But invariably, this patience is rewarded once they get on their feet and start being productive. Typically these students do the work nobody else wants to do, but having been one myself at one point, I can attest to the enthusiasm with which this work is met. As a student you are starved for real-world work, and working for any organization that isn't school seems exciting.
So I urge project leads to seriously think about how they can encourage students to join their projects.
If i were teaching again at a university, i would run an open-source project as follows.
1. To do an open-source project requires 2 semesters (1 year) of work. There just isn't enough time to do something worthwhile in 1 semester. Therefore, to do a project with me, you'd have to agree (in principal) to sign up for two semesters of independent study.
2. In the first 20% of the project, the student would pick a topic area and write a thorough survey about what is available in that area. To save time, i would make available good surveys from previous students (if any). The survey would also contain a proposal for how to write something new and/or innovative in the domain.
There are many tired over-worked areas in computer science, such as real-time OS kernels, or C compilers, etc. To do a project in one of these tired areas, you'd have to present a really honking great idea in the first week or two of the class in order to be able to work on these dead topics. I would have a set of 10 canned idea areas but would not turn to these until the student had failed twice with their own ideas.
2. In the second 30% of the time, student would write a spec and pull together a development environment, including writing any software or hardware tools or developing ideas for any testing tools needed to complete the task.
3. Last 40-50% of the time is devoted to writing the code.
This is sort of what happened with my B.S. thesis in 1984, and it became a pretty successful open source project (the PC/IP multitasking TCP and SMTP).
This is a very hard thing for a faculty member to support because there is a lot of risk in step (1) that the student fails to find something interesting, and becaue of the need to hand out a grade at the end of the first semester, and allowing for the possibility that the student drops out of school, transfers, gets into a car wreck, hates my guts, or whatever, and gives up.