You’ll hear the word “open” a lot.
Open means you can talk about your work publicly. Anyone from anywhere might pop in and comment on your work. You can pop in and comment on any other project.
Open also means people won’t be telling you what to do very much, but rather expecting you to figure out how to contribute. Along with that, the org chart is never kept up to date, and is probably more of a dag or hypergraph than a tree. This is exciting and fun, but can also be challenging to navigate.
Becoming Effective
As a new employee, one of your first priorities is becoming effective at your basic job. For example, if you are on the JS engine team, your job is to fix bugs and add features. Fixing bugs is hard, so it will take a lot of practice and learning to become good at it.
There are all kinds of new procedures, skills, and/or codebases to learn, but what’s special in open-source projects is that you need to learn how to decide what to work on. Even if you are producing top-quality code at maximum speed, the value of that code is still entirely dependent on how relevant the project is.
What to work on
It’s not a total free-for-all. You will probably get assignments. But the assignment may be very general, like “make GC not suck”. So you’d need to figure out what that really means. And you’ll probably get way more assignments run past you than you could ever do. So even if you try to just do those, you’ll have to choose. And quite often assignments are more offered than, well, assigned.
Why don’t they just tell people what to do?
As for a open-source developer, one reason is that they are busy with all kinds of stuff, and they don’t really have time for that. But more importantly, they don’t know everything, so they’d really like your ideas and your help in making decisions. And most of all, they find that the results are far better when people choose their own projects–and choose things that they are fired up about, whether it’s because they’ll get to learn, they’ll get to feel badass, or for whatever reason it’s something important to them personally.
So how do you figure out what to do?
In one word, listen. Talk regularly with people in and around your area to find out what problems need solving, bugs need fixing, enhancements are needed. In two words, listen intelligently. Simply aggregating everyone else’s opinion is OK to start with, but I’d really much rather see everyone else’s opinion blended with your own unique point of view. Plus you’ll want to pick out the projects that you currently have the skills to get traction on and that you’ll find interesting. And you’ll need to figure out who really knows what’s worth working on vs. who everyone else thinks knows what’s working on vs. who thinks they know what’s worth working on but really doesn’t.
One lesson from my experience is that figuring out what to work on is pretty hard. So if your first few assignments seem to turn out not to be of much value, don’t sweat it. (Often new people are offered low-priority stuff or weird ideas so they can learn without blocking ongoing critical work.) Just keep talking, listening, trying things out, and learning.
Also: watch out for tar pits. There are projects out there to work on that are ill-defined, or that are popular to talk about but not really useful, or that will have an ever-expanding scope, or that have been tried 3 times and have always failed. You want to work where you will have maximum impact, not minimum. So if you find yourself in one of these, call for help: get out or get someone to help you get out.
Becoming Visible
I think visibility is important in pretty much any software company bigger than Dunbar’s number, but in such a fluid environment, it’s even more important. If you’re after external rewards, your managers and peers need to know about the great stuff you’re doing. If you’re after getting to work on the big cool projects and such, people need to know who you are and what you can do.
You don’t need to worry about becoming super-visible immediately, but you can start taking steps to improve your future visibility right away:
Starting a blog is an excellent thing to do. You may think you don’t have much to write about. But you do: your work and your experiences at Mozilla. There is almost certainly someone out there who’s interested. I started this blog talking about abstruse aspects of program analysis, and even that found an audience.
Talking to people regularly in person or on IRC is also great, of course. “What are you working on” is a good conversation starter and likely to be reciprocated.
Asking people for help automatically lets them know what you’re working on.
Helping other people gives them a chance to see what you can do.
There are also of course all the mailing lists and newsgroups and Yammer. I have the sense that a lot of the talk on there is not that productive so I’m hesitant to recommend spending more time on them to a new person, but YMMV.
Being Visible
The common notion of visibility is mostly abouttelling other people about your accomplishments (which for us extends also to your capabilities), but because we are so open, there is another side, which is letting people see you working.
We are supposed to be “all open and stuff”. It can be intimidating to work out in public where anyone could see you fail or criticize you. I highly recommend responding by embracing it. In Bugzilla, use the assignee field to show what you’re working on. Post half-baked design ideas before you start coding. Post WIPs (works in progress) to let people see your crappy incomplete code. If someone asks you to do something and you don’t have time or think it’s a bad idea, say so right away.
The advantage of this is that you don’t have much to worry about. No one’s going to discover what you’ve been working on for the past 2 months and criticize you for wasting your time, because they would have been able to give you feedback right away. No one’s going to complain you’re not working on their favorite bug, because they can either see that you are, or you’ve told them you’re not. If it’s all in the open, and no one’s complaining, it’s fair for you to think you’re on the right track.
Just to make sure you don’t think I’m (totally) crazy, I should point out that there are times to be less open. When you’re working on a proposal to change procedures or do a crazy project, or a presentation, or something like that, it does make sense to get feedback from a small group before taking it public. And that is in fact OK around here.
Becoming Influential
You probably have all kinds of ideas about how to make the web better, or the JS engine, or Bugzilla, or our review process. That’s excellent.
But don’t be too surprised if at first most of your ideas are met with skepticism, misunderstanding, refusal, or are just ignored. There are way more ideas out there than there are people to work on them, so everyone already has 35 great ideas they’d love to try. They’d have to decide that your new idea is better than those 35 in order to think about it all that much. Or maybe they’ve already heard that idea and they rank it #67, so they’re not that motivated to think about it again. Getting ideas heard can be hard.
But also, don’t be discouraged if your ideas don’t seem to move people very much. It doesn’t mean your ideas are bad. It doesn’t mean no one’s ever going to listen to them. It does mean that if you want to be heard you’re going to have to rise to the challenge and work at it.
The easiest way to get more attention for your ideas is if you have “open source street cred”. If you are new, there is of course a good chance that you don’t have any yet. But as you become effective and visible, you will get that street cred and more chance to be heard.
What to do in the meantime?
I don’t have a recipe. I recommend just to keep trying. That’s also why I said not to get discouraged. You can try an idea on different people. Maybe the first 5 are not too interested but the 6th has time and wants to work on it. You can try it over time. Maybe when people first hear it is unfamiliar and weird, but after talking with you about it over time, they come to see its merits. You can write code or do some experiments to test the idea and show how it might work. You can change and refine the idea to see if different versions get more attention. If you keep trying and pay attention to what works and what doesn’t, you will gain skill in promoting your ideas.
One thing I think is clearly effective in getting heard is service. If you help other people solve problems, make their jobs easier, or help them get their ideas heard and implemented, there’s a good chance they’ll be more inclined to listen to you and help you out. That can go a long way even before you have any street cred.
Conclusion
If you’re effective, visible, and influential, then you’ve made it. It’s only a matter of time that will get you up the ladder.