9 ms·

Why I still don’t contribute to open source

170 points by phiggy 15y ago

wtn 15y ago
People shouldn't be trying to contribute to open source—you use something, you need to extend it, so you submit your patches upstream. Nothing more.
- wccrawford 15y ago
  I didn't understand your comment before reading the article, but it's perfectly clear afterwards. This guy is trying to do a good deed for the deed's sake, instead of for the sake of the project. No wonder he doesn't get accepted!
  - phillijw 15y ago
    But at the same time there are a lot of people who suggest contributing to open source as a way to practice or give back. Most open source software is already at a level of maturity that it's difficult to find improvements. At the same time, I don't use a lot of open source software on a daily basis which makes it even harder.
- ddlatham 15y ago
  People often recommend contributing to open source projects as a good way to learn and to build your resume and reputation. In that case you're not necessarily motivated by an existing product need.
  - jrockway 15y ago
    <picture of cat with caption that reads, "you're doing it wrong"> Seriously, if you want to engage in some activity to "build your resume" but you can't figure out how to do it... maybe there's a message in there.
  - jarin 15y ago
    Shipping a product (even if it's just a dumb little side project) is way more impressive to most people than contributing a patch to an open source project. I contribute to projects that I use as often as I can, but I've never had to point a potential client to my Github account to land a contract.
    - jrockway 15y ago
      Impressive to the average person, yes, but not impressive to people hiring someone to work on a team. It's great to be able to do whatever you want, but it takes a special kind of person to put their personal tastes aside, open up someone else's work, and fix it. Incidentally, that's what most programming jobs are, and most people are terrible at it.
  - ChuckMcM 15y ago
    I agree with jrockway (but perhaps not the phrasing) that its not an appropriate response to the requirement. People advise new programmers, "Its good to have work on an open source project on your resume." because that gives them access to your check-ins, how you responded to reviews, and generally mailing list chatter. That is invaluable for potential managers since its like having a 'preview' of how you work. However ... When people hear it "Go contribute to some open source project." That is not the correct interpretation. And the reason is that there two conflicting assumptions. The manager person is looking for folks who write code, whether or not it pays the bills. These are people who love to code. So if you're not already writing code, then your already not someone they really want to talk to. If you're writing tons of code in your spare time, but none of it is 'out there', then one of three things might be true; 1) You're one of those people for whom someone elses code is never good enough so you've written everything yourself from scratch, probably have your own mail program, dns server, tcp stack, you name it :-) 2) You are keeping all your code under wraps because someday you're going to sell it as the next version of Office or something for $1000/copy. :-) 3) You can't tell if anyone would even care to use your code even if it was available so you just work on it in isolation. Of these types, if you're #3 the solution is easy, pick a couple of things you're doing, throw them up on github so that there is a copy 'out there' if you need to recover it and you will find people will discover it and start feeding you back comments. If you're #2 you probably aren't going to be a good fit but feel free to create the next Microsoft. Some of the people in #2 will create the next SAP or Salesforce.com or Autocad so don't let me stop you. If you're in group #1 you're possibly a brilliant coder who will argue with everyone :-). When people come to me and ask "How can I get a job at Google?" I ask them what software they are working on. If they answer, "What do you mean?" I explain the whole "If you are someone Google might hire, then you are someone that writes code whether or not you are getting paid for it. If you aren't that type of person then working for Google is probably not high on the list of possibilities (although I hear that is changing).
- sc68cal 15y ago
  Even non-programmers can contribute to open-source software. Proofreading and copy-editing patches are always appreciated - especially if the developers are ESL (English as a Second Language)!
- araneae 15y ago
  It's not always that simple. Sometimes a piece of software has only one instance, and you want to contribute to that particular instance and not the general one. For instance, you may use a particular website or web application, so you would like to improve it. But the people running that project are disorganized or not open other contributions, so you end up just saying "screw it." If this is just software you have installed locally, that makes sense though.
- robryan 15y ago
  There is a lot of stuff where if no one puts there hand up to improve it will just languish because no one really encounters it in a way that motivates them to patch it for their own needs. So a lot of documentation stuff that would require a lot of time to fix up. A good example I guess was PHP6, without reading to much in it it seems that making all the string functions UTF8(16) compatible was one of the very time consuming tasks that didn't have a lot of momentum behind it.
