Why do you want to contribute?

It's a myth that in order to be a good software engineer you have to spend every free moment coding or that you need to be an open source contributor.

It's also a myth that all or even most employers will ignore or ding you if you have no contributions.

If you want it enough for yourself and for its own sake, schedule one evening (or weekend afternoon) a week for it - just as you would schedule one evening a week for date night or for volunteer work or for anything else you care enough about. Treat it as similarly inviolable.

That goes for anything outside work you want badly enough - learning to play the flute; writing a memoir; whatever.

> If you want it enough for yourself and for its own sake, schedule one evening (or weekend afternoon) a week for it - just as you would schedule one evening a week for date night or for volunteer work or for anything else you care enough about. Treat it as similarly inviolable.

I'm kind of annoyed at how simple you just made this sound (and it is) but I somehow overlooked it. I seem to always be putting stuff like that off for some huge block of time that of course never comes.

Thanks for giving me some perspective.

I agree that even setting aside one night a week isn't really that simple - especially if you have a busy schedule. But it is something most of us already do for the things we care most about.

Good luck!

If you use open-source software at work -- which you almost certainly do -- your employer might not mind if you spend a small, fixed amount of time every week improving that software.

You should ask your manager. First identify what you'd work on, then make an argument for how improving it would be good for the company as well as the public, and finally (if needed) try to sell them on the PR and recruiting benefit to the company. Propose a specific chunk of time for it, so your manager doesn't have to worry about you disappearing down a rabbit hole. (I might suggest the last 4 hours of the week, when not much gets done anyway.)

If you work for a larger company there may be policies around this, and they are likely to make it more difficult. But as a developer, you only need your manager's approval.

If you work for a smaller company you'll have a much easier time selling the idea. And if it's really important to you, consider working for a company that actively supports this.

I have successfully done this in a couple of jobs. The key takeaways:

1. Help the managers realize that you're probably saving 1000s of hours monthly by using existing open source software. The least you can do (as a company) is to give few hours back to the community.

2. Sometimes it's about "can we open-source this tool/work/whatever?" or "does this give our competitors advantage?". Make sure you think this through before talking to the manager; I got a couple of internal tools open-sourced when I argued that even though it does advance our competitors if we'd publish a great tool, it also positions us as a company as the leaders of the genre (helping in recruitment, sales, etc).

3. "Does it benefit the company?" - Managers love to see the company logo in the project. So ask yourself if you're willing to trade some publicity of the company (e.g. "powered by YourCompany" badge, "supported by YourCompany" in the README.md, or moving the Github project under your company's account) for some hours that would be allocated for you to work on the project.

The great thing about doing open source work is that you decide how much or how little time you want to put into it.

I have a full time job and two small kids. I'm usually out of the house with the family on weekends, and after work, I sometimes play video games or read manga. I rarely ever attend meetups or hackatons because I live and work uptown and frankly don't have time to be driving downtown.

Yet, I still find time to work on my project (usually after the kids have gone to bed). I used to also do it on the commute when I took transit to work.

