Grad Student Looking To Contribute To Open Source
An anonymous reader writes "I'm an Applied Math grad student who knows a bit of Mathematics and a bit of programming. C++ is my first programming language — I am decent at it. I wish to start contributing to a numerical library with two purposes — contribute to open source and develop my C++ skills at the same time. I looked at the Boost libraries and joined the developer list. However, I have no idea on how to start contributing. I'm not an expert in template programming, having written only toy programs to understand that concept. I've used some of the OOP constructs like inheritance,but only for very small projects. Do you have any tips on how to get started on contribution? Are there any other emerging numerical libraries to which I can contribute? Are there any other avenues where I can contribute to open source and improve programming skills?"
To understand most boost modules, you definitely need a thorough understanding of templates.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
The KDE C++ math classes are "eigen": http://eigen.tuxfamily.org/index.php?title=Main_Page
This is just a library (well actually a set of inline header files)
More generally, there are programs like "maxima" (symbolic manipulation, integration, etc) and "octave" (like mathlab).
I would love to see more work go into maxima :)
1. Join a big open source project.
2. Read the bug reports
3. Start churning out fixes for bugs
4. Profit!
Just saying it like it are.
Boost (boost.org) is broad and pretty fancy. Eigen (eigen.tuxfamily.org) is narrower in scope - linear algebra - and just might be closer to your interests. To learn the details of templates, Alexandrescu's book -- Modern C++ design -- is a way of diving in deep quickly. Reading the Loki sources is also a good way of going about it ( http://en.wikipedia.org/wiki/Loki_(C++) ). Those are resources I can come up with off the top of my head. And general advice also hold: try stuff. Make a source repo for yourself (git, mercurial, darcs, whatever) and pick a small problem to solve and hack at the templates there. Use version control so you can come up with one solution and refine it and look over your own development history.
I work in air traffic control and kinematics are a big deal for us. This is the software which takes care of coordinate systems, motion and transformations. Say you have a vehicle with a particular WGS84 coordinate. Its moving at a particular speed in a particular direction relative to true north. After one hour where will it be in three dimensions relative to its original position? How much distance will it have covered? What happens if its trajectory went within two metres of the south pole? What path in 3D will it follow if it maintains a constant altitude above the datum along the way?
Ok now say it is not allowed to fly into (say) North Korea which has a particular shape. How can you project its path forwards to determine if it goes into the air space over that country?
And so on. Its bloody complicated stuff and I reckon a lot of open source software would benefit from a library which did this. Ideal for a maths guy.
http://michaelsmith.id.au
Don't take this the wrong way, but you're in math, not CS. Call the CS department, find someone who's willing to team up with you on this and work together on turning the mathematical end of your contributions into good code. You'll come out of it with a better understanding of how software should go together, your CS cohort will get some insight into applied math and both of you will be better for the experience.
The easiest way to enter Open Source to write patches for existing software. Learn how to communicate with other developers, how to be flexible and adopt their coding styles and practices. Chances are this will help you learn the most, because you'll be writing smaller amounts of code and it will always be under review by someone else. Once you've shown your competency, you're usually given commit access to the project.
Boost can be a very helpful community. Submitting a new library to Boost typically follows a few steps: gauge interest, put up code/examples/documentation for informal comments, submit for review. It sounds like you've got a lot to learn in C++ so it might be a long road (Boost has a very high bar to meet), but if you've got perseverance and are eager to learn, you can make it happen.
Your intended point (while you stated it rather poorly, since it's stupid to suggest someone couldn't be a good programmer in a language simply because it's their first - I am still a "decent" BASIC programmer despite learning many languages since) is understandable and probably something that we all thought when reading the summary, but it does depend on your definition of "decent", and the poster's ability to self evaluate. Usually I take "decent" to mean "average to good". As an "Applied Math grad student" he has already demonstrated good logical ability and therefore probably has the makings of a good programmer.He didn't claim he was amazing, but presumably he can write code that works even if it's not amazingly efficient, and he clearly knows he has much to learn and is looking for avenues to improve.
Rather than simply making obvious criticisms, you could try to help. I unfortunately have very little experience with helping out in open source projects, and have no clue about Mathematics libraries so I can't offer any useful advice, but I'm certainly not just going to sit here and watch while some smug AC takes immature pot shots at a guy who is trying seriously to both better himself and help out other people in the process.
which is totally what she said
Which is why I said:
Your intended point is understandable and probably something that we all thought when reading the summary
Still, being decent at a language and it being your first language are not contradictory things. Thinking he's decent at the language and not knowing much about templates is of course more contradictory, but you certainly don't have to be an expert to be "decent" at something.
Anyway, my point was that guy is obviously aware he has more to learn and is humbly asking us how he can do so. It's an attitude that should be encouraged, and it's sad that the first post is someone trying to insult him, with no actual helpful advice.
which is totally what she said
Extrapolating from how #2 smells relative to #1, NUMBER TEN must smell really awful.
You're an amateur, like the thousands of others on the net, like me. This is not a programming skill problem - that comes from either practice or aptitude, not pure willing. This is a contribution problem. You're looking for a project that has many skilled users and also has a very, very basic need they have to meet but at a basic level and that they haven't already done themselves and probably won't take too long. See the problem?
You're asking entirely the wrong questions - I would suggest that instead of trying to add something to Boost or similar, that you try to do something yourself and thus work out why Boost and similar projects are quite complex, have certain standards, etc. The problem of patch submission, new features and bug-fixing is not one of people willing to write the code that fixes the problem - that part's easy, and the fun part - it's finding something interesting that fits within the scope of the project and it's the problem of getting that code into the shape that the project would be happy with too. Thus bug-identification and lots of the hard slog-work (test suites, etc.) are much more useful than anything else you can come up with. I guarantee that the first few ideas you have to contribute to a large project will be knocked back because a) they've been suggested a million times, b) they don't WANT to do it that way, c) they CAN'T do it that way for some reason or d) they just don't trust your code and would spend longer fixing it than just writing it themselves.
I would suggest that you do one of the following:
1) Write your own library, for something you know intimately. Publish it on a website, document it well, do it under a loose license. Chances are it will overlap with other projects but they are always alternatives for everything and if your library is BETTER than the others, it will be used in preference, code will be absorbed from it into other projects, or people will ask you to for more of it. Chances are that it will take you a LONG time to make it better than even the bare basic libraries you find on the net.
(I'll use an example that I'm familiar with - SDL has lots of graphics primitive libraries, but SDL_gfx is one of the best despite not being the only "big" one, despite being unofficial, despite being a one-man operation and yet is used in thousands of projects. All it does is draw circles and polygons and rotate images, for God's sake, but it works and it's simple and it's fast and it's documented so it gets followers)
I know that when I go looking for a library to solve my problems, I am happier with something tiny and in my language of preference (C instead of C++) than some huge generic library that does a million and one other things. I have been on hundreds of tiny sites and found some absolute gems where the author just knocked up the exact piece of code I was after and nothing more and then I've used it, extended it, reported bugs in it and it becomes part of my standard toolchain (as an example, I use LodePNG to save PNG images from SDL_Surfaces, not because that's the only way, or even the easiest way, but because I found it easier than trying to get libpng to do it for me - some of my projects actually use libpng for loading and LodePNG for saving PNG's!).
2) Meld into the community - hunt for bugs, be active on discussions, suggest features (after reading the FAQ's about what not to ask for, etc.), maybe even implement a few test routines to show how useful your feature-X would be. Produce test suites (horrible, horrible job that's incredibly boring but serves a useful purpose). Run valgrind, or some kind of mathematical analysis, on the code and report your fixes for anything found back to the community. The hard-slog but useful stuff that nobody really wants to do.
Everybody would love to be chosen to just insert thousands of lines of code into a big famous project - it very, very, very rarely happens. More likely is that you have a small project of your own that others find useful (because it avoids t
Are there any other avenues where I can contribute to open source and improve programming skills?"
The internet is drowning in code and starving from lack of decent documentation on how to use it. if you want to transform a mediocre, existing OSS project into a world-class, standing head and shoulders above everything else in its field piece of exemplary work, then take ANY numerical library and write some examples for it, write explanations on how it works, what its limitations are (hell: even comment some of the source code itself). Write user guides, API guides, put together a FAQ or a Wiki. List the mistakes and create some workarounds.It's not sexy, but it's what we need most.
The other thing that inspecting other people's work will do (apart from really honking-off some of the more protective - read; poor - software authors) is to show you, close up and in the real world, some of the constructs and techniques that are employed. For better or worse, this will give you a lot of experience in good and bad techniques and will give you a much larger palette to choose from when you decide to endow the planet with yet another piece of OSS of your won making.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
As a C++ developer and boost user, I advise against starting to code for it. API design and implementation are quite hard as opposed to "normal" programming, as you need to factor several other problems: building a easy-to-use generic interface, mandatory in a library, is much more difficult to code than in project that works with specific data models. Also, I had specific problems with boost::filesystem API so I can tell you getting a bug acknowledged and fixed in a particular version might be frightening at first(no, I don't want to update my boost version to get it... I want it backported). I suggest you find a piece of code that you are interested and find useful and follow this simple roadmap:
1.Install it and use it
2.Subscribe to user/devel mailing lists
3.Write missing documentation and unit tests for components
4.Offer to implement features/fix bugs that have been appearing for some time but have a low priority.
In addition to BOOST, you might want to consider looking at other projects. Some that might be a good fit, and might need developers are :
- GSL : The GNU Scientific Library is a scientific toolset for C and C++. These tools are quite modular, and you might be able to find your own module to code.
- Plotting software : Help to any of the plotting programs would be a real boon for all scientists. This could involve developing non-linear fitting algorithms, GUI, or statistical analysis. Look at SciDAVis and possibly GRACE.
- non-linear fitting : C++ Minuit, or a CERNlib project may be a good match--I'm not sure whether these are only developed internally.
good luck!
Knowing a bit about the Boost libraries, he's probably talking about template METAprogramming instead of mere template programming. The former is quite a bit larger of a bitch than the latter. You can be a quite decent C++ developer without ever having done template metaprogramming.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
What seems pretty obvious is that the guy's question is about how to get involved in an OSS initiative, not how to find one. Cultural barriers aside, the perception from the outside is that many existing communities are closed, elitist kingdoms that are unwelcoming and intimidating to newbies. So, while providing a helpful search query may be clever, it does not address the essence of the question and serves to perpetuate the stereotype.
C++ doesn't teach you anything, you study it.
From the summary it sounds like he learned C, not C++. There's a huge, grand-canyon-sized difference between the two.
C++ is a safe, expressive, modern language - like Java but without all the horrible limitations. Yes it takes a bit of study and it's not for casual programmers, but the results are worth it.
C is much lower level, unsafe language. Good for what it does but dangerous and a very bad choice for large projects.
No sig today...
C++ is a safe, expressive, modern language - like Java but without all the horrible limitations. Yes it takes a bit of study and it's not for casual programmers, but the results are worth it.
C is much lower level, unsafe language. Good for what it does but dangerous and a very bad choice for large projects.
It's good you've been rated funny rather than insightful. C++ is every bit as unsafe as C.
Yes, they are very different languages, as C is intended for low-level systems programming, managing individual memory locations and stuff like that, whereas C++ has modern OO concepts badly tacked on top of that in a wrong way. It combines all the problems of Java with all the problems of C, and then adds some more. The end result is quite powerful, but not something I'd ever dare to call "safe".
Most projects love off-loading working onto eager, but inexperienced, contributors. You can't go wrong with most groups by going to them with a good attitude, stating what you can do and asking what you can do to help out. If you get grief from them for that, you can safely write them off as terminal assholes because no reasonably well-balanced human being would slap down someone who approaches them like that.
I've been contributing to a project for a while where the core contributors are far better and more knowledgeable than the average contributor. The community has an elitist reputation, but what I've found from watching how others are treated is that those core contributors will treat the small time contributors very well if they contribute according to their abilities (meaning they don't flood the core contributors with trashy git commits for obviously complicated problems) and work as a team.
Part of the problem is that a lot of people don't like hierarchies and resent the hell out of them. The fact is, however, that they not only exist, but are necessary for social organization.
The end result is quite powerful, but not something I'd ever dare to call "safe".
C++ is as safe as you want to make it.
eg. Did you know that Visual C++ operator[] does range checking in all standard container classes/strings?
If you do stuff like that and ban raw pointers (ie. all pointers have to be objects and thus subject to RIAA) then most of your traditional C++ problems disappear. It just takes a bit of practice and getting over the C mentality.
In return you get multiple inheritance, timely freeing of resources, operator overloading and much more expressive power than Java.
A good portion of Java code is just copy/paste because you can't inherit implementation and try/finally blocks to get your files closed at the end of functions, not just when the garbage collector feels like it (which might be 'never'). In C++ you write code once in a library and it stays written.
No sig today...
Did I really type RIAA instead of RAII? Oh, dear...
No sig today...
Here's an example of what the ledow is talking about with point #1. Or at least a corollary of his point in action. About a decade ago, I wanted to play with XML files in C++. There were no good, small libraries to do that. There were a couple of ridiculously large, complicated libraries that would handle XML files, but you'd lose more time learning the library than you would ever put into your actual code. So I created libxml++, to scratch my own personal itch. It was, at the time, a small but useful wrapper around libxml. Very basic, and demonstrated mostly that I knew less about either C++ or XML than I thought I did.
But people used it. (They also used my CLI Yahoo Messenger client, but that became defunct after I handed it off to other developers, due to the then-rapidly changing Yahoo protocol. The single most touching e-mail I have ever received was from a user of that client.) One of them submitted some patches, and eventually in 2002 I passed off ownership of the libxml++ project to him. I don't code in C++ much anymore, so I don't use my own library, but I do check in on it every so often. There are regular commits, including one last week, and an active mailing list, with several thousand messages. It's in Debian's main package repository and a number of diverse other packages depend on it.
All of this is the result of an itch I had ten years ago. Don't let anyone tell you that this kind of thing never happens and that there are just a billion useless libraries and programs half-written out there. There are a billion of those, but if you have a need for something that nothing on the market seems to fill, the chances are good that you're not alone in that unfilled need. Fill it and make it easy for others to use it and contribute to it, and see where it ends up in 2020.
What seems pretty obvious is that the guy's question is about how to get involved in an OSS initiative, not how to find one. Cultural barriers aside, the perception from the outside is that many existing communities are closed, elitist kingdoms that are unwelcoming and intimidating to newbies. So, while providing a helpful search query may be clever, it does not address the essence of the question and serves to perpetuate the stereotype.
Most communities seem closed because the internet is vast and there are a lot of idiots and trouble makers out there who at best waste time and at worst wreak havoc with a project. Since FOSS projects don't have employment processes and hiring forms, they need mechanisms to make sure they are working with the right people for the job.
Here are some hints to help you get through the initial barrier of egotism end rudeness that many projects use to protect themselves:
1. Join the mailing lists.
2. You may if you like, send an introduction to the mailing lists, but do not say anything else until you get an idea of the culture of the community, what netiquette guidelines do they follow, who is who, and the general tone that people use to address each other. Aslo try to figure out if there is certain sorts of questions the project doesn't like to answer. It's possible they deliberately obscure certain configurations, etc. in order to guarantee consulting income. If you think this wrong, and you want to be some kind of maverick coder vigilante, call them out and publish the tricks widely. If on the other hand you want to be a dev on the project, accept that this is the real world, and these devs are doing enormous good giving this volume of code away, free to use for anybody smart enough and interested enough to figure it out and at small once of consulting fees to those who aren't so inclined. Be kind to them, don't answer questions that seem to fit into this category, don't publish the fixes anywhere, think of it as a gift and keep it in your pocket for your own consulting career.
3. How long you lurk varies greatly from project to project, but it will always be longer for dev lists than for user lists. Once you have figured out the community a bit, start showing your worth by being helpful on those questions that come in to the user list that you can answer. A community is not going to accept code contributions from someone who can't figure out the part of their project that they expect users to be able to understand. So show you understand what they are doing.. At this point, it's probably best to be friendly and helpful, but if it is one of those lists where a lot of the popular (not to be confused with profusive) posters are boastful and have a bit of a bite, it's probably safe to start showing a bit of a swagger already.
You can also use this time to start climbing into the code, get to understand the architecture of the project, the existing coding culture (is code readably formatted, is code commented well, are they cowboys or nazis? When reading about fixes or changes in the dev list, look at the code, try to understand what they are talking about, how it all hangs together.
4. Once you have demonstrated that you understand their project well, are helpful and involved. You have mirrored their preferred modes of behaviour! You already seem like one of them just waiting to be adopted! You start contributing to the dev lists when you've understood the code sufficiently to make a contribution. It doesn't have to be a particularly brilliant contribution. It could be something a 5 year old could have spotted, and you just happen to be the first one to see the incoming mail. Don't write out the full function in perfect code with every excpetion caught, all nicely commented and logging in all the right places. Don't try get commit writes to the project, just formulate a solution, implement rought it in your local copy to make sure it works and describe it on the mailing list. If you've solved the problem correc