agentultra 15y ago
It’s not obvious where to start. Just ask. If you feel like you are overwhelmed or too inexperienced (maybe not in skill, but just in this project) -- just ask someone. IRC is good if they have a channel or the mailing list if you have to. Just ask for some easy tickets. Read the source, figure out the problem, create a test, make your patch, submit the patch using whatever process they use on the project. This will get you familiar with the source code and their development process at the same time. Trying to contribute and failing makes me feel stupid. Maybe you should take the time to find out why your contributions are being ignored or turned down. You might not get an answer right away, but it doesn't hurt to ask. Internalize the responses you get and adjust your approach accordingly. Few people contribute to open source with the intent of making other people feel stupid. There’s no time. Priorities. It helps if your employer gives you a little time at work to contribute back to open source. But ymmv depending on where you work. Even a couple of hours out of your weekend to squash a bug is appreciated by everyone.
- araneae 15y ago
  I've only tried contributing to OSS once. They had n00b-tagged tasks on pivotal tracker, the problem is they wouldn't give me the permissions to sign-up for that task. Instead they said to claim it on IRC. Except that two other people thought they were the only one doing the same task (because that's a really stupid way of doing it) and I just said "screw it"- it wasn't worth all the drama. I'd just rather just work my own stuff.
  - VMG 15y ago
    That was just a poorly managed open-source project. There are enough of them out there, but not contributing because of only one experience is like saying you won't ever listen to music again because you bought a nickelback album.
  - nl 15y ago
    Don't sign-up to do a task. Write the code, then say you've done it and ask where you should put the source. In my experience running a few open source projects it's all too common to get a random person asking for commit privileged (or whatever) before they actually do anything. Working code has a way of focusing people.
phaylon 15y ago
If those are the hurdles one sees, I'd suggest starting by contributing documentation. It's welcome help in almost all cases, since it's something the people that do know the problem domain in and out often have too little time, and too little need for. Also, as someone who is not yet fully emerged you're in the perfect position to design documentation from the point of a user who isn't familiar with the code base. It usually also consists of small jobs (fixing documentation, keeping it up to date, making sure documented behavior is tested) and bigger projects (tutorials, cookbooks, main manuals). So it's possible to start out small and work your way up. From documentation you can go to testing and code cleanup contributions (X needs a better error message, Y is not the way library L says you should do it anymore) and then, depending on the project, on to larger tasks.
- pbhjpbhj 15y ago
  >If those are the hurdles one sees, I'd suggest starting by contributing documentation. I don't code: for my contribution but instead answer user questions about one of my most used applications. I figure this helps to strengthen the eco-system. When they come up I try to register bugs and be a good FOSS citizen that way. Not trying to blow my own trumpet just suggest alternative options for anyone reading who's not a coder.
aarongough 15y ago
I would suggest starting by creating your own open source projects, that way you get to learn the ropes without anyone hassling you... Once you feel more comfortable you'll contribute to other projects as if they were your own...
jrockway 15y ago
Here's how you contribute to open source. Start writing some software. Use an open source library. One day, something will break. Instead of whining on the bug tracker or hunting for shitty workarounds... open up the library source, delete the bug, make a diff, and send that to the project maintainers with a note like, "I was trying to call foobar, but it segfaults because bazquux is off by one. Patch attached." That's contributing to open source. Alternatively, write some code and share it with people. That's good too.
- pavel_lishin 15y ago
  I just committed a change to someone's library last week. It was like a lightbulb going off in my head - "Oh, so it's just this easy." I wonder how much more difficult this was before Github.
  - davidw 15y ago
    > I wonder how much more difficult this was before Github. Not much. Open source, and... well, software development in general is about people. Github makes it a bit easier, but the basic process is the same. Here are some programs developed before github: Linux, Emacs, X11, Gnome, KDE, Apache, PHP, Tcl, Perl, Python, Ruby. They turned out ok and managed to garner their fair share of contributors.
    - aaronblohowiak 15y ago
      Dealing with weird build chains and getting each projects particular patch acceptance processes correct was pretty annoying. Dynamic languages / more "sane" build systems and "pull requests" have reduced friction, but it is not a categorically different process. The interesting thing is that the friction has been so reduced that GH has made contributing patches upstream my default behavior instead of something I would do if I wanted to commit to being a contributor.
    - pavel_lishin 15y ago
      Sure, but I imagine that actually working on the Linux kernel, making and testing patches, submitting them, and having them accepted was much more difficult. Yes, they turned out okay, but that doesn't mean it wasn't much more difficult, right?
christkv 15y ago
Read the code of your favorite projects, pick some tickets fix some bugs and submit some patches or pull requests :) Most of us who have projects love when get patches as it makes us feel less lonely :)
johnzimmerman 15y ago
openhatch.org and launchpad.net are good sites to look for projects needing help. Take an open source application you use on a daily basis and think of ways you can contribute. Bigger projects may be difficult to dive into, but its always worth a shot.
jjm 15y ago
I'll try to keep this very very short. Every one of your points is grounded in... fear. Fear of X, Y, Z. Just do it friend. Take the plunge, you'll end up learning a lot while engaging in great discussions.
- eropple 15y ago
  Or you'll end up being shat on, from a great height, from people whose credentials largely involve "being there first." (Not all open source projects are like that, fortunately, but running into one or two can sour your view on the whole process.)
  - jjm 15y ago
    As is life. You'll always find people that oppose everything that makes you... you. Religion, politics (<-- oh and i think you know about that one), ethics, money, fighting (Boxing vs MMA), Operating systems... etc. For every several pieces of 'shat' you take, you'll find a couple golden nuggets. Those make the difference, builds character and knowledge. Who knows, it may even help you build the next startup or 'cool app'. Take the plunge!
    - eropple 15y ago
      Hey, I've done it. :p I can understand why others may not, though. It may just not be worth the hassle.
- tehviking 15y ago
  I get it. Unless your life is on the line, fear is a very bad way to make a decision. I would say more "exasperation and confusion". But your point is extremely well taken.
akozak 15y ago
Try openhatch.org. It's a startup with the intent to make contributing to open source easier for newbies.
DasIch 15y ago
Don't contribute to open source for the sake of contributing, contribute because you are excited about something. Implement this feature you always wanted to have, fix this bug which has been annoying for who knows how long and you will be motivated and excited which is pretty much a prerequisite. Also if you want to contribute to a project get to know the community around it, find out who is responsible for what and use this knowledge to talk directly to the people who are working on the stuff you are interested in. If you want to be in for the long run, no amount of posting tickets to the mailing list will make you a member of the community. A discussion in the development IRC channel, no matter if it's about the latest piece of tech, Portal 2 which just came out or our all time favorite the best editor, will teach you more about the community in a couple of minutes than any amount of posting tickets to the bug tracker will. Despite the stereotype of the autistic geek this sort of socializing is an important part of any project with a healthy community, if you want to contribute to open source you should be aware of that.
wycats 15y ago
Having contributed to a number of open source projects in the past, I definitely feel the pain. In order to help people get up to speed with SproutCore, we just released a four-part screencast and guide for contributing to the various parts of the framework. http://blog.sproutcore.com/post/5166266734/dispatch-from-the-edge-contributing-to-sproutcore http://blog.sproutcore.com/post/5166266734/dispatch-from-the...
- _pius 15y ago
  Having contributed to a number of open source projects in the past ... Understatement of the day. https://github.com/wycats https://github.com/wycats
