Wednesday, November 11, 2015

Polishing Cars Wasn't In My Job Description


­"Whose turn is it to prep the JavaCar demo?" I asked my colleague. As I suspected, the answer was, "Yours!"

However, I wasn't too disappointed, as I was happy to show off what my team at Sun Microsystems Labs had built. Our JavaCar was well ahead of its time—a vehicle testbed for in-car networking, telematics, and infotainment, all before those concepts existed in the mainstream.

So, I set about carefully starting the demo, as well as using a spray bottle to give the vehicle a quick wipedown before showing the car to another set of visiting executives. As I was doing this, I suddenly thought back over the past six months of development—we were a three-person team inside of the research organization, yet we'd garnered code contributions from over 15 different individuals throughout multiple teams in the company to make this demo a reality.

While I didn't think too much more about it that day, that project had propelled me into a career in open source.

Inner source & community

After finishing the JavaCar project, I set about trying to collect the "loose pocket change" projects from throughout Sun Microsystems—those projects that were utilized by lots of people, sometimes in many different forms or versions. I had my first real introduction to open source when I took the PHP code base from Sourceforge.net (when it still was open source) and built an internal Sourceforge instance inside of Sun.

I also had my first realization that just building a tool for a problem wasn't enough—I spent a large amount of time finding projects, convincing people, as well as connecting different teams inside and outside of Sun Labs together. I was an inner source community manager; I just didn't know it yet.

After I left Sun, I spent some time in a startup, where my open source and community skills weren't really needed (except to consume some open source software, occasionally). However, my next stop was Motorola, where I continued to pursue my job as an engineer, working on embedded software for a Linux/Java phone platform.

What happened next changed the course of my career and further pushed me into the world of open source and community management. By chance, I found someone at Motorola who had built an internal version of Sourceforge for the company—sound familiar? He and I started chatting, and before I knew it I was helping him manage the site, as well as writing extensions and other PHP code to improve the site's functionality and integrate it with other Motorola systems. We also contributed back small changes to the code base and other open source projects we relied on.

Our site became very popular internally, with a large portion of the company starting to use it. We hired a team of two to do the technical and day-to-day management, and I (reluctantly) became more of a community evangelist/strategist. However, this change pushed me in the direction that defines my career today—talking about, educating, evangelizing, and coaching others about the importance and benefits of open (and inner) source software and methods, all of which I truly enjoy!

The metamorphosis is complete

I often joke that I no longer do technology for a living, I just talk about it. While I still do occasionally hack on shell, Perl, or other scripting languages, I primarily work at helping make companies successful in their use of open source (including applying the same principles to internal collaboration).

I've spent time helping build strategic open source consulting offerings at Red Hat, contributed to launching an open source group at Samsung, and now I'm directing open source strategy efforts at Autodesk. What have I learned through this journey to open source and community?
  • Don't be afraid to go off in new directions and try things that might make you uncomfortable.
  • Relationships (even virtual ones) matter—they help you get things done.
  • "Release early, release often" works for more than just code.
My advice for anyone starting out in open source is simple: Be humble, but bold. The great thing about open source is that you can make a great impact, but you have to do it within the confines of a community, and learning how to bring your best while working in sometimes challenging interpersonal situations is a skill that you can only acquire through practice.

Originally posted on opensource.com
Reposted with permission and under Creative Commons.

Aim to Be an Open Source Zero


My two biggest dreams growing up were to be either a firefighter or a space explorer. Though I didn’t get to do either of those things, I satisfy the former via being a volunteer in prevention with Cal Fire, California’s state fire department, and the latter by reading everything I can get my hands on about space—both fiction and non-fiction.

I recently picked up Col. Chris Hadfield’s book about life as an astronaut, An Astronaut’s Guide to Life on Earth, and began reading it during one of my international trips to Asia.

Besides being a fascinating read (I highly recommend it), it has also been enlightening as I think about how I can do my own job better and counsel internal developers and Samsung as a whole on doing a better job in open source.

Aim to be a zero

