Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Open Source as Programming Exp. for College Students? 420

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?"
This discussion has been archived. No new comments can be posted.

Open Source as Programming Exp. for College Students?

Comments Filter:
  • Check sourceforge (Score:4, Insightful)

    by nate1138 ( 325593 ) on Tuesday February 26, 2002 @07:08PM (#3074266)
    You could always check sourceforge, they always have listings for tons of projects that need testers, coders, documentation folks, etc. Good way to get your "hands dirty" and help out the community.
    • by hillct ( 230132 ) on Tuesday February 26, 2002 @07:27PM (#3074443) Homepage Journal
      SourceForge is a good place to start if you wanted to get involved in OSS development, but I would question whether such experience is truly valiable in the job market. While it looks good on a grad school application (maybe) it really doesn't demonstrate an ability to work in a close knit team, to meet deadlines, to solve problems, enguage in project management activities (in the more treditional sense).

      It's true that working on an OSS project may give you experience in the actual work of software development in that you will be producing code, vary few of the software development skills msot companies look for are really developed or evaluated in the OSS world, unless you think a hiring manager at any company would actually be influenced by your code-fu rating as listed on SourceForge or Avogado. While in the strictest sense it may allow one to sharpen one's coding skills, I seriourly doubt whether it would significantly effect a hiring decision at any large company. On the other hand, if you want to start building up a consulting business it could never hurt to say you were a lead developer on OSS projects A, B, and C.

      --CTH
      • by Macrobat ( 318224 )
        You may be right about what SourceForge or OSS development doesn't add to your resume. Realize, though, that nothing that isn't a job itself exactly replicates a job. What work on an OSS project demonstrates is that you are self-motivated (because nobody's forcing you to do this), that you work well with people even if you don't see them day-to-day (because you are working on a distributed project) and that you have the ability to finish a project and create a working piece of code. All in all, an intelligent employer should recognize the benefit.
      • It also depends on the work done of course. My company employs a few driver maintainers. Why? Because our products require good knowledge of system internals. While driver writing doesn't guarantee such knowledge, it's usually a good sign. Especially if it works.

        Companies always are looking for coders that can actually make things work, and unfortunately a cs degree does not guarantee that. Then again I do not work at a huge company, nor have I any wish to.
      • When I graduated and was looking for my first job, the primary concern of employers was my work experience. They didn't even count my part-time job programming at the University.
        Working on an open source project would probably allow the graduate to get a lot of useful nuts and bolts experience, but that is not something that they could put on a resume that anyone would care about (unless they were going to work at Red Hat).
      • It may not be useful for full-time, on-site, permantent employment. In my experience there, noone cares what you did if you weren't paid to do it.

        However, on the other side of that, open source experience can be very valuable when seeking off-site, outsource development work. When I am looking for people to hire for that kind of work, is it *extremely* useful for them to have some code they can show me (open source!) so I can see what kind of code they write. If I am comparing developer A and developer B, and A says he wrote some great stuff but can't show me a line of it, and B says I can go look at his code, it's a lot easier to hire B.

      • I don't know about that. At most of my interviews, I've brought up my Phish Stats website [ihoz.com] as a way of proving that I know how to write perl. It usually helps a lot in showing that I can write a decent web app.
  • by Anonymous Coward
    If the student is interested, just shoot the lead dev an email and he's in, right?

    However, my advice in these troubled times is to continue having Ma and Pa keep footing the bill for education and get a Master's degree. When the tech slump ends, the student will be that much better off with more experience than he could shake a stick at. Another bonus is that his starting salary will likely be higher than a fresh recruit's.
    • That's actually pretty good advice.. I know several people that either aren't ready to enter the work force or are having a hard time finding a job, (hell even people I know with 4.0's are having a hard time finding jobs atm) are either going back for a 2nd undergrad degree or continuing on for masters in CS.

  • Most projects would love to see more help--simply find lead developers or maintainers and say hello. Or send a message to the project mailing list and ask about projects, suggestions, etc.

    There are always features that have sat on the back burner, code to be cleaned up, etc. And of course I can tell you that as an undergrad, you often have more time to code.

    -Geoff
    • When I was out hiring for our last open position at work (it's filled now ... don't send me email) I had been hoping to find someone with experience on an OSS project. That actually would have been my ideal, as I believe this offers real-life experience in a way that lets you dip your toes into the water on your own time.

      But alas, that didn't happen. Maybe next time I need to do hiring...

      If you want a suggestion, I would recommend helping out the FreeDOS Project [freedos.org]. The FreeDOS Documentation Project [sourceforge.net] (FD-DOC) lists a few of these suggestions [sourceforge.net] for helping out with FreeDOS:

      - Take any of the open projects on the FreeDOS Software List [freedos.org].

      - Contribute to FreeCOM (our command.com) or the FreeDOS kernel. It's not as hard as you would think, especially if you start small by applying some bug fixes.

      - Apply some contributed patches to Freemacs (a GNU emacs clone for DOS). The patches are already there .. you just need to apply them. This should be fairly easy!

      - Patch an existing program to use Cats [freedos.org] or MSGLIB to support internationalization. It's not hard .. just read through the docs and you'll be fine.

      There are other things, too, but if you are looking for suggestions these should get you on your way. I'm sure that any sane employer will look on this as valuable experience, as you will have demonstrated the ability to work with others on a project, and contribute to the code.

  • Yes, browse sourceforge and freshmeat for interesting projects that need help.

    Rarely do you find stuff there that isn't in need of some kind of help. Sometimes, all they need a a little design/analysis work, sometimes they have modules to code. Check it out, you might just make someone's day.
    • by room101 ( 236520 ) on Tuesday February 26, 2002 @07:14PM (#3074323) Homepage
      Sorry to reply to my own post. But really, the secret to getting started in the OSS biz (yeah, biz, that's funny....) is to be willing to really get your hands dirty. That is, be willing to fix bugs and such. There are too many people only willing to work on new code. (yes me too) Many projects have too many cooks in the kitchen, too many "neat" little side projects that don't fit into what the main project is all about. Also, they add too many features and the same bugs are listed in each release.

      Talk about really making the project lead's day, as for a prioritized bug list and get cracking on that.

  • by www.sorehands.com ( 142825 ) on Tuesday February 26, 2002 @07:10PM (#3074287) Homepage
    The problem that some employers have with new grads is not just the lack of experience. It is also the lack of experience on large projects. Writing and maintaining a 2k-3k utility, even at a job, is very easy as compared to dealing with a small portion of a 250,000 line program.
    • There are some large OSS projects [mozilla.org] that actively encourage feedback and bugfixes and so on. Even contributing small bits to them or minor bug fixes would show some experience in being able to deal with isolated portions of enormous programs.
    • Hm. I basically agree with you, however I feel a few points must be made:

      Coding one's own app from start to finish entails design, project management, coding, testing, quality assurance, etc. One person must play the part of an entire team. Programmers tend to be geek-inclined, therefore of higher-than-average intelligence. Take this highly proficient programmer and plop them in the middle of a group.

      All of a sudden, the programmer who is used to overseeing their own projects from conceptualization to realization, they're plopped down in an environment where they either have to learn to "put up or shut up". The project managers are in charge of how things are done, and for a "new monkey" in the pack of typing monkeys, it's hard to make your voice heard no matter if you're right or not. FRUSTRATION.

      For those who 'play well with others', making the leap into this environment of "distributed responsibility" won't be a difficult transition. However, geeks tend not to fit into this category. Can you name one single geek who is perfectly content to exist within an environment that must remind many of the whole "How many monkeys with how many typewriters..." question?

      Hiring new grads of any "group" is a hard call to make, when the new grads consist of a group that is largely different than the majority of the population (ie: geeks) it's an even more difficult decision. Let's face it, we're a highly opinionated/unusual group and it's reassuring for employers to see past work experience on our resumes. That way they at least feel prepared when we start getting into battles with the project manager about releasing software labled as version 9 when it is really more along the lines of .9.

      No one wants the responsibility of breaking the news that this is a flawed world we live in, and that sometimes, yes. Sometimes we must use a WYSIWYG editor.

      -Sara
    • And, well, make sure that 250,000 line program is written in something marketable like Java, C or C++. Your offers will diminish if you're playing around with non-corporate languages like Perl. Or you'll be forever banished to maintaining 5 year old CGI scripts...

      Go ahead, mod me down. It's true though...

      -Russ

  • Senior Design (Score:3, Insightful)

    by Dr. Bent ( 533421 ) <ben&int,com> on Tuesday February 26, 2002 @07:10PM (#3074291) Homepage
    Many 'Senior Design' (aka Capstone) courses are ideal for open-source projects. You gain valuable experience, contribute to the open-source community, and get course credit! Plus, sometimes these projects translate into actual jobs when you get out of school.

    Many professors will let you work on O.S. projects if you find one than can be completed in the alloted time, and if it's relevant to some of your other coursework. Of course, this depends greatly on the professor, but you'll never know if you don't ask.
  • Academic Research (Score:3, Insightful)

    by slcdb ( 317433 ) on Tuesday February 26, 2002 @07:12PM (#3074310) Homepage

    Although, not all students will get positions on research staff, and it usually doesn't pay all that great... research staff positions are available at most universities.

    Plus, (at the risk of getting flamed) most commercial software companies will give more credence to someone with a research background than to someone who worked on the latest Open Source project.

    • Plus, (at the risk of getting flamed) most commercial software companies will give more credence to someone with a research background than to someone who worked on the latest Open Source project.

      That's arguable. The case where it is clearly true is where the company is working in a highly technical field that your research is directly relevant to. For example if do a PhD on highly efficient 3D rendering algorithms you will be of great interest to several games companies. If your research is in number theory I know several financial software firms who'd love to talk to you.

      But, if you have done research in graphics, you probably aren't going to be interesting to a bank.

      A research background will probably make you highly attractive to a very small number of specialized software companies. Good experience on a successful open source project is likely to be more attractive to much larger number of general software development shops.

      Finally only take a research position at a university if you really love the subject you are going to be researching. You must have a vocation for this work. Its badly paid, you'll get little recognition and you will need to be very good at what you do. Its not for the faint of heart.
  • by prockcore ( 543967 ) on Tuesday February 26, 2002 @07:13PM (#3074315)
    "Frank, sourceforge needs more hits... we'll need to buy a few banner ads"

    "Nah, I've got a better idea, why not post an Ask Slashdot question where the most obvious answer is 'sourceforge'? Like 'where can I find a bunch of open source developers?'"

    "Great.. I'll get right on it.."
  • Everyone is in computer science for the money these days.

    We tried to get an Open Source Development group together at my school, 5 people showed up. One guys was like, "With Open Source we can go download everyone's source code and resell it for thousands of dollars. Its work free!" Yeah, ummm....I think he kinda missed the boat...

    Too many colleges are indebited to M$ and so that mentality is pervasive in Colleges and Universities. I'm sure a good portion of undergradatues across the US (I can guarantee that's the case at my school) haven't ever been to Sourceforge.

    • Firstly, as much as I dislike MS, I hardly see how you can blame MS for this mentality (as you see it).

      Secondly, very few universities are indebted to MS. Try backing it up with some facts. I'm certain you'll find that any money MS gives them, in any reasonably arguable form (whether that's free/reduced licensing or what have you), is much less than 1% on average.

      Thirdly, you are assuming that anything that is not programming for money == "Open Source." Open source is just one sort of "free" ideology and its not an ideology that everyone happens to agree with. For instance, someone may choose to develop code for a non-profit and/or at a reduced salary since they believe that open source is largely a waste of time. i.e., it's not "all" about the money.

      Lastly, the attitude that money is unimportant is generally afforded to the few that have the luxary of not working. Try this when you get out of college and keep it up when you're trying to raise a family, just don't complain to others that it's not fair that you're not making enough money to lead a comfortable life.
  • by sphix42 ( 144155 ) on Tuesday February 26, 2002 @07:18PM (#3074358) Homepage
    DISCLAIMER: I'm not currently looking for more help.

    While my site (db.etree.org) is not (all) open source, I have mentored a student (hey Eric) while he developed code now used on my site.

    His school assignment was designing and implementing something from start to finish. He asked to work on top of the work (adding new code) I had done as his project. I hooked him up with a shell and CVS and we had quite a few phone conversations where (I hope) I taught him quite a bit.

    We both benefited from the relationship in the end. Eric contacted me directly with a plan to enhance my site. This method worked very well for us...that is, someone looking for experience came up with a plan for an existing project and asked to do itand, in return, I mentored him.
  • I believe it's a great idea.

    here [unmaintain...ftware.org] would be a great place to begin.

    Could look great on your CV and benefit the OS community as a whole.

  • by nomadic ( 141991 )
    If there are no jobs, there are no jobs. How is making yourself better qualified for jobs that don't exist helpful?
    • umm, the economy is cyclical.

      That means that in a year or two things will be different. True, things could get worse... though I doubt it. We're suffering from deflated exuberance caused by a lot of VC being placed behind shoddy business plans, combined with the psychological impact of Shrubya's comments right around the election "We're going to have a recession", topped off with the effects of a major terrorism strike.

      Most of the unfit companies have closed their doors, but some of the stronger ones have survived and have diversified their business plans to make them stronger. W has come around and said that we're having a recovery. Finally - we've routed the Taliban out of Afghanistan, and unless they've massively reorganized in another part of the world, I doubt that we'll see many more large terrorism strikes that catch us by surprise. We're on guard now.

      The big uncertainties are whether or not W will decide to invade Iraq to finish the job his daddy didn't finish, and whether the rest of the world gets pissed at the US for it, on top of snubbing the Kyoto and ABM treaties.

      Do I need to spell it out further? Right now there aren't many tech jobs out there. If you don't have a job you essentially have 2 more choices:

      • A) find another field
      • B) huddle in your bunker and refine your skills while waiting for the cycle to swing back up.

      I don't know about you, but I love working with computers, and want to continue doing so. Do you think that Olympic athletes give up skiing just because they're no snow outside?

  • Assuming we're talking about talented coders who have knowledge of computer science but want experience, some logical places to start are Linux Kernel Mailing List, the various monolithic BSD projects, Debian and WineHQ. These are two ongoing open source areas where new blood is always welcome and the best of open source coders gravitate.

    Others will suggest starting with sourceforge, but in my experience a young coder doesn't want to pick somebody else's ideas and run with them s/he wants to find a way to test out new ideas and see if they'll work. Avoid isolation, try to find a team that has an agenda but permits arguments and discussion. Open source is a must, because you're always free to veer off on your own development tree if your ideas diverge from or are preempted by the requirements of the project.

  • It seems that one of the repeated claims about open-source software is that the best developers are sort of self-selected in a meritocratic system. However, throwing college undergrads at the problem certainly isn't going to garner a whole herd of the "best developers" out there. In fact, most of them will be downright awful.

    So, would this be useful, or would it end up throwing a lot of buggy, fragile patches at software and overwhelming the lead developers?
  • 1) Start small. No kernel hacks yet, you can be more productive on smaller projetcs;
    2) Abstract coding, that means try to learn/develop/help projects that are root of others. Like engines, classes, libraries. I know this somehow conflicts with number one but you must find the balance;
    3) Do it right. Document, comment, test. No half steps please;
    4) 'In-loco' development. Try to get a job in any company. Meet the managers to learn how to overcome this difficult part of our lives;
    5) Share with other students. Recentely (er... 90 and above) developing an app has become more and more a team activity;
    6) Block Slashdot's webpage access;
    7) Write useful stuff, for you daily activites. Like a tool to perform any desirable action at the school network, to administer your books, to share knowledge better (Personally I would love somekind of P2P Knowledge-tree sharing system);

    Well, that's it for now.
  • by gwernol ( 167574 ) on Tuesday February 26, 2002 @07:33PM (#3074482)
    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.
    • 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. I'd like to stress this point further. Being a hacker isn't all you need in most programming jobs, but it is the most admired trait in open source developers. It's fairly rare to find an open source project that will teach an individual when it's appropriate to make compromises in the workplace. Open source projects rarely have the individual pressures or conflicting goals found in commercial projects. Because many (especially small) open source projects start as academic exercises and many are designed for use by other hackers, the programmers can more often choose the elegant solution. On top of these compromises are the social ones you eluded to... programmers in the workplace need to work closely with others. Many times, with people who aren't qualified for their jobs (Dilbert is real). Although open source projects teach a lot, they won't replace real experience. There is still a lot to be said for the guy who's already had the ambition beat out of him.
  • When making hiring decisions, I do not take anything on the resume seriously. I have found there is no relationship between quality of resume and quality of coder/employee. [However it usually must get through resume screeners who dont know anything about programming, so make it look sharp!]

    Working on a large free-source project would probably be very good experience. However, working on your own can also push your boundaries. I suggest doing both. Best of all is to get a co-op or internship at a real software company.

    In an interview I would ask you specific programming questions which should be simple and obvious for you. If you pass that, I will ask you more difficult obsure questions that will (hopefully) require you to think on your feet. Failure to pass this interview will not get you hired no matter how good your resume looks. If you pass with 'flying colors', you will be hired no matter how skimpy your experience.

  • The only way to become a good programmer is to write lots of programs so in this respect I suppose writing code for an OpenSource project is just as good as any. From a corporate job marketability perspective it's virtually useless however. Most employers will not know what OpenSource means and will probably think you're some kind of communist code hippie if you try to explain it to them. Best leave it off the resume unless you know the reader will appreciate it. Rather than procrastinate working on another worthless runlevel editor for Joe-Bobs-Great-But-Kinda-Slow-Desktop-Environment, you would be much wiser to make your skills available to a professor writing ulitmately useless code. Right now, students should be worried about grades and diplomas, certs, and boring stuff like that. It all comes down to peices of paper folks. Don't fool yourself into thinking your enthusiasm for writing Free code will help you.
  • If you are a CS student, don't you have projects at school? Some of the projects are pretty complicated (at least, at my school), and you should be able to show that to potential employers. Of course, some of the projects are team work, and there are always people who don't do anything. But you make sure you do your part, and know all the other parts too, even if you are not the coder.

    Make sure you have the design documentation, QA test plans, etc, when you show it to potential employer. And make sure that you write pretty code (ie. readable code), and good comments. Yeah, and put your name as the main coder in the source code, if you are the main coder. Also make sure you know how the program works internally, and know how to explain. I got my first job by showing the source code of a JPEG compression/decompression program (it was a solo project) I wrote. The manager liked my "clean" coding style.

    When I graduated, the only people who got a job were: those who can code and explain in clear terms the projects they were working on, and those who are straight-A students (even if they were not very good coders). The first kind got jobs at small companies, and the second went to big companies where they spent the next 6 months in training.
    Everyone else in between didn't get a job.

    I was good student but not straigt-A, and I went to a small company. The first day there, I was assigned a desk, and a pile of PC components on it, plus a pile of floppies containing the OS and dev tools. In the afternoon, the manager came to ask how was my development environment setup (I mean, the RCS/CVS and shell scripts part, not the hardware assembly and OS installation). One of my classmate went to IBM. When we met 9 months later, he was still in training, and had not wrote a single line of code yet.

    At our school, there was a joke running around, stating that if you don't know how to code, you go to graduate school.

    • Projects for CS classes typically are much smaller scale than most of the systems you will find in the real world. It's very hard to give students a taste of large-scale software development in a university setting. There are too many issues: how do you evaluate the work, how do you set up the project, how do you make sure the students learn something meaningful, etc etc.
  • My own pointers. (Score:5, Insightful)

    by Christopher Thomas ( 11717 ) on Tuesday February 26, 2002 @07:43PM (#3074553)
    Here are my suggestions.

    I've been on both sides of the software company interview table, and I've dabbled in open source (produced a few patches and some documentation for the LML33 video capture card project).

    Things the interviewer wants to see:
    • You program for fun.

      This is the difference between someone who knows how to code and someone who's just been slogging through coursework. Have a couple of pet projects to talk about, even if they aren't that fancy. Bring a disk with code and executables for extra credit.

    • You've worked as part of a team.

      This shows that you can follow directions and cooperate with others. Your Software Engineering course project got your feet wet with this. Go join an open source project with more than one member, and get a patch accepted.

    • You've supervised other people.

      This shows that not only can you work in a team, but the supervisor trusts you enough to put you in charge of people. If you've done this, it's a big bonus. A letter of reference is *vital* for this, though.

    • Letters of reference.

      Any time you're a part of a team, get your supervisor to write you a letter of reference saying that you worked there and that they were satisfied with your performance. Anything above that is a bonus for you. The letter must contain contact info for the supervisor and the company/OS project/whatever you worked for [so the interviewer can track these people down].

      Get these letters *before* you leave the project. Ideally just after you've finished doing something substantial. Letters keep well - and it's a lot easier to get them midway through your tenure than a few months after you've left.



    Between all of the above, you'll show that you actually know how to use what you've been taught in school, and that you can work with others, and that you did a good enough job that people don't mind giving you a recommendation.

    Tips on projects to pick:
    • Pick something you're interested in.

      This is a no-brainer. You're not going to be enthusiastic about something you don't care about.

    • Pick a project you know something about.

      If you aren't at least somewhat familiar with the kind of work being done in the project, you'll do more harm than good. If the project deals with a cool subject you'd like to learn about - spend a couple of months learning about it and writing your own toy projects before jumping in and helping. Your future teammates will thank you.

    • Pick a project that's made some progress.

      Most projects that are in the "idea" stage or that are just skeletons, stay at that stage. Grab a project that's already moving.

    • Pick a project with at least two or three other people working on it.

      This helps reduce the effect of personality clashes, and has enough people present that there's a team to show teamwork with (that's what the employer wants to see).

    • Pick a project with fewer than a dozen people working on it.

      If it's a small team, you can make a difference, and so you're more likely to get a letter of reference if you do a good job. A large team probably won't care, and may not even remember what you actually did. Either way, it'll be harder to squeeze a letter out of them.

    • Lurk on the project mailing list for a while.

      You need to know what's going on in the project, who the people involved are, and what they're like. Sign up to the project's mailing list (any worthwhile project will have one), and read quietly for a month or so. After the first couple of weeks, maybe try asking an intelligent question or two. *Then* offer to help, if you still want to join this group.

      This is time-consuming, but you can be browsing several mailing lists in parallel. Make sure you save the messages for future reference.

    • Remember that testing and documentation are valuable too.

      Both of these make some developer's life easier, and they'll thank you for it. If you're good at finding bugs or writing up how code works, do so, and make sure you're thanked in writing.

      If your documentation is decent, your name will live on for as long as that documentation is valid (I got LML33 questions for months after leaving the project).



    Follow these pointers, and browse freshmeat and sourceforge industriously, and you should find a worthwhile project that you enjoy.

    Good luck.
  • While I won't argue the value of working on open source projects, do seriously consider seeking an internship (paid if you can get it, unpaid if you can't - it's hard to turn down someone who wants to work for free).

    It's a big plus to me when someone I interview has demonstrated that in addition to being able to code, yes, they can exist in the 9-to-5 flourescent light world without losing their mind. Not everyone can.
  • As far as I can tell, most of the people who have made significant contributions to Mozilla, who weren't already a Netscape employee, whose contributions were high quality and who appeared to be a reasonable person has eventually at least been offered a job interview at Netscape, and many of those people are now working there. (It's one big reason why Mozilla doesn't have as many "non-Netscape" contributors as you might expect.)

    If you think about it, it's a no-brainer from Netscape's point of view. They get a chance to hire people who are pretty much known quantities, who already know most of the codebase they'll be working with, and who for whatever reason are interested and motivated to work on Mozilla.

    Things might change if Mozilla gets flooded with "wannajob" people of course... hasn't happened yet.
  • by gewalkeriq ( 263780 ) on Tuesday February 26, 2002 @08:06PM (#3074734)
    If I was trying to help a college student
    get a real job. I would suggest ...

    Get some real coding experience, preferably paid, but volunteer if needed. People pay more attention to paid experience. Nothing wrong with open source for experience (its just another form of volunteer work), biggest problem compared to other vol. work suggested below is that it does not have a local presence, but it tends to use more hot skills than some of the local work.

    Call local software companies and and if you can have any fixed-bid job that can be done off-site, and do a good job on them, including being done on time.

    Volunteer some programming work for the church, or the local youth center, or whatever you prefer -- just make sure it's real programming experience. Do a good job, and have that person vouch for your work. Some volunteer organizations are run by people with lots of solid business contacts.

    Join some local programming user-groups to match your interests. There is likely to be Linux, Windows, Java, C, Delphi, etc. groups in your area. Volunteer to help, make presentations, etc. Make contacts with these people.

    More generally ...

    Be flexible, if the job involves knocking off some VB screens, do it well. The boss remembers that you did a good job, more than he remembers you did a good job with some VB screens.

    Learn more and work harder and faster than the next guy. Listen more than you talk.

    Be friendly. Brush you teeth. Use mouthwash if necessary. Take regular showers. Wear clean clothes without holes.

    Use common sense.

  • Working on the education side (Engineering) of this discussion, I have something to add.

    Students come to me all the time in their senior year telling me that they don't know how to do anything and don't know what they should do for a job.

    The reality is that they do know _how_ to do a great many things, but we don't have time practice all of them in the structured environment of a course. There's so much for an engineering student to learn to prepare them for employment. Most employers will take a new student and provide additional training in the specific area that they'll work in and it's our job to make sure that they have a good foundation to add to. (Training has been less common in the computer field the last few years compared to Civil, Mechanical, etc. but my guess is that'll swing around pretty quick here.)

    The best thing for students to do is to take the initiative (that's important right there) to use their summers and free time to pursue internships, or participate in projects like open-source ones or maybe volunteer on a public service project.

    What we cannot reproduce in an academic environment is the real-world. (We can on a small scale, but not for 2,000-40,000 students...) Students need to understand that the diploma is NOT the whole package, just a typical element of the package.
    • A typically worthless part of the package for those of us who do learn on our own, unlike the graduates that never take the time to really develop any skills past what is required to complete the assignment at hand.

      A lot of the time, my coworkers come up to my office and see what I am doing, and ask me what it has to do with anything we are working on. Sometimes it doesn't, not right away. Then in a few weeks when I pull off something amazing, they never can figure out how I do it.

      There are two types of people, the ones that work for themselves, the ones that work constantly to increase the stock in their "personal toolbox" and the kind that just figure out how to do the job at hand. IMO, the former has a much better chance at really getting things done, and usually higher education is a total waste of time for those types. Me included.
      • There are two types of people, the ones that work for themselves, the ones that work constantly to increase the stock in their "personal toolbox" and the kind that just figure out how to do the job at hand. IMO, the former has a much better chance at really getting things done, and usually higher education is a total waste of time for those types. Me included.

        Those who do develop their "personal toolbox" are IMO showing a more long-term mentality. Those who are completely absorbed by immediate goals are on a treadmill of sorts, and they miss out on a lot of important stuff, because it isn't "on the exam".

        However, I dispute your contention that higher education is a "waste of time" for self-motivators. A good school will facilitate independent thinking, not stifle it.

  • If you want an easy place to start where you're likely to find a good job I suggest you pick a web project and offer to maintain the db code of that project especially if you can work with both MySQL and Oracle. Being a DBA might not be the most fun but it seems to pay well and companies seem to always be looking for such help. Having Perl, Python, and PHP are also good languages to make sure you know. Any admin or web programming jobs you take will exercise all three heavily.

    Have a web page with your resume and a list of projects you've worked on and examples of your programming. Pick some of your best work.. something of decent size and complexity that's implemented well.. and include it as a tar/gzip file when you submit your resume. Doing so greatly increases responses.
  • 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.
  • With OSS code around, it's a fantastic opportunity to *read* lots of other people's code. Writing some HTTP protocol stuff? Take a peek at the Mozilla, Konq, curl etc source for some pretty wildly different ideas at how others have tackled it, and compare it with your own ideas.

    Books and professors never seem to teach you about ideas for debug, error handling, build systems, using profiling tools etc. Also, by dipping into lots of projects you can get a feel for what's good and what works for different situations, much quicker than the usual company where you'll tend to stick to the same tools and systems, not to mention a small pool of opinions.

    The environment / requirements of your software will no doubt be changing quickly so you need to keep getting wider experience than your job generally gives you.
  • I know a lot of people that take on interns. Might not be paid experience, but it is work experience and looks good on a resume.

    I've had interns use me as references to get jobs plenty of times. Mainly it takes a little effort on the employers part, but several of the companies I work with have similiar programs... It's merely a matter of students contacting us and asking for free training in exchange for helping out.

    Keep in mind that there are a lot of small computer companies out there, even now... We've had our incomes cut because it's been hard to sell with the internet crash and then 911. Most of us know what it's like to be at the bottom and are willing to help give experience.

    Keep in mind as well, going to work on an OSS project is just as valid to most of the computer programming firms I know. It probably won't help getting you a job at Big Blue, ATT or any other fortune 500 company, however most software companies are not that big and while a cvs/resume gets you a chance to be heard, pulling out a software package that you helped to produce can blow anything else away.

    Lando
  • Jump on in! (Score:2, Interesting)

    by zachlipton ( 448206 )
    I'm 13 years old and am involved in the Mozilla project and somewhat in the parrot (parrotcode.org) project as well. If you don't believe me, do a google search on my name (Zach Lipton)... I got involved with Mozilla two years ago and as they say "On the internet, no-one knows you are a dog."

    Mozilla has had some exiciting work done by students (including one high school student who is 15 years old who interned at Netscape last summer) and http://www.mozilla.org/school shows that open-source as an assignment really does work.

    Instead of wasting time with small example programs, simply getting involved with a project and keeping a record of what you do may be one of the best ways to really learn about software development. I am the Quality Assurence Contact for 3 components and the Owner for 2 in mozilla.org and I am able to communicate with other developers around the globe on irc.

    So come on in and join the pool, many opensource projects are standing by for your patches!
  • Many would like to have something concrete to put down on their resume or application to graduate school.
    Great! Better get working then, eh?
    However, starting their own project is a hard and time-consuming task.
    Hard and time-consuming.. Hmmmm.. that sounds like precisely the kind of thing they might like to see on a resume. So how about starting your own projects?

    I know the original comment didn't intend to ask, "We are lazy, what can we do that is easy but looks good?" But this is something I run into SOOOOO often, it's crazy. I have many hobbies. I take 3D photos. I render scenes in POV-Ray. I build robots and various other gadgets, etc etc. And you know what the first question is that I hear, whenever I show these to people? They say, "COOL!!" Followed by, "What class is this for?" To which I reply.. "Umm... it's... for fun." Seems to be a concept few people understand. (Although lately I've resorted to saying, "It's for the Robotics Club", which seems to make it all "normal" again in most peoples' eyes. They no longer question the fact that I'm doing work because I want to, because I enjoy it immensely. Good thing I never mention that I founded the club. They'd never understand that.)

    Again, no disrespect meant to anybody. I just find it a bit odd that here I am, a Junior in college, and any time I do anything fun (or hard), it's immediately assumed that I'm doing it for credit. How about finding something you love to do, and WORKING YOUR BUTT OFF ON IT, and putting THAT on your resume? (Says the guy who'll probably NEVER find a career.. ;)

  • ...for one, stop reading and posting silly questions to Slashdot, and just subscribe to any one of the mailing lists of the many open source projects around. Pick something that sounds interesting. Or find a pyschologist if you don't know what is interesting to you. Sheesh.
  • by Capt.Smirk ( 554635 ) on Tuesday February 26, 2002 @10:51PM (#3075501)

    As I approached completion of my undergraduate degree, I was lucky enough to get a graduate student level internship at NASA. While I was there, I learned that I could make important contributions by applying the theory I had learned in school; essentially doing graduate level research while still an undergraduate. Speculating that there were others out there like me, I came up with the idea that we could come together to form a online research society. The society would differ from the open source community in that it would be based around a process. People would submit proposals, contributors would then offer resources for implementing the proposal, and the project would start when it had enough resources. The only constraints on the project proposal would be that it describes its goals, the process it will use to acheive these goals, and that it would have a deadline. The society would track proposal status and require a postmortem at the end of the project duration. This system is somewhat similar to the (failed) commercial ventures CoSource and SourceXchange, but would be not-for-profit.

    While I understand that such a system is hardly any kind of substitute for a "real" job, the research would be public, and citation of such material would be valid resume fodder. Of course, you could be lazy like me and look for work in your school. What started my resume was not the internship at NASA, but work I did for a professor, namely C++/Win32 application development at $6/hr!

    Save the Wild Thoughts and Ideas! -wildideas.org [wildideas.org]

    -smirk

    P.S. I just checked the link to find it didn't work anymore...then I found out that I had let my name registration lapse! If the above link doesn't work, wait for the DNS change to propigate. Thx.
  • We're doing this (Score:2, Interesting)

    by lkehresman ( 106841 )
    At my university, we started a class called "Open Source Software Development" this spring. In it, we are actively working on an open source project, and are learning about the methodologies and philosophies that go along with this development model. On the practical side, we are also learning to use some of the most common development tools (SourceForge, CVS, Lists...). The class is student led with a professor overseeing the whole thing. So far it has been going really well. We are three weeks into the semester, and the students are already contributing quite a bit to the project. Looks like it's going to be a winner!

    Luke
  • Yee ha! (Score:5, Insightful)

    by ansonyumo ( 210802 ) on Wednesday February 27, 2002 @12:12AM (#3075755)
    First, let me qualify my post:
    * I regularly evaluate candidates for employment in a disciplined software development environment.
    * I fully support Open Source Software.

    That being said, the open source code that I have reviewed has been of low quality in the areas that I look for in evaluating candidates, including:
    * strong OO principles
    * rigorous design
    * excellent documentation

    The few open source projects that I have tried to contribute to (freenet being one) actually scoffed at these points, claiming them to be the stuff of over-educated highbrows, stuffed-shirt engineer etc.

    If that is the culture of open source software, then so be it. However, in the world of commercial software development, these are very real, very important requirements. The best hacker is useless if he creates an unmaintainable system.

    The point is that, from my experience, OSS projects and commercial development are two very different environments (granted, many commercially-developed codebases are poorly engineered, hackfully constructed and are devoid of documentation). OSS projects will get you acclimated to integrated your work with that of other developers', but may also indoctrinate you in an unrealistic development environment.

    In other words, it produces a lot of cowboys. Don't expect your bazaar approach to be successful in the cathedral.

    • When you say that you look for:

      * strong OO principles
      * rigorous design
      * excellent documentation

      what exactly do you mean? The person can explain benfits of MI? Knows UML notation? What's "rigorous design"? Design that can be mathematically verified?

      In other words, it produces a lot of cowboys. Don't expect your bazaar approach to be successful in the cathedral.

      There are plenty of "cowboys" working on proprietary systems. You just don't know, because you cannot examine their code.

      In OSS project the source code serves as the main communication medium between developers, it's the only documentation that never goes out of date.

      Good software engineers are rare in any environment, but when you find them they can do amazing things.

      As far as building "cathedrals" - I'd consider the Linux kernel and the Apache web server as pretty good examples of "cathedrals" built using the "bazaar" style of development. No?

  • Can undergrads really participate in this? I mean, sure there are a few with some skills. But the vast majority have trouble understanding basic OO concepts. Even fewer (as in none) would understand how to use cvs, or debug, or whatever.

    In my experience (as a college grad and TA) is that you don't really become a Software Engineer until you spend a year or two in the Software Industry.

  • by bryanwclark ( 532325 ) <[moc.liamg] [ta] [wbkralc]> on Wednesday February 27, 2002 @07:59AM (#3076788) Homepage
    I think I'm pretty lucky at my school, recently we recieved resources from the administration to construct an Open Source Institute on campus. We were giving a computer lab area where we fixed up some old PC's and created our own distrobution so that we may easily instlal all the packages necessary to our environment.

    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) [clarkson.edu]

  • by elliotj ( 519297 ) <slashdot&elliotjohnson,com> on Wednesday February 27, 2002 @08:50AM (#3076859) Homepage
    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.
  • Because in order for a software project to have any effect it has to be judged by other people interested in open source software. These people are also the same ones you compete with to get jobs and are usually more intimidated than impressed.

    Instead of writing free software to gain experience you should use open source software to interact with other programmers who can then get you leads. Most open source projects are created for social value not for software production.

  • Note: I am an IBM employee, but these opinions and observations are mine and do not necessarily represent the views and opinions of IBM.

    One thing I always love about "Ask Slashdot" is that people ask questions who seem to have already made up their mind about the answer. This questioner is no different. A more useful question would have been: I'm a CS undergrad and I'm getting ready to graduate. What weapons do I need in the interview process to land me a job given the current economy? See how that question doesn't presuppose an answer?

    I'll answer the question you should have asked, rather than the one you did ask. So, what is important for the job-seeking CS undergrad these days? The first thing would be to find a company that is actually still hiring undergrads. Don't let the fact that some company XYZ was at your college's job fair imply that they are looking to hire you. When I went back to my alma mater in October to assist with the recruiting effort, there were several companies at the job fair who were there basically to save face. Many weren't hiring and were simply collecting resumes which I can only assume went straight to the nearest recycling bin. You're wasting your time pursuing a company like this. If they don't have the budget to hire people, then it doesn't matter how intelligent or skilled you are, you won't be hired there. That said, there are still some companies that are hiring. The key difference is that now they are looking for the absolute cream of the crop. This is opposed to just a few years ago, when software companies were hiring anyone who was remotely qualified.

    So what makes you the cream of the crop? Obviously, intelligence and raw ability are very important. If you have shitty grades, you might as well start looking for a job in another field; however, your intellect alone is not going to get you a job.

    Experience is also very important. You touched on this with your original question, but I think that you're looking in the wrong place to gain experience. While you can certainly argue that OSS experience is better than no experience, I would say that working on an OSS project doesn't really give you the kind of experience that commercial software firms are looking for. Hiring managers want to see that you've worked in a close knit, team setting; they want to see that you can communicate effectively with your teammates (in both oral and written media); they want to see that you have solid design skills. Basically, they want to see if you have a structured approach to designing, writing, documenting and testing software. In contrast, OSS projects seem to take a more freeform approach which is orthogonal to how commercial firms do business. There are exceptions to be sure, but I think that by and large the majority of OSS projects aren't going to provide you the right kind of experience. A better approach would be to secure an internship or co-op position. Not only do you get some experience in the "cathedral", but you also get your foot in the door for when you do graduate.

    Something else to consider is your prospective employer's attitude towards the OSS movement. Some companies are outwardly embracing OSS because they see the business climate as heading that way - basically, an "if you can't beat'em, join'em" attitude. Even if the company is outwardly a supporter of OSS, the individual hiring managers may not be. My former manager was very skittish about OSS, despite the fact that IBM is embracing it with more or less open arms. Here, you have to be able to get a read on the person who is going to be responsible to making you the actual job offer. Feel them out first before you launch into the OSS experience you have.

    A passion for the technology is also important. Are you really excited about the field, or did you just pick CS because the monetary prospects looked good at the time? People who are really into technology wear that enthusiasm on their sleeves. It really comes through in an interview, and can make all the difference between otherwise equally qualified applicants. Find some area that you are really excited about an concentrate on it. Have some demos to show in the interview. Interviewers love to have something to back up the resume, and a portfolio CD is a great way to do that.

  • I work in computer graphics, which is a rapidly changing and very competitive field.

    When interviewing candidates, I want to see one major project that they've worked on to which my immediate reaction is, "cool." If they want to write games, saying "I worked on Unreal2" is pretty cool. As a student, you probably can't say that. But a final or independent project you worked on that blows me away is going to get you a job where a 4.0 (5.0 for the MIT crowd) average, good letters of recommendation, and knowing 200 digits of PI will still get you dumped out the door if I don't think you have coding experience.

    OSS is appealing to some people, and I support open software development in cases where it has a chance of being superior. But if I'm interviewing you, I don't care what your ethical standing is toward OSS-- I care if you worked on something cool and will help make our product cool, too. So if the choice is making a patch to the Linux kernal, a new GIMP filter, or working on something closed-source (or a personal project) but relevant to what you want to do professionally, ignore the OSS/closed distinction. It matters to you, not your employer, and they're the one making the decision.

    -m

  • by systemBuilder ( 305288 ) on Wednesday February 27, 2002 @02:03PM (#3078658) Homepage
    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.

One man's constant is another man's variable. -- A.J. Perlis

Working...