briancurtin 15y ago
> There’s no certification, ceremony, or merit badge that says, “you’re ready to contribute to OSS”. I strongly believe that everyone, and I mean everyone, is ready to contribute to OSS. On the Python project, Jesse Noller recently started a "core mentorship" group to help people put the rubber to the road. There's an almost endless amount of work to be done on CPython, and we'll literally take anyone with any amount of knowledge and help them contribute. Whether it's people contributing to OSS for the first time, or people new to contributing to Python, we can find something. If you understand English, you can write documentation. If you can write Python code, which is obviously a common skill for someone interested in contributing to Python, there's plenty of work. If you know C, dig right in. The group of core contributors ranges from 18 to the upper 60s, from the self-taught to multi-PhDs, from students to Googlers. I think the only people who aren't ready to contribute, wouldn't be interested in contributing in the first place. > It’s not obvious where to start. This is definitely an issue for a lot of projects, and as mentioned above for CPython, the core mentorship group is hoping to tackle this. Online and in person, I've pointed countless amounts of newcomers to the "easy" bugs list on our tracker, but that's not always a great starting point. Half of the issues are a 35 comment bikeshed, but it's tagged as "easy" because the end result will probably be a 2 line change. The other half of the issues are easy, but in uninteresting corners of obscure modules. I've had success leading newcomers at the PyCon sprint to start with test coverage, and I think that approach worked pretty well. You can't get too far without writing tests anyways, so it's a good educational step that you can even take back to your day job if you aren't already doing so. Additionally, it's a task that gives you a tangible sense of accomplishment. Being able to fix bugs is cool, but often they are very low impact. Being able to say you raised test coverage from 30% to 70% is nothing to shrug at. Having early success is key to having continued fun on the project. No one wants to spend their evening working on a patch to have it rejected and shot down -- that's not fun. My approach, and one I also suggest to some first-timers, is to start with documentation. You can bang out 10 successful doc patches a lot easier than you can do 10 successful code changes. In order to get some attention to yourself, find the easiest way in the team and stick with it a bit before branching out. > Guidelines often make a maintainer’s life easier, and mine harder. I can certainly feel for this, and speaking for CPython, I think we've tried to keep the guidelines simple and well documented. Overall, the process doesn't deviate too far from "write it, review it, commit it", when it comes to being an external contributor. Once you have commit access, some of the source control process gets hairy, but it mostly stays out of your way and lets you do the work. > Open source is for people who are better at this than me. I'd put myself on the bottom of the pile both on the CPython team and at my day job. I told my dad programming was stupid when I was in high school, I barely got by in college, and finally found myself the first year on the job. I'm not a bad developer by any means, but I'm not blowing the doors off of companies when I interview with them. I just like what I do and I have fun doing it -- I think a lot of the people involved in this stuff are probably the same way. > Trying to contribute and failing makes me feel stupid. Failure sucks, straight up. It especially sucks when it's on an open source project that you're trying to help in your free time outside of work. It's not news that you're going to fail from time to time, but something that worked for me and apparently some people I've helped was choosing the right thing to work on. I touched on it earlier, but fixing 5 small easy things sometimes looks better to a maintainer than fixing 1 regular thing. If you start with that approach, soon you'll have 15 successful pull requests and may feel more confident to dive into deeper and harder things, and the maintainer may have more confidence that you can offer quality work for those harder things. > There’s no time. Time is the biggest bottleneck in open source. Not only do you have a kid, job, and responsibilities, everyone else does too. Submitting a patch or a pull request only to have it sit un-noticed for months sucks. The only way to get it through the system is more time. I don't know of any really good solutions on the maintainer side other than quitting everything and going full steam on the project, but that's clearly not viable :) > It’s pretty lonely. The CPython core mentors group aims to fix that. I don't remember the numbers off the top of my head, but the ratio of core contributors to new outsiders is pretty tight, and we've helped a bunch of interested contributors get their work accepted. Your average 1-man project might not be able to do this, but we've tried to make a group available for those who need a helping hand on Python.
generalk 15y ago
What a lot of folks might not get is that there isn't one thing that can be called "contributing to Open Source", which is why setting that as a goal is somewhat vague and difficult to accomplish. If you can find a project that you want to contribute to, then that's awesome. If you can't, that's understandable. > There’s no certification, ceremony, or merit badge That's part of the point. Anyone can code, design, document, whatever. There's nobody telling you you're ready and there's nobody telling you you can't. > It’s not obvious where to start. If you don't have an obvious starting point, that's okay. Most Open Source contributions are coders solving problems that interest them. If you don't have one of those right now, that's no big deal. Not contributing to open source isn't the end of the world, it's just one of many ways to sharpen your skills. > Open source is for people who are > better at this than me. Gotta start somewhere though. In my experience, a project's owner usually gives invaluable feedback if you send in a patch that isn't quite there yet. > Trying to contribute and failing makes me feel stupid. I have the same problem. For lots of projects, I'll never meet the maintainers, so I just hold my breath and click send. What's the worst that could happen?
- Deestan 15y ago
  > > Trying to contribute and failing makes me feel stupid. > I have the same problem. For lots of projects, I'll never meet the maintainers, so I just hold my breath and click send. What's the worst that could happen? You can get a gruff rejection by a (clearly) skilled developer, which unless you have a big ego acting as buffer, will make you doubt whether you are cut out for programming at all. This again will hurt your enthusiasm and make you stop working on hobby projects (what's the point?) for weeks, or even months if you are already insecure or slightly depressed.
jcapote 15y ago
Sounds like the author is just making excuses to rationalize his laziness/fear.
- eropple 15y ago
  Alternatively, maybe attitudes like yours are the problem. Look in the mirror.
- tehviking 15y ago
  This is a terrifyingly accurate assessment. You've drilled into the focus of the article: 1. I'm too lazy to overcome the inertia of not knowing what to do next 2. I'm too scared of rejection or looking dumb The resulting question is: is there an onus on the community to provide additional tools to help the lazy/scared people like me push through these barriers? My opinion is "yes, within limits", but I would also understand if someone said "no".
  - eropple 15y ago
    And I assume you would then also understand if people had better things to do than be shat on by that community (in the case of #2). #1 is simply false; when there is little context for how to contribute it is completely understandable that someone may be paralyzed by indecision. It has nothing to do with laziness. Contributing to open-source projects is, in my experience, often more trouble than it's worth--precisely because all too often the people already involved have forgotten (or never had the social capability to know and understand) that #1 is a falsehood and #2 is an eminently reasonable reaction for any remotely normal human being. I still contribute to some projects, but only projects that I or close personal friends maintain. It allows me to tell them to unscrew their heads when they act like the grandparent poster.
    - tehviking 15y ago
      Yeah, I understand and empathize with your viewpoint. I wrote the article and felt like the detractor captured some of the weaknesses I possess that led to its writing.
SoftwareMaven 15y ago
After developing software for 15 years, I submitted my first patch to an open source project yesterday, and it was because I needed the functionality for my day job (being able to actually stream AES CTR and HMAC in Erlang). Somehow, I've managed to be successful in my job without many commits. Don't beat yourself up if you aren't a contributor. Can it be valuable and fun? Yes. Is it a requirement to succeed? No. Life is for living, not checking off boxes other people say are important. Have fun with that kid, that will likely be far more rewarding than any patch!
- andos 15y ago
  Yes! People think that contributing to OSS is some kind of moral duty. OSS is not a cancer hospital for kids. Do you work on a project that depends on OSS? There will be bugs (lots of bugs — OSS is generous in this regard) and the need to contribute will arise naturally. Or else. You don't? Why bother? Go help the local cancer hospital for kids instead.
technomancy 15y ago
If you're finding it difficult to contribute to a project, the odds are way in favour of this pointing to a deficiency in the way the project is run rather than any shortcoming of your own.
Cyranix 15y ago
I had this same sentiment within the past few days, as I resolved to finally get involved in an open source project. I'm grateful for the mentions of OpenHatch and Launchpad -- I started with Github, and for as much as I enjoy the site, I felt like the emphasis on popular projects made it harder to find a place for a relative newbie to get involved. I seriously doubt that I'm enough of a JS ninja to add value to a project as thoroughly picked-over as jQuery, so seeing it listed repeatedly as a suggested repo was disheartening. I accept the advice of other commenters who say that contributing to OSS becomes much more natural when you're actively using a library in your own project and stumble across a bug or feature idea... but not all of us have those projects, and I think that's okay.
mark_h 15y ago
> It’s not obvious where to start. This is coming up again and again; this blog post is another data point I read recently, about a couple of projects dedicating time specifically to get potential new contributors up and running: http://blog.lydiapintscher.de/2011/04/18/how-vidalia-and-gimp-found-new-contributors-just-by-asking/ http://blog.lydiapintscher.de/2011/04/18/how-vidalia-and-gim...
michaelochurch 15y ago
The problem with many OS projects is that being distributed leads to isolation. Obviously, OS projects need to accept input worldwide, but they should work more to establish cores in major cities (San Francisco, New York, London) that meet once a month, and have "hackathons", on the weekends. A lot of communication that really can't happen through Git and mailing lists would occur, and the projects would come out a lot better. In-person interaction between developers, as much as is possible, would really help these projects a lot.
jamesbritt 15y ago
BTW, for those who do not feel up to hacking code for patches, please consider adding documentation. It's bastard child of OSS, the task often no one, even the code creator, wants to do.
deleted 15y ago
[deleted]
singular 15y ago
I absolutely felt the same, but basically made myself take a look at the go[1] issue tracker[2], before just committing to working on a bug. Once I got one fixed, it was an amazing feeling - I can contribute to this project that is run by people from goddamn bell labs, legends in the industry[3], etc. - though my contribution may be small, I was able to fix something. Getting past that first hurdle was just amazing Theeeeeeen I tried a more serious bug[4] - the only high-priority one in the whole tracker which hadn't been solved for over a year (yeah. Maybe a bit over-ambitious). After hours of learning C and the codebase (my day job is as a financial CRUD C#-er) I was able to find a way to fix it :-) It has genuinely been a voyage into the unknown and taken quite some effort + despite feeling utterly not up to the task, but being able to contribute even minor changes to a project you believe in is just the most amazing thing, really. So I am with @briancurtin on this one - just push yourself to try it, it's genuinely worth it. Knowing you contributed something to a project you care about is just damn awesome. Seriously :) [1]:http://golang.org http://golang.org [2]:http://code.google.com/p/go/issues/list http://code.google.com/p/go/issues/list [3]:http://en.wikipedia.org/wiki/Rob_Pike http://en.wikipedia.org/wiki/Rob_Pike [4]:http://code.google.com/p/go/issues/detail?id=667 http://code.google.com/p/go/issues/detail?id=667
- singular 15y ago
  For those who are interested, I just blogged about the patch I made[1] :) [1]:http://www.codegrunt.co.uk/2011/05/04/Forward-Referenced-Recursive-Types-In-Go.html http://www.codegrunt.co.uk/2011/05/04/Forward-Referenced-Rec...
