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 & communityAfter 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 completeI 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.
Originally posted on opensource.com.
Reposted with permission and under Creative Commons.