Polishing cars wasn't in my job description

No readers like this yet.
My open source story

Opensource.com. CC BY-SA 4.0.

­"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.

User profile image.
Guy Martin is the Director of Open Source & Standards at NVIDIA, where we works with the Omniverse product team on helping them navigate the open landscape with projects such as Universal Scene Description, MaterialX, and many others. He also consults with the rest of the organization on open source best practices.

5 Comments

Great story! I like how you sort-of sidestepped into the community management position in Motorolla. It just sort-of happens!

Thanks Drew.... sometimes the best things in your life you literally 'fall into'. :)

The challenge for me was making the switch between being an 'engineer doing community management' to a 'community manager/strategist with a technical background.'

In reply to by dragonbite

Thanks for sharing your story. "I also had my first realization that just building a tool for a problem wasn't enough" is so true. As an autodesk products user, I am excited to know it is putting some efforts in open source.

Thanks Sreenivas!

I've only been at Autodesk 5 months, so there is a lot of work still to do on all fronts. You can check out one of the first things I was able to do, which was to at least put a place together where people could see what open source projects we've created:

http://autodesk.github.io

Feel free to follow our twitter presence too: @AutodeskOSS

In reply to by cg-cnu

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.