zmmmmm 15y ago
You definitely need to adopt a reasonably thick skin when contributing. I've had many patches flat out ignored (literally no response at all from the mailing list despite other discussions going on around it), I've had patches interpreted as a kind of subversive / ideological attack on the project (usually it's a feature or issue that was discussed before and you're unknowingly picking at an old sore) and rejected. What amazes me most though is that while I've had plenty of positive comments from other users of the projects I've contributed, not once have I ever had a project maintainer say "Thank you". I can understand this from some perspectives (they created the whole project and gave it to you, and now they have to do more work to accept your patch for something they probably don't need themselves - so saying thank you in return for one tiny patch seems very asymmetrical). Nonetheless, it surprises me that simple words of encouragement are often so lacking from the open source movement. At a human level it feels very strange to spend hours working on something for free, to give it as a gesture of good will to a community of people you thought were your friends and get a response somewhere between neutral and hostile. Nonetheless, the rewarding feeling from patches I've had accepted has outweighed all negatives, so I can highly recommending just putting on your thick skin and going out there and trying.
mv1 15y ago
I would add to the list "It is too frustrating". I've contributed to several open source projects in the past (Linux kernel, gnome, etc.), but doing so is hard work, even if the changes are trivial and you don't have a reputation in the community for the project. Most recently, it took almost a dozen emails over 4 days among 3 different people to get a 3 line patch committed to a driver. The truth is contributing to open source is a social problem. You have to get to know the maintainers, build their trust, and over time, it gets easier to get patches in. If you can meet the maintainer for an hour or so at a conference, it lowers the bar but maintainers of popular projects are often swamped at these events. More often than not it is easier to fix the bug for yourself and move on, using git to keep up to date with new releases.
tehviking 15y ago
If you want people to show you how to contribute to open source, be an internet loudmouth and complain that you don't know how to contribute to open source. Seriously, these are amazing comments and I hope it's OK if I compile the best ideas into another post for others who are as adrift as I sometimes feel.
leon_ 15y ago
> Open source is for people who are better at this than me. If you think that then you're possibly better than the most people contributing to OSS. Just look up http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
nwmcsween 15y ago
A very important rule in almost all OSS projects: have a thick skin. There is usually a few abrasive and argumentative people that derail good development due to ego or trivial issues, avoid projects with people like this.
shaggyfrog 15y ago
For me the biggest problem I have contributing to OSS projects -- and something not mentioned in the article -- is dealing with politicking/egos.
deleted 15y ago
[deleted]
pbiggar 15y ago
For Mozilla, we're trying to improve a lot of the things being discussed on this page, and make it really easy for contributors to get involved. If you've ever wanted to contributor to Mozilla, go here: https://developer.mozilla.org/En/Introduction https://developer.mozilla.org/En/Introduction (feedback very welcome)
Hisoka 15y ago
Life is too short to spend any enormous amt of time on an OSS project. Invest your skills into your own business, and reap the rewards of it.

170 points by phiggy 15y ago

wtn 15y ago

People shouldn't be trying to contribute to open source—you use something, you need to extend it, so you submit your patches upstream. Nothing more.

wccrawford 15y ago
I didn't understand your comment before reading the article, but it's perfectly clear afterwards. This guy is trying to do a good deed for the deed's sake, instead of for the sake of the project. No wonder he doesn't get accepted!
- phillijw 15y ago
  But at the same time there are a lot of people who suggest contributing to open source as a way to practice or give back. Most open source software is already at a level of maturity that it's difficult to find improvements. At the same time, I don't use a lot of open source software on a daily basis which makes it even harder.
ddlatham 15y ago
People often recommend contributing to open source projects as a good way to learn and to build your resume and reputation. In that case you're not necessarily motivated by an existing product need.
- jrockway 15y ago
  <picture of cat with caption that reads, "you're doing it wrong"> Seriously, if you want to engage in some activity to "build your resume" but you can't figure out how to do it... maybe there's a message in there.
- jarin 15y ago
  Shipping a product (even if it's just a dumb little side project) is way more impressive to most people than contributing a patch to an open source project. I contribute to projects that I use as often as I can, but I've never had to point a potential client to my Github account to land a contract.
  - jrockway 15y ago
    Impressive to the average person, yes, but not impressive to people hiring someone to work on a team. It's great to be able to do whatever you want, but it takes a special kind of person to put their personal tastes aside, open up someone else's work, and fix it. Incidentally, that's what most programming jobs are, and most people are terrible at it.
- ChuckMcM 15y ago
  I agree with jrockway (but perhaps not the phrasing) that its not an appropriate response to the requirement. People advise new programmers, "Its good to have work on an open source project on your resume." because that gives them access to your check-ins, how you responded to reviews, and generally mailing list chatter. That is invaluable for potential managers since its like having a 'preview' of how you work. However ... When people hear it "Go contribute to some open source project." That is not the correct interpretation. And the reason is that there two conflicting assumptions. The manager person is looking for folks who write code, whether or not it pays the bills. These are people who love to code. So if you're not already writing code, then your already not someone they really want to talk to. If you're writing tons of code in your spare time, but none of it is 'out there', then one of three things might be true; 1) You're one of those people for whom someone elses code is never good enough so you've written everything yourself from scratch, probably have your own mail program, dns server, tcp stack, you name it :-) 2) You are keeping all your code under wraps because someday you're going to sell it as the next version of Office or something for $1000/copy. :-) 3) You can't tell if anyone would even care to use your code even if it was available so you just work on it in isolation. Of these types, if you're #3 the solution is easy, pick a couple of things you're doing, throw them up on github so that there is a copy 'out there' if you need to recover it and you will find people will discover it and start feeding you back comments. If you're #2 you probably aren't going to be a good fit but feel free to create the next Microsoft. Some of the people in #2 will create the next SAP or Salesforce.com or Autocad so don't let me stop you. If you're in group #1 you're possibly a brilliant coder who will argue with everyone :-). When people come to me and ask "How can I get a job at Google?" I ask them what software they are working on. If they answer, "What do you mean?" I explain the whole "If you are someone Google might hire, then you are someone that writes code whether or not you are getting paid for it. If you aren't that type of person then working for Google is probably not high on the list of possibilities (although I hear that is changing).
