I get the big picture, now how do I break it down?
December 26, 2007 6:43 AM Subscribe
I love the whole Linux idea from start to finish. I've been using it for a year now, full time, and I want to go deeper. How do I contribute?
I'm not a programmer in the traditional sense; I guess I'm a wannabe. Everything I know is self taught and I've never worked in a team environment. I love the open source model and want to contribute for a couple of reasons. One, to give back and, two, I want to learn more about programming as a group.
I've done pretty well in the scripting languages (PHP, Ruby, bash, etc), but I've always stumbled when it came to real programming (C, et al) and I want to break through. I have some ideas in mind for projects down the road and would like to learn how to build curses based apps, specifically. I guess the language could vary, but I assume most are written in C or C++. I can check out source, but I usually find myself overwhelmed.
Any ideas? Buy a book? Go to school? IRC? Googling either leads me to the kernel itself or some uber-specific topic like Java. I found this question, but it seems to be for someone who's already a programmer looking to break in. I think I need a hand holder to walk me through the baby steps to the open source world first.
I'm not a programmer in the traditional sense; I guess I'm a wannabe. Everything I know is self taught and I've never worked in a team environment. I love the open source model and want to contribute for a couple of reasons. One, to give back and, two, I want to learn more about programming as a group.
I've done pretty well in the scripting languages (PHP, Ruby, bash, etc), but I've always stumbled when it came to real programming (C, et al) and I want to break through. I have some ideas in mind for projects down the road and would like to learn how to build curses based apps, specifically. I guess the language could vary, but I assume most are written in C or C++. I can check out source, but I usually find myself overwhelmed.
Any ideas? Buy a book? Go to school? IRC? Googling either leads me to the kernel itself or some uber-specific topic like Java. I found this question, but it seems to be for someone who's already a programmer looking to break in. I think I need a hand holder to walk me through the baby steps to the open source world first.
Whatever distro you use has wikis, mailing lists, etc where they coordinate various projects. There are lots of things you can do to help, from writing or editing documentation to getting involved in a local LUG. Pick something that aligns with your natural interests and just get involved.
posted by COD at 7:09 AM on December 26, 2007
posted by COD at 7:09 AM on December 26, 2007
The places where Linux often falls short, because of the lumpy, bumpy nature of open source development, is the spadework of documentation and UI/interaction design. If you like a particular project, but feel that the look and feel can be tweaked, there'll be developers glad to hand over the task.
Another way to get a foot in the door is through things like Perl modules and their equivalent in other scripting languages: you don't break the codebase, there's a large corpus to draw upon, and plenty of people paying attention.
posted by holgate at 7:10 AM on December 26, 2007
Another way to get a foot in the door is through things like Perl modules and their equivalent in other scripting languages: you don't break the codebase, there's a large corpus to draw upon, and plenty of people paying attention.
posted by holgate at 7:10 AM on December 26, 2007
Seconding holgate's comments about documentation. Find your favorite open source app and start updating and correcting the documentation. Also, if you speak foreign languages, supplying translations for the UI and documentation is also very appreciated. If your favorite apps have pretty good documentation support, look at other apps you use. Eventually you'll find one with documentation in need of work.
posted by fengshui at 7:17 AM on December 26, 2007
posted by fengshui at 7:17 AM on December 26, 2007
It depends on what you mean by "Linux". Do you mean the kernel, the distros, or open source in general? If it's the kernel, yeah, you need C knowledge for that, but you could still look over the kernel janitors project and see if there's anything you can contribute there.
If you want to support your favourite distro, the best place to start is bug reports and documentation. I work for one of the big distros, and we love it when we get a new user who a) knows how to write a good bug report and b) is motivated enough to write good bug reports. We have a bunch of smart full-time QA people, but it's still tough to shake out the bugs from something as massive as a Linux distro, so we depend on you, the user, to help us. If you want to get programming knowledge out of it, look at the source code of the offending program and see if you can track down the place where the bug is occuring and include that with your report. That'll get you familiar with read other people's code (C, C++, or otherwise) as well as comfortable with open source debugging tools like GDB.
If you want to learn how to be a good programmer while contributing to open source projects at the same time, buy a couple of good books on the language to start with, maybe one of those "LEARN $X IN THIRTY SECONDS A DAY" ones and whatver the definitive language reference is (K&R for C, Stroustrup's C++ book, whatever the Ruby one is these days, you get the drift). Read them so you understand how the language is constructed, how pointers work, etc. Then find a fun project that is past the "vague planning stages" and learn it inside and out. Start from the top, work your way down, and once you have a good grasp on how everything fits together, look through the project's bugzilla, find a bug, fix the bug, and submit a patch. Voila, you are now not only a contributing member of the open source community, but you've also learned a whole lot in the process.
Finally, a frequently overlooked area is man page documentation and kernel API documentation. Getting involved with working on the documentation projects for the kernel or one of the large userland libraries like glibc, glib, gtk, or even wxWidgets if that's your bag, involves reading a lot of code and figuring out what the code does. And reading code is one of the most important things to do when you want to become a better programmer.
posted by cmonkey at 7:18 AM on December 26, 2007 [2 favorites]
If you want to support your favourite distro, the best place to start is bug reports and documentation. I work for one of the big distros, and we love it when we get a new user who a) knows how to write a good bug report and b) is motivated enough to write good bug reports. We have a bunch of smart full-time QA people, but it's still tough to shake out the bugs from something as massive as a Linux distro, so we depend on you, the user, to help us. If you want to get programming knowledge out of it, look at the source code of the offending program and see if you can track down the place where the bug is occuring and include that with your report. That'll get you familiar with read other people's code (C, C++, or otherwise) as well as comfortable with open source debugging tools like GDB.
If you want to learn how to be a good programmer while contributing to open source projects at the same time, buy a couple of good books on the language to start with, maybe one of those "LEARN $X IN THIRTY SECONDS A DAY" ones and whatver the definitive language reference is (K&R for C, Stroustrup's C++ book, whatever the Ruby one is these days, you get the drift). Read them so you understand how the language is constructed, how pointers work, etc. Then find a fun project that is past the "vague planning stages" and learn it inside and out. Start from the top, work your way down, and once you have a good grasp on how everything fits together, look through the project's bugzilla, find a bug, fix the bug, and submit a patch. Voila, you are now not only a contributing member of the open source community, but you've also learned a whole lot in the process.
Finally, a frequently overlooked area is man page documentation and kernel API documentation. Getting involved with working on the documentation projects for the kernel or one of the large userland libraries like glibc, glib, gtk, or even wxWidgets if that's your bag, involves reading a lot of code and figuring out what the code does. And reading code is one of the most important things to do when you want to become a better programmer.
posted by cmonkey at 7:18 AM on December 26, 2007 [2 favorites]
Good programming is hard. Good operating system programming is really, REALLY hard. This is the sort of thing you need to be a real hands-in-the-guts sort of programmer to do well, and proficiency with modern scripting languages ain't good enough.
cmonkey's strategy is both eponysterical and good. By digging around in projects and reading code, you'll be contributing and learning at the same time, preparing yourself to be an actual developer.
posted by middleclasstool at 7:24 AM on December 26, 2007
cmonkey's strategy is both eponysterical and good. By digging around in projects and reading code, you'll be contributing and learning at the same time, preparing yourself to be an actual developer.
posted by middleclasstool at 7:24 AM on December 26, 2007
Doc doc doc doc. Just reading the details on what the programmers post, emailing them about what they're working on, etc. can transform a project that 8 people can use into one that many people can use. This is probably the WORST part about most open-source projects. Similarly if you're willing to test features, make sure they do what they say they do, report bugs with full details, etc. you'd help tons.
posted by a robot made out of meat at 8:36 AM on December 26, 2007 [1 favorite]
posted by a robot made out of meat at 8:36 AM on December 26, 2007 [1 favorite]
One way that you can help is simply by learning the open source programs, and then politely answering questions. It seems to be getting better, but the Linux crowd always has a large contingent of elitist, blame-the-user assholes. If a user wants a particular feature, and it's hard to do in Linux, then the user must be stupid for wanting it. The Linux crowd tends to be very hostile toward 'stupid' people, particularly when the real failing is with the software. This drives potential new users away. You see this over and over and over.
A friendly person who will be candid and straightforward about the strengths and limitations of Free Software does a great deal to ensure its success. The rest of the Linux community will never notice you for doing this, but you will nonetheless contribute.
If you can code and document and work on UIs, those are even better.... but just answering questions and treating new users like human beings is a real service.
posted by Malor at 9:12 AM on December 26, 2007
A friendly person who will be candid and straightforward about the strengths and limitations of Free Software does a great deal to ensure its success. The rest of the Linux community will never notice you for doing this, but you will nonetheless contribute.
If you can code and document and work on UIs, those are even better.... but just answering questions and treating new users like human beings is a real service.
posted by Malor at 9:12 AM on December 26, 2007
http://flossmanuals.net/
Centralized documentation for several Free/open software projects. They always need help documenting simple how-tos for software. Adam there is a very very nice guy.
If you have a specific project / topic you wanted to work on, I bet they could accommodate you.
posted by sethwoodworth at 10:10 AM on December 26, 2007
Centralized documentation for several Free/open software projects. They always need help documenting simple how-tos for software. Adam there is a very very nice guy.
If you have a specific project / topic you wanted to work on, I bet they could accommodate you.
posted by sethwoodworth at 10:10 AM on December 26, 2007
Find a real programmer and get him or her to mentor you. It's a trade, and the only way to get good at it is to do it a lot. Doing it in a vaccum is bad, because you'll learn to do it wrong.
posted by jeffamaphone at 10:17 AM on December 26, 2007 [1 favorite]
posted by jeffamaphone at 10:17 AM on December 26, 2007 [1 favorite]
I am in a similar position. I can't code well enough to contribute in that sense, but I find other ways to contribute. I spend a lot of time on forums, (mostly on debian based distros like Mepis, or Ubuntu) and help "noobs" with simple tasks. I can't really help with the more difficult problems because my knowledge isn't too great, but I can help fine with Xorg problems, wireless issues, etc etc.
I also do a lot of testing. I am writing from my laptop which has a few issues due to the hda_intel audio chipset as well as some weird monitor problems. Such as how if "DDC" is on in xorg.conf, then my fonts get all blown up using the intel video driver. I try alpha Ubuntu releases, as well as Mepis (if you can tell I am a fan of apt-get :-P) and try to resolve these issues, report bugs etc.
Stay active in the community, report bugs, and get people hooked. You don't need to code to contribute in a big way.
posted by MaHaGoN at 10:43 AM on December 26, 2007
I also do a lot of testing. I am writing from my laptop which has a few issues due to the hda_intel audio chipset as well as some weird monitor problems. Such as how if "DDC" is on in xorg.conf, then my fonts get all blown up using the intel video driver. I try alpha Ubuntu releases, as well as Mepis (if you can tell I am a fan of apt-get :-P) and try to resolve these issues, report bugs etc.
Stay active in the community, report bugs, and get people hooked. You don't need to code to contribute in a big way.
posted by MaHaGoN at 10:43 AM on December 26, 2007
Documentation is huge. Writing test suites for projects that don't have them could also be useful. Internationalization is big, too, though that can be hard to get started on.
Good testing and bug reporting is hard. It's not just running the programs. If you get very good at that, you can really make developers' lives easier.
Curses development is kind of a pain. ncurses is a terrific library, but it's a somewhat uncomfortable way of programming. To learn C or C++, you need to jump in with the language, not libraries - no X, no ncurses, no linux-specific stuff. Solving problems in plain old C++ is really what you need to do. And for that, you need a book, and someone that will be very patient with you & answer lots and lots of questions. Idling in a C++ IRC channel can help, but they tend not to like to answer a bunch of simple questions, or walk you through things. You really need someone 1 on 1 too.
posted by devilsbrigade at 12:56 PM on December 26, 2007
Good testing and bug reporting is hard. It's not just running the programs. If you get very good at that, you can really make developers' lives easier.
Curses development is kind of a pain. ncurses is a terrific library, but it's a somewhat uncomfortable way of programming. To learn C or C++, you need to jump in with the language, not libraries - no X, no ncurses, no linux-specific stuff. Solving problems in plain old C++ is really what you need to do. And for that, you need a book, and someone that will be very patient with you & answer lots and lots of questions. Idling in a C++ IRC channel can help, but they tend not to like to answer a bunch of simple questions, or walk you through things. You really need someone 1 on 1 too.
posted by devilsbrigade at 12:56 PM on December 26, 2007
If you're looking to get some experience working with a group, it's best to join an existing project rather than to start a new one. New projects don't attract contributors until they're already useful, and that can take months or years.
Find something specific that you want to add, improve, or fix. It's much easier to understand source code if you have an objective. You don't need to understand everything to help, and if you have a specific goal, you can just ask "where would I add this feature/fix this bug/change the way this works?" and get a useful answer.
Start small, and keep your immediate objectives in line with your level of confidence. There are a lot of things you can do that don't involve any programming at all - documentation, testing, community work; there are a lot of programming tasks that don't require much skill or in-depth knowledge - updating patches, fixing simple bugs. This may mean you don't get started on your real objective for a while, but if it's something you care about, that won't matter.
posted by plant at 6:21 PM on December 26, 2007
Find something specific that you want to add, improve, or fix. It's much easier to understand source code if you have an objective. You don't need to understand everything to help, and if you have a specific goal, you can just ask "where would I add this feature/fix this bug/change the way this works?" and get a useful answer.
Start small, and keep your immediate objectives in line with your level of confidence. There are a lot of things you can do that don't involve any programming at all - documentation, testing, community work; there are a lot of programming tasks that don't require much skill or in-depth knowledge - updating patches, fixing simple bugs. This may mean you don't get started on your real objective for a while, but if it's something you care about, that won't matter.
posted by plant at 6:21 PM on December 26, 2007
If you want to actually code rather than do docs, find a project you use that was written in a scripting language you already know (such as the Ruby you mentioned, or Python, which is used more). Then look at their bug tracker and fix a bug and submit a patch. This will gradually teach you more about the language you are using, will teach you about the codebase of the project you pick and will make the devs like you if your patches are good.
You can do curses programming in Python too, and I'm assuming Ruby.
If you really want to learn C I'd go get a college text book and work through it from the start, including all the exercises.
posted by markr at 6:36 PM on December 27, 2007
You can do curses programming in Python too, and I'm assuming Ruby.
If you really want to learn C I'd go get a college text book and work through it from the start, including all the exercises.
posted by markr at 6:36 PM on December 27, 2007
Response by poster: I know my question was vague, but every one of these answers were right on the money. I just want to learn how to contribute while furthering my knowledge of all things open source. I want to learn more about programming (in any languages), docs, contributing and online collaboration with people from all over the world.
I guess I'll throw my name in the hat for what I can help with on the projects I really enjoy and learn the rest as I go. As far as programming, I think the last suggestion about finding bugs in projects written in languages I know and fixing is a great starting point.
*mark all as best answer(s)* Thanks!
posted by cdmwebs at 7:05 PM on December 27, 2007
I guess I'll throw my name in the hat for what I can help with on the projects I really enjoy and learn the rest as I go. As far as programming, I think the last suggestion about finding bugs in projects written in languages I know and fixing is a great starting point.
*mark all as best answer(s)* Thanks!
posted by cdmwebs at 7:05 PM on December 27, 2007
Response by poster: Okay, I've looked around at a few bugzillas. Anyone got any recommended reading on actually doing the patching? I'm okay with Subversion, etc., but I've never done the patch thing on other's code. Is there a de facto standard I can follow?
posted by cdmwebs at 6:10 PM on December 28, 2007
posted by cdmwebs at 6:10 PM on December 28, 2007
I contribute to the NetBeans project, so I can point you to their page about how to make and submit a patch. Some of the information, likes paths and licenses, are specific to that project, but most of it would be generally helpful.
Each project will have a different system for accepting patches. Some, like NetBeans, have a fairly formal process while others I have contributed to did not. In some cases, I just sent the patch in an e-mail to the maintainer. You should see if the projects you're involved in have specific guidelines.
posted by tomwheeler at 2:20 PM on December 29, 2007
Each project will have a different system for accepting patches. Some, like NetBeans, have a fairly formal process while others I have contributed to did not. In some cases, I just sent the patch in an e-mail to the maintainer. You should see if the projects you're involved in have specific guidelines.
posted by tomwheeler at 2:20 PM on December 29, 2007
I'm okay with Subversion, etc., but I've never done the patch thing on other's code. Is there a de facto standard I can follow?
Having the code in a subversion repository makes it pretty easy: run svn up, make your changes to FILENAME, run svn diff -cHEAD PATH_TO_FILENAME > PATCH_OUTFILE from the top level project directory, and it'll output a unified diff patch suitable for submitting directly to the maintainer or mailing list.
You can combine multiple diffs into a single patch, of course, or (if you're really feeling reckless), run svn diff against the entire repository and dump it into a single patch, but you're on safest territory making a bunch of small patches (one per source file) that can be applied or reverted independent of each other.
In terms of how to actually make the changes, that depends on the project. Some of them have the forethought to put together a coding standards document, but most don't. So it's up to you to figure it out based on the existing code. Other than making sure that your indentation and variable naming fits in the project, document the source code (of course), and when you submit the patches, write a clear description of what each patch does. And with most projects, particularly smaller ones, chances are that even if you fuck up your patch submission people will be pretty forgiving.
posted by cmonkey at 11:10 AM on December 30, 2007
Having the code in a subversion repository makes it pretty easy: run svn up, make your changes to FILENAME, run svn diff -cHEAD PATH_TO_FILENAME > PATCH_OUTFILE from the top level project directory, and it'll output a unified diff patch suitable for submitting directly to the maintainer or mailing list.
You can combine multiple diffs into a single patch, of course, or (if you're really feeling reckless), run svn diff against the entire repository and dump it into a single patch, but you're on safest territory making a bunch of small patches (one per source file) that can be applied or reverted independent of each other.
In terms of how to actually make the changes, that depends on the project. Some of them have the forethought to put together a coding standards document, but most don't. So it's up to you to figure it out based on the existing code. Other than making sure that your indentation and variable naming fits in the project, document the source code (of course), and when you submit the patches, write a clear description of what each patch does. And with most projects, particularly smaller ones, chances are that even if you fuck up your patch submission people will be pretty forgiving.
posted by cmonkey at 11:10 AM on December 30, 2007
Response by poster: For posterity, here are a couple I found for Ruby on Rails:
http://drnicwilliams.com/2007/06/01/8-steps-for-fixing-other-peoples-code/
http://railscasts.com/episodes/50
posted by cdmwebs at 1:46 PM on December 30, 2007
http://drnicwilliams.com/2007/06/01/8-steps-for-fixing-other-peoples-code/
http://railscasts.com/episodes/50
posted by cdmwebs at 1:46 PM on December 30, 2007
« Older can I, should I ressuscitate my dead printer ? | How to get education funds earmarked? Newer »
This thread is closed to new comments.
posted by pallak7 at 6:51 AM on December 26, 2007