There's really no real secret to doing open source. Working on my project is something I truly enjoy doing, so I often "stew" on problems and next steps while driving or eating or before falling sleep, and on the nights I feel like working on the project, I just sit down and do. If sitting down to do open source feels like a chore, then it probably isn't for you (and there's nothing wrong with that!)

Like anything else that might get stalled by procrastination, every time you sit down to work, you just have to pick some small thing to complete, so that you can get into a roll.

Working on open source to scratch an itch is also a good way to incorporate open source into your day job.

I am working as a moonlight freelancer and starting my own software business while working full time and managing my family (though no kids currently which makes managing family a bit easier). This isn't the same as OSS but it is the same principals. When I have free time I work on what I can get done. I have a 3 hour daily commute which is on the train so I have about 2.5 hours of work I can get done a day. Then there are times when the wife and I are just watching TV that I can work. Basically, I get my side work done whenever I have free time. I think OSS isn't going to be like your 9-5 dev work where you are able to sit down and code and pump out features. It is going to take more time because you aren't going to be working on it every night, for the most part.

I think the answer is, "how do you find time for other things besides open source?" People do open source because they love it more than most other things, and so other things suffer.

> How do people implement some larger features that are time consuming and require several days or months of work?

Did tons of open source at work. A bulk of my open source early on was fixing gulp, grunt and jquery plugins that would often break when API's changed.

To get your foot in the door, start by patching other people's projects. That can be as simple as a typo or adding docs initially.

On any project, the first thing I do is almost always low hanging fruit. I clone it and try to build it from source on OS X, Debian, FreeBSD and fix anything wrong with the build system or tests. Often just right there I can get a few patches in or segue it into a larger fix [1] [2]

I built up from doing small stuff to then doing big things, and eventually my own projects like tmuxp [3]. Small stuff means you get an opportunity to lurk and understand the codebase, tests and contribution guidelines.

You can also find a mentor. Open source programmers are always looking for a protege who is passionate about the codebase. Hang out on IRC with them and say hi. Look at the milestones to see if there's any quick wins to get started with. If you work at a company that uses the project, be sure to mention it. :)

[1]: https://github.com/python-cmake-buildsystem/python-cmake-bui... [2]: https://github.com/aseprite/aseprite/commits?author=tony [3]: https://tmuxp.git-pull.com

The trick for me is to break things down into manageable chunks. It may be a larger feature, but it isn't anything that a git branch can't handle. I try to keep the effort in half-hour increments, because with two small kids there just isn't room for anything bigger (most of the time).

Also, I'll often briefly open up some code at work while I'm eating lunch just to get my mind going on it. A quick scan of the structure allows me to then break away from the computer to walk/think/socialize while my subconscious mind chews on whatever the problem is. Whenever I find a free chunk of time, I'll already have a rough idea of what I can do to push that needle forward. It's then just a matter of doing it!

I've gotten to a point where doing Open Source can be a way to relax. Some nights I'll put on some good music I can code to, have tea or a scotch, and tinker around without the pressure of getting something done on any particular timeline.

I'm currently busy these days (became a tech lead/engineering manager hybrid), but if I want to work on open source, I just go ahead and get involved - read the READMEs, CONTRIBUTING.md, peruse the issues, debug the reported issues...and come back with findings, opinions, or sometimes a PR or few.

There is no shame in not contributing to open source - most developers don't do much beyond using it. There is also no shame in failing to bring new insight. I would say that make sure that it is something you enjoy doing, because otherwise it will tax your mind some to force yourself to make the effort.

We use a lot of open source packages at work and if something is wrong, it is equal responsibility of us to fix it. The hardest part (or) blocker is understanding the large codebase (A good read - http://devblog.nestoria.com/post/96541221378/7-strategies-to... ) Don't be afraid to ask questions in IRC (or) mailing list. Get started with mentored bugs. When you fix couple of bugs and understand the codebase, you will make/find more time to contribute to the project.

For now, I don't. I'm busy working on paid proprietary projects for my clients. I'll have to save up more money before I choose to dedicate a working vacation to OSS. I spend a good portion of my non "working" time on learning more technical skills that are directly related to my line of work. When technical study, travel, rest, and money become lower priorities (and they certainly will), I'll do some significant OSS work.

Also, one my clients is interested in open-sourcing one of my projects. I'm excited about that, but it's not the same as "finding the time."

I've got a few projects on Github. My kid goes to bed at 9. My wife and I often spend time watching TV when he's in bed, and that's a good time for me to multitask and add some code to my projects. When I really want to work on something, time is made. Most of the time, I judge the rest of my life as more important, but if you've got an itch, you can't avoid wanting to scratch it.

I'm not going to work on anything remotely work-related in my spare time, though. I'm not interested enough in the work I do for my employer to also make it my after-hours hobby.

I am hosting a hacker space twice a week, on Wednesday evening and Saturday afternoon. Although these are certainly social events, I do make sure to spend at least half my time there working on one of my free software projects. As an added bonus I can tell our guests all about it while working on it.

It does not matter if I am unable to finish a task, because I'll be working on it during the next hacker space meetup. Yes, oftentimes it is slow going, particularly when we're having fun, but it gives me two clear structured time slots a week to work on my projects.

Would love to hear more about this (where you organize, any structure, is it collaborative, etc.). Did this a bit on my own in the summer but it kind of petered out after a couple months.

Our hacker space has been meeting for years now. We are guests at the office of a foundation that is doing work related to art, design, society, and technology outside of their office hours. This makes the space very affordable.

Twice a week we open the space for visitors and regular participants. We try to be as open as possible; everyone is welcome to join up whenever they feel like it. There are no restrictions regarding participation or contribution. If people want to, they can make a small donation but it isn't required. At our meetings there is free coffee, tea, and beer, but everyone is welcome to bring other stuff as well. Donations in the form of drinks or food or tools are also welcome.

We have about 15 participants that show up regularly, and about 50 or so that show up now and then. I think we have had a couple of 100 visitors that did not return or only once or so, particularly when we organise special events.

Basically, people just show up and start working on their own projects. Somehow we have trouble starting communal projects, probably because it is up to the hackers themselves to keep it going or not. We try to create some sort of free-style atmosphere where everything can be supported, but there is no pressure to perform or finish. Most often, when a couple of hackers show up, it becomes more of a social gathering than a work place. That is always a nice end of the evening.

Furthermore, we also support other like-minded clubs to have their meetings at our space for free--we also have a large canteen, and a couple of meeting rooms. We have collected about four separate clubs that meet up about once a month or so. This is great as it results in some sort of cross-pollination.

After a couple of years we created an official foundation to make renting and paying things easier. It has a board, which has one board meeting a year of about an hour or two. So, bureaucratically, it does not take much time.

I'm in the same situation. We're a very small team (8 total), so I barely find time to contribute back among other events like trying to relax, personal development, entertainment, etc. I think I might have to carve out one day or a couple hours on a specific day of the week that'll be my "open source time". I look at it almost every day, but don't have enough alone time with the open source software (like React.js) I want to work on.

Yeah I am with you... If it's not a habit it is hard to do. Personally when i'm done with work I want to go play Dark Souls :p. Weekends though I will get the itch a little bit and saturday/sunday is when I can work on my own projects. Still lots of weekends are spent visiting folks and such so that free time is limited.

I try to spend 2 hours each day on open source or learning.

usually around dinner time (before or after dinner).

my problem is not that I don't have time, but that I don't have a focus. I do a little bit this and that.