sc68cal 15y ago
Even non-programmers can contribute to open-source software. Proofreading and copy-editing patches are always appreciated - especially if the developers are ESL (English as a Second Language)!
araneae 15y ago
It's not always that simple. Sometimes a piece of software has only one instance, and you want to contribute to that particular instance and not the general one. For instance, you may use a particular website or web application, so you would like to improve it. But the people running that project are disorganized or not open other contributions, so you end up just saying "screw it." If this is just software you have installed locally, that makes sense though.
robryan 15y ago
There is a lot of stuff where if no one puts there hand up to improve it will just languish because no one really encounters it in a way that motivates them to patch it for their own needs. So a lot of documentation stuff that would require a lot of time to fix up. A good example I guess was PHP6, without reading to much in it it seems that making all the string functions UTF8(16) compatible was one of the very time consuming tasks that didn't have a lot of momentum behind it.

agentultra 15y ago

It’s not obvious where to start. Just ask. If you feel like you are overwhelmed or too inexperienced (maybe not in skill, but just in this project) -- just ask someone. IRC is good if they have a channel or the mailing list if you have to. Just ask for some easy tickets. Read the source, figure out the problem, create a test, make your patch, submit the patch using whatever process they use on the project. This will get you familiar with the source code and their development process at the same time. Trying to contribute and failing makes me feel stupid. Maybe you should take the time to find out why your contributions are being ignored or turned down. You might not get an answer right away, but it doesn't hurt to ask. Internalize the responses you get and adjust your approach accordingly. Few people contribute to open source with the intent of making other people feel stupid. There’s no time. Priorities. It helps if your employer gives you a little time at work to contribute back to open source. But ymmv depending on where you work. Even a couple of hours out of your weekend to squash a bug is appreciated by everyone.

araneae 15y ago
I've only tried contributing to OSS once. They had n00b-tagged tasks on pivotal tracker, the problem is they wouldn't give me the permissions to sign-up for that task. Instead they said to claim it on IRC. Except that two other people thought they were the only one doing the same task (because that's a really stupid way of doing it) and I just said "screw it"- it wasn't worth all the drama. I'd just rather just work my own stuff.
- VMG 15y ago
  That was just a poorly managed open-source project. There are enough of them out there, but not contributing because of only one experience is like saying you won't ever listen to music again because you bought a nickelback album.
- nl 15y ago
  Don't sign-up to do a task. Write the code, then say you've done it and ask where you should put the source. In my experience running a few open source projects it's all too common to get a random person asking for commit privileged (or whatever) before they actually do anything. Working code has a way of focusing people.

phaylon 15y ago

If those are the hurdles one sees, I'd suggest starting by contributing documentation. It's welcome help in almost all cases, since it's something the people that do know the problem domain in and out often have too little time, and too little need for. Also, as someone who is not yet fully emerged you're in the perfect position to design documentation from the point of a user who isn't familiar with the code base. It usually also consists of small jobs (fixing documentation, keeping it up to date, making sure documented behavior is tested) and bigger projects (tutorials, cookbooks, main manuals). So it's possible to start out small and work your way up. From documentation you can go to testing and code cleanup contributions (X needs a better error message, Y is not the way library L says you should do it anymore) and then, depending on the project, on to larger tasks.

pbhjpbhj 15y ago
>If those are the hurdles one sees, I'd suggest starting by contributing documentation. I don't code: for my contribution but instead answer user questions about one of my most used applications. I figure this helps to strengthen the eco-system. When they come up I try to register bugs and be a good FOSS citizen that way. Not trying to blow my own trumpet just suggest alternative options for anyone reading who's not a coder.

aarongough 15y ago

I would suggest starting by creating your own open source projects, that way you get to learn the ropes without anyone hassling you... Once you feel more comfortable you'll contribute to other projects as if they were your own...

jrockway 15y ago

Here's how you contribute to open source. Start writing some software. Use an open source library. One day, something will break. Instead of whining on the bug tracker or hunting for shitty workarounds... open up the library source, delete the bug, make a diff, and send that to the project maintainers with a note like, "I was trying to call foobar, but it segfaults because bazquux is off by one. Patch attached." That's contributing to open source. Alternatively, write some code and share it with people. That's good too.

pavel_lishin 15y ago
I just committed a change to someone's library last week. It was like a lightbulb going off in my head - "Oh, so it's just this easy." I wonder how much more difficult this was before Github.
- davidw 15y ago
  > I wonder how much more difficult this was before Github. Not much. Open source, and... well, software development in general is about people. Github makes it a bit easier, but the basic process is the same. Here are some programs developed before github: Linux, Emacs, X11, Gnome, KDE, Apache, PHP, Tcl, Perl, Python, Ruby. They turned out ok and managed to garner their fair share of contributors.
  - aaronblohowiak 15y ago
    Dealing with weird build chains and getting each projects particular patch acceptance processes correct was pretty annoying. Dynamic languages / more "sane" build systems and "pull requests" have reduced friction, but it is not a categorically different process. The interesting thing is that the friction has been so reduced that GH has made contributing patches upstream my default behavior instead of something I would do if I wanted to commit to being a contributor.
  - pavel_lishin 15y ago
    Sure, but I imagine that actually working on the Linux kernel, making and testing patches, submitting them, and having them accepted was much more difficult. Yes, they turned out okay, but that doesn't mean it wasn't much more difficult, right?

christkv 15y ago

Read the code of your favorite projects, pick some tickets fix some bugs and submit some patches or pull requests :) Most of us who have projects love when get patches as it makes us feel less lonely :)

johnzimmerman 15y ago

openhatch.org and launchpad.net are good sites to look for projects needing help. Take an open source application you use on a daily basis and think of ways you can contribute. Bigger projects may be difficult to dive into, but its always worth a shot.

jjm 15y ago

I'll try to keep this very very short. Every one of your points is grounded in... fear. Fear of X, Y, Z. Just do it friend. Take the plunge, you'll end up learning a lot while engaging in great discussions.

eropple 15y ago
Or you'll end up being shat on, from a great height, from people whose credentials largely involve "being there first." (Not all open source projects are like that, fortunately, but running into one or two can sour your view on the whole process.)
- jjm 15y ago
  As is life. You'll always find people that oppose everything that makes you... you. Religion, politics (<-- oh and i think you know about that one), ethics, money, fighting (Boxing vs MMA), Operating systems... etc. For every several pieces of 'shat' you take, you'll find a couple golden nuggets. Those make the difference, builds character and knowledge. Who knows, it may even help you build the next startup or 'cool app'. Take the plunge!
  - eropple 15y ago
    Hey, I've done it. :p I can understand why others may not, though. It may just not be worth the hassle.
tehviking 15y ago
I get it. Unless your life is on the line, fear is a very bad way to make a decision. I would say more "exasperation and confusion". But your point is extremely well taken.

akozak 15y ago

Try openhatch.org. It's a startup with the intent to make contributing to open source easier for newbies.

DasIch 15y ago

Don't contribute to open source for the sake of contributing, contribute because you are excited about something. Implement this feature you always wanted to have, fix this bug which has been annoying for who knows how long and you will be motivated and excited which is pretty much a prerequisite. Also if you want to contribute to a project get to know the community around it, find out who is responsible for what and use this knowledge to talk directly to the people who are working on the stuff you are interested in. If you want to be in for the long run, no amount of posting tickets to the mailing list will make you a member of the community. A discussion in the development IRC channel, no matter if it's about the latest piece of tech, Portal 2 which just came out or our all time favorite the best editor, will teach you more about the community in a couple of minutes than any amount of posting tickets to the bug tracker will. Despite the stereotype of the autistic geek this sort of socializing is an important part of any project with a healthy community, if you want to contribute to open source you should be aware of that.

wycats 15y ago

Having contributed to a number of open source projects in the past, I definitely feel the pain. In order to help people get up to speed with SproutCore, we just released a four-part screencast and guide for contributing to the various parts of the framework. http://blog.sproutcore.com/post/5166266734/dispatch-from-the-edge-contributing-to-sproutcore http://blog.sproutcore.com/post/5166266734/dispatch-from-the...

_pius 15y ago
Having contributed to a number of open source projects in the past ... Understatement of the day. https://github.com/wycats https://github.com/wycats

briancurtin 15y ago

