Being a GNU Contributor

I am currently 3 semesters into my AS for Computer Science, I will be going for my BS afterwards through a distance learning program at a University. After I finish my AS I would like to get a job working in the field while I finish my BS. Ideal, I know, I'm sure everyone wants to do this so I'm trying to get my resume together for when I do complete my AS degree. I wanted to have something that would put me apart from the other 2-year applications. I'm not expecting a "good job" right away, but I want to get into something CS related instead of my current call-center tech-support gig.
In order to be a step above a regular graduate; it seems like you either have a nice collection of programs that you are proud of, or you work on some kind of project group. It's my opinion that being on the group would be a more powerful statement. To me, it seems to imply that you have already been accepted as a programmer worthy of contributing to a project. I'm sure most of you can imagine that it would be completely possible to join some random persons project online and claim to be on a team or such, even with minimal coding experience or contributions. So then the problem becomes getting on a team that is already recognized as being a respected team of programmers.

Thats when I looked into how to become a GNU Contributor. After looking and finding something that I thought I wanted to help with, I reflected on some of the other things I saw on the site. I think most prominent is that - grossly overstated, I'm sure - "every Official GNU program is an attempt to provide the same functionality that some other particular proprietary program does." I think that sounds great from the user's perspective, but what about an employer who is looking at an employee. I'm afraid that it might be some kind of red-flag to wrong people.

My reasoning has reduced my opinion to two scenarios:
Being a GNU Contributor would be good for a resume because it shows that you can work with a team while providing functional code independently.
Being a GNU Contributor would be bad for a resume because of potential concerns by the employer for their Intellectual Property, or other such trust related issues.

Of course, you know this boils down to: if I do deem it to be a bad idea to help with GNU, then I would need to find another group. Any suggestions?
Maybe there is something completely different that you think I could consider for boosting my resume.

Thanks!

Why would it raise potential concerns for their intellectual property ?
If anything a free software developer would be less likely to steal his employers IP since he'd get caught almost immediatly.

The fact that alot of GNU software attempts to provide equivalent functionality to that of proprietrary software is a non issue as pretty much all proprietary software does exactly the same thing, thats how the software industry works. (Some things are protected by patents but the FSF respects those even if they don't agree with the concept of software patents).

2.1 Referring to Proprietary Programs
Don’t in any circumstances refer to Unix source code for or during your work on GNU! (Or to any other proprietary programs.)

If you have a vague recollection of the internals of a Unix program, this does not absolutely mean you can’t write an imitation of it, but do try to organize the imitation internally along different lines, because this is likely to make the details of the Unix version irrelevant and dissimilar to your results.

For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. You could keep the entire input file in memory and scan it there instead of using stdio. Use a smarter algorithm discovered more recently than the Unix program. Eliminate use of temporary files. Do it in one pass instead of two (we did this in the assembler).

Or, on the contrary, emphasize simplicity instead of speed. For some applications, the speed of today’s computers makes simpler algorithms adequate.

Or go for generality. For example, Unix programs often have static tables or fixed-size strings, which make for arbitrary limits; use dynamic allocation instead. Make sure your program handles NULs and other funny characters in the input files. Add a programming language for extensibility and write part of the program in that language.

Or turn some parts of the program into independently usable libraries. Or use a simple garbage collector instead of tracking precisely when to free memory, or use a new GNU facility such as obstacks.
[/quote]
http://www.gnu.org/p...s/standards.pdf