In chapter 9 of the book, Hadfield writes:
“In any new situation…you will almost certainly be viewed in one of three ways. As a minus one: actively harmful, someone who creates problems. Or as a zero: your impact is neutral and doesn’t tip the balance one way or the other. Or you’ll be seen as a plus one: someone who actively adds value. Everyone wants to be a plus one, of course. But proclaiming your plus-oneness at the outset almost guarantees you’ll be perceived as a minus one, regardless of the skills [or value] you bring to the table or how you actually perform.”
While this may sound defeatist, it actually has a lot of relevance for how individuals or corporations should approach working in open source.

It resonated with me as I considered other things I’ve written on community interaction, including the last statement of one of my recent blog posts: "Be humble, but bold."

As I thought about Hadfield’s words, it was very clear to me that he’s talking about the same thing. While you certainly should want to be a 'plus one' in any open source community you're a part of, you need to do your best to be a zero—not tipping the balance one way or the other—especially at the start of your interactions.

This applies to individual open source developers, but is especially so for those working on behalf of a company. There is nothing that will cause a community to, at best, ignore you or, at worst, actively campaign against you, faster than jumping in and immediately trying to be a ‘plus one’ from the start.
Does this mean you should shrink into the background and not ever speak up? Absolutely not, but there are some general guidelines you can follow to help you get to that 'plus one' status.

Do your homework

There is simply no substitute or shortcut for doing your homework/research before attempting to have an impact on an open source project.

Among other things, you need to understand how the community communicates (mailing lists, forums, or internet relay chat (IRC)). You should also know how ideas get proposed (bug tracker or mailing list) and discussed.

Additionally, it helps to understand how the community is governed—is it hierarchical with maintainers/sub-maintainers (like the Linux Kernel), or is it a mostly flat structure (such as the Debian project)? Understanding this helps you identify the key leaders and influencers in the project, which will help you later on as you start to propose changes or new ideas.

Finally, understanding the flow of development is critical—how many stages does a bug or new feature go through before it’s accepted into the mainline? Are some areas more contentious than others? All of this research will help you when it comes time to fix a bug or propose and implement a new feature.

Offer to do the dirty work

When explaining how to enter the International Space Station for the first time, Hadfield writes:
“The best way to contribute to a brand-new environment is not by trying to prove what a wonderful addition you are. It’s by trying to have a neutral impact, to observe and learn from those who are already there, and to pitch in with the grunt work wherever possible.”
In an open source project, just as in the space station, there are innumerable tasks that need to be accomplished. Yes, the glory may be in writing code, but almost all projects I’ve ever seen have urgent needs in one (or all) of the following areas:
  • Documentation
  • Testing/quality assurance
  • Bug fixing/triage
  • User interface/user experience
  • Community shepherding/evangelism
Often by contributing in one of these areas, you’ll gain expertise and understanding you didn’t have about the project before you started. You’ll also show your fellow community members that you can be trusted with more and more responsibility as time goes on.

Treat everyone with respect

There has been a lot of commentary in the last several years about how some open source projects are "hazardous work environments" because of the vitriol spewed on mailing lists, IRC, etc. However, as I tell staff within Samsung (and other companies I’ve consulted or worked for), "You never lose points for professionalism."

Learning to take feedback gracefully (even if it was not given that way) and reworking your code, suggestion, or just commentary on a mailing list, is important in learning how to work effectively in this environment. While the transparent nature of most projects’ communications helps enforce this a bit, remember that any private communications you have with project members are important as well.

Hadfield tells a story about how would-be astronauts were basically disqualified for space duty because they couldn't 'play well with others,' or treated medical or other support staff poorly. You may be the most brilliant developer on the planet, but unless you can interact gracefully and treat everyone with respect, you're unlikely to be successful in open source in the long term.

Bringing it all together

All of these points are really about a single thing: understanding your environment. Hadfield sums this up beautifully:
“When you have some skills but don’t fully understand your environment, there is no way you can be a plus one. At best, you can be a zero. But a zero isn’t a bad thing to be. You’re competent enough not to create problems or make more work for everyone else. And you have to be competent, and prove to others that you are, before you can be extraordinary.”
It’s important to remember that the lessons he shares in his book were born out of hard-fought (and sometimes life-and-death) situations. While working effectively in open source projects isn’t in the same league, the lessons he shares about living and working 255 miles above earth in a multi-national collaborative effort are just as applicable to being a trusted member of the open source community.

Originally posted on Open Source Delivers
Reposted with permission and under Creative Commons.