> There’s no certification, ceremony, or merit badge that says, “you’re ready to contribute to OSS”. I strongly believe that everyone, and I mean everyone, is ready to contribute to OSS. On the Python project, Jesse Noller recently started a "core mentorship" group to help people put the rubber to the road. There's an almost endless amount of work to be done on CPython, and we'll literally take anyone with any amount of knowledge and help them contribute. Whether it's people contributing to OSS for the first time, or people new to contributing to Python, we can find something. If you understand English, you can write documentation. If you can write Python code, which is obviously a common skill for someone interested in contributing to Python, there's plenty of work. If you know C, dig right in. The group of core contributors ranges from 18 to the upper 60s, from the self-taught to multi-PhDs, from students to Googlers. I think the only people who aren't ready to contribute, wouldn't be interested in contributing in the first place. > It’s not obvious where to start. This is definitely an issue for a lot of projects, and as mentioned above for CPython, the core mentorship group is hoping to tackle this. Online and in person, I've pointed countless amounts of newcomers to the "easy" bugs list on our tracker, but that's not always a great starting point. Half of the issues are a 35 comment bikeshed, but it's tagged as "easy" because the end result will probably be a 2 line change. The other half of the issues are easy, but in uninteresting corners of obscure modules. I've had success leading newcomers at the PyCon sprint to start with test coverage, and I think that approach worked pretty well. You can't get too far without writing tests anyways, so it's a good educational step that you can even take back to your day job if you aren't already doing so. Additionally, it's a task that gives you a tangible sense of accomplishment. Being able to fix bugs is cool, but often they are very low impact. Being able to say you raised test coverage from 30% to 70% is nothing to shrug at. Having early success is key to having continued fun on the project. No one wants to spend their evening working on a patch to have it rejected and shot down -- that's not fun. My approach, and one I also suggest to some first-timers, is to start with documentation. You can bang out 10 successful doc patches a lot easier than you can do 10 successful code changes. In order to get some attention to yourself, find the easiest way in the team and stick with it a bit before branching out. > Guidelines often make a maintainer’s life easier, and mine harder. I can certainly feel for this, and speaking for CPython, I think we've tried to keep the guidelines simple and well documented. Overall, the process doesn't deviate too far from "write it, review it, commit it", when it comes to being an external contributor. Once you have commit access, some of the source control process gets hairy, but it mostly stays out of your way and lets you do the work. > Open source is for people who are better at this than me. I'd put myself on the bottom of the pile both on the CPython team and at my day job. I told my dad programming was stupid when I was in high school, I barely got by in college, and finally found myself the first year on the job. I'm not a bad developer by any means, but I'm not blowing the doors off of companies when I interview with them. I just like what I do and I have fun doing it -- I think a lot of the people involved in this stuff are probably the same way. > Trying to contribute and failing makes me feel stupid. Failure sucks, straight up. It especially sucks when it's on an open source project that you're trying to help in your free time outside of work. It's not news that you're going to fail from time to time, but something that worked for me and apparently some people I've helped was choosing the right thing to work on. I touched on it earlier, but fixing 5 small easy things sometimes looks better to a maintainer than fixing 1 regular thing. If you start with that approach, soon you'll have 15 successful pull requests and may feel more confident to dive into deeper and harder things, and the maintainer may have more confidence that you can offer quality work for those harder things. > There’s no time. Time is the biggest bottleneck in open source. Not only do you have a kid, job, and responsibilities, everyone else does too. Submitting a patch or a pull request only to have it sit un-noticed for months sucks. The only way to get it through the system is more time. I don't know of any really good solutions on the maintainer side other than quitting everything and going full steam on the project, but that's clearly not viable :) > It’s pretty lonely. The CPython core mentors group aims to fix that. I don't remember the numbers off the top of my head, but the ratio of core contributors to new outsiders is pretty tight, and we've helped a bunch of interested contributors get their work accepted. Your average 1-man project might not be able to do this, but we've tried to make a group available for those who need a helping hand on Python.

generalk 15y ago

What a lot of folks might not get is that there isn't one thing that can be called "contributing to Open Source", which is why setting that as a goal is somewhat vague and difficult to accomplish. If you can find a project that you want to contribute to, then that's awesome. If you can't, that's understandable. > There’s no certification, ceremony, or merit badge That's part of the point. Anyone can code, design, document, whatever. There's nobody telling you you're ready and there's nobody telling you you can't. > It’s not obvious where to start. If you don't have an obvious starting point, that's okay. Most Open Source contributions are coders solving problems that interest them. If you don't have one of those right now, that's no big deal. Not contributing to open source isn't the end of the world, it's just one of many ways to sharpen your skills. > Open source is for people who are > better at this than me. Gotta start somewhere though. In my experience, a project's owner usually gives invaluable feedback if you send in a patch that isn't quite there yet. > Trying to contribute and failing makes me feel stupid. I have the same problem. For lots of projects, I'll never meet the maintainers, so I just hold my breath and click send. What's the worst that could happen?

Deestan 15y ago
> > Trying to contribute and failing makes me feel stupid. > I have the same problem. For lots of projects, I'll never meet the maintainers, so I just hold my breath and click send. What's the worst that could happen? You can get a gruff rejection by a (clearly) skilled developer, which unless you have a big ego acting as buffer, will make you doubt whether you are cut out for programming at all. This again will hurt your enthusiasm and make you stop working on hobby projects (what's the point?) for weeks, or even months if you are already insecure or slightly depressed.

jcapote 15y ago

Sounds like the author is just making excuses to rationalize his laziness/fear.

eropple 15y ago
Alternatively, maybe attitudes like yours are the problem. Look in the mirror.
tehviking 15y ago
This is a terrifyingly accurate assessment. You've drilled into the focus of the article: 1. I'm too lazy to overcome the inertia of not knowing what to do next 2. I'm too scared of rejection or looking dumb The resulting question is: is there an onus on the community to provide additional tools to help the lazy/scared people like me push through these barriers? My opinion is "yes, within limits", but I would also understand if someone said "no".
- eropple 15y ago
  And I assume you would then also understand if people had better things to do than be shat on by that community (in the case of #2). #1 is simply false; when there is little context for how to contribute it is completely understandable that someone may be paralyzed by indecision. It has nothing to do with laziness. Contributing to open-source projects is, in my experience, often more trouble than it's worth--precisely because all too often the people already involved have forgotten (or never had the social capability to know and understand) that #1 is a falsehood and #2 is an eminently reasonable reaction for any remotely normal human being. I still contribute to some projects, but only projects that I or close personal friends maintain. It allows me to tell them to unscrew their heads when they act like the grandparent poster.
  - tehviking 15y ago
    Yeah, I understand and empathize with your viewpoint. I wrote the article and felt like the detractor captured some of the weaknesses I possess that led to its writing.

SoftwareMaven 15y ago

After developing software for 15 years, I submitted my first patch to an open source project yesterday, and it was because I needed the functionality for my day job (being able to actually stream AES CTR and HMAC in Erlang). Somehow, I've managed to be successful in my job without many commits. Don't beat yourself up if you aren't a contributor. Can it be valuable and fun? Yes. Is it a requirement to succeed? No. Life is for living, not checking off boxes other people say are important. Have fun with that kid, that will likely be far more rewarding than any patch!

andos 15y ago
Yes! People think that contributing to OSS is some kind of moral duty. OSS is not a cancer hospital for kids. Do you work on a project that depends on OSS? There will be bugs (lots of bugs — OSS is generous in this regard) and the need to contribute will arise naturally. Or else. You don't? Why bother? Go help the local cancer hospital for kids instead.

technomancy 15y ago

If you're finding it difficult to contribute to a project, the odds are way in favour of this pointing to a deficiency in the way the project is run rather than any shortcoming of your own.

Cyranix 15y ago

I had this same sentiment within the past few days, as I resolved to finally get involved in an open source project. I'm grateful for the mentions of OpenHatch and Launchpad -- I started with Github, and for as much as I enjoy the site, I felt like the emphasis on popular projects made it harder to find a place for a relative newbie to get involved. I seriously doubt that I'm enough of a JS ninja to add value to a project as thoroughly picked-over as jQuery, so seeing it listed repeatedly as a suggested repo was disheartening. I accept the advice of other commenters who say that contributing to OSS becomes much more natural when you're actively using a library in your own project and stumble across a bug or feature idea... but not all of us have those projects, and I think that's okay.

mark_h 15y ago

> It’s not obvious where to start. This is coming up again and again; this blog post is another data point I read recently, about a couple of projects dedicating time specifically to get potential new contributors up and running: http://blog.lydiapintscher.de/2011/04/18/how-vidalia-and-gimp-found-new-contributors-just-by-asking/ http://blog.lydiapintscher.de/2011/04/18/how-vidalia-and-gim...

michaelochurch 15y ago

The problem with many OS projects is that being distributed leads to isolation. Obviously, OS projects need to accept input worldwide, but they should work more to establish cores in major cities (San Francisco, New York, London) that meet once a month, and have "hackathons", on the weekends. A lot of communication that really can't happen through Git and mailing lists would occur, and the projects would come out a lot better. In-person interaction between developers, as much as is possible, would really help these projects a lot.

jamesbritt 15y ago

BTW, for those who do not feel up to hacking code for patches, please consider adding documentation. It's bastard child of OSS, the task often no one, even the code creator, wants to do.

deleted 15y ago

[deleted]

singular 15y ago

I absolutely felt the same, but basically made myself take a look at the go[1] issue tracker[2], before just committing to working on a bug. Once I got one fixed, it was an amazing feeling - I can contribute to this project that is run by people from goddamn bell labs, legends in the industry[3], etc. - though my contribution may be small, I was able to fix something. Getting past that first hurdle was just amazing Theeeeeeen I tried a more serious bug[4] - the only high-priority one in the whole tracker which hadn't been solved for over a year (yeah. Maybe a bit over-ambitious). After hours of learning C and the codebase (my day job is as a financial CRUD C#-er) I was able to find a way to fix it :-) It has genuinely been a voyage into the unknown and taken quite some effort + despite feeling utterly not up to the task, but being able to contribute even minor changes to a project you believe in is just the most amazing thing, really. So I am with @briancurtin on this one - just push yourself to try it, it's genuinely worth it. Knowing you contributed something to a project you care about is just damn awesome. Seriously :) [1]:http://golang.org http://golang.org [2]:http://code.google.com/p/go/issues/list http://code.google.com/p/go/issues/list [3]:http://en.wikipedia.org/wiki/Rob_Pike http://en.wikipedia.org/wiki/Rob_Pike [4]:http://code.google.com/p/go/issues/detail?id=667 http://code.google.com/p/go/issues/detail?id=667

singular 15y ago
For those who are interested, I just blogged about the patch I made[1] :) [1]:http://www.codegrunt.co.uk/2011/05/04/Forward-Referenced-Recursive-Types-In-Go.html http://www.codegrunt.co.uk/2011/05/04/Forward-Referenced-Rec...

zmmmmm 15y ago

You definitely need to adopt a reasonably thick skin when contributing. I've had many patches flat out ignored (literally no response at all from the mailing list despite other discussions going on around it), I've had patches interpreted as a kind of subversive / ideological attack on the project (usually it's a feature or issue that was discussed before and you're unknowingly picking at an old sore) and rejected. What amazes me most though is that while I've had plenty of positive comments from other users of the projects I've contributed, not once have I ever had a project maintainer say "Thank you". I can understand this from some perspectives (they created the whole project and gave it to you, and now they have to do more work to accept your patch for something they probably don't need themselves - so saying thank you in return for one tiny patch seems very asymmetrical). Nonetheless, it surprises me that simple words of encouragement are often so lacking from the open source movement. At a human level it feels very strange to spend hours working on something for free, to give it as a gesture of good will to a community of people you thought were your friends and get a response somewhere between neutral and hostile. Nonetheless, the rewarding feeling from patches I've had accepted has outweighed all negatives, so I can highly recommending just putting on your thick skin and going out there and trying.

mv1 15y ago

I would add to the list "It is too frustrating". I've contributed to several open source projects in the past (Linux kernel, gnome, etc.), but doing so is hard work, even if the changes are trivial and you don't have a reputation in the community for the project. Most recently, it took almost a dozen emails over 4 days among 3 different people to get a 3 line patch committed to a driver. The truth is contributing to open source is a social problem. You have to get to know the maintainers, build their trust, and over time, it gets easier to get patches in. If you can meet the maintainer for an hour or so at a conference, it lowers the bar but maintainers of popular projects are often swamped at these events. More often than not it is easier to fix the bug for yourself and move on, using git to keep up to date with new releases.

tehviking 15y ago

If you want people to show you how to contribute to open source, be an internet loudmouth and complain that you don't know how to contribute to open source. Seriously, these are amazing comments and I hope it's OK if I compile the best ideas into another post for others who are as adrift as I sometimes feel.

leon_ 15y ago

> Open source is for people who are better at this than me. If you think that then you're possibly better than the most people contributing to OSS. Just look up http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

nwmcsween 15y ago

A very important rule in almost all OSS projects: have a thick skin. There is usually a few abrasive and argumentative people that derail good development due to ego or trivial issues, avoid projects with people like this.

shaggyfrog 15y ago

For me the biggest problem I have contributing to OSS projects -- and something not mentioned in the article -- is dealing with politicking/egos.

deleted 15y ago

[deleted]

pbiggar 15y ago

For Mozilla, we're trying to improve a lot of the things being discussed on this page, and make it really easy for contributors to get involved. If you've ever wanted to contributor to Mozilla, go here: https://developer.mozilla.org/En/Introduction https://developer.mozilla.org/En/Introduction (feedback very welcome)

Hisoka 15y ago

Life is too short to spend any enormous amt of time on an OSS project. Invest your skills into your own business, and reap the rewards of it.