Wednesday, February 17, 2016

It feels great to get that off my chest. I started a new role at Autodesk 8 months ago, knowing next to nothing about 3D design, additive manufacturing, CFD, BIM, or even the company's flagship products like AutoCAD.

Why am I in such a celebratory mood about this? Because this very lack of knowledge, plus what seems like a lifetime in open source & community, has prepared me to look at things from a different (and much wider) perspective. This is an important component of my job, and I believe nearly anyone can learn a lot from this approach. Anthony K. Tjan said it best in a 2010 Harvard Business Review article:

If desperation is the mother of innovation, then ignorance might be its father.

Let me be clear that ignorance is the starting point, and if you never move past that, it does you no good. But, ignorance, combined with a drive to become enlightened, is the recipe for mastery of anything. Learning how to ask great questions is key in this endeavor, but it's also equally important to be supportive in answering those questions. Scott Merrill has some great suggestions for that in a 2015 article on opensource.com.

‘Framing’ your questions in the right way is critical as well. Just saying ‘I don’t know’ with an implied ‘tell me everything’ rarely gets results. Think about being explicit – ‘I don’t know x, but here’s what I’ve tried to find…’ or ‘I don’t know y, and I hear you’re the subject matter expert on this, can you help?’ Framing things in this way shows your willingness to be humble, but your eagerness to learn. Simply showing up ignorant, with an expectation that people will just ‘fill you in’ because of who you are, never works. In short, ignorance, used properly, can be disarming to those you’re trying to get knowledge from.

Clichés abound in this context, for example, ‘try to learn something new every day.’ While that’s a laudable goal, I think it’s far more important to focus on a plan to acquire knowledge in chunks that you can piece together yourself into a larger puzzle. This also relieves some of the pressure to collect facts every day (in isolation), while lacking a good way to immediately combine them.

Why is this important to not only personal growth, but corporate health as well? Knowledge transfer is generally easier when it’s ‘pull’ vs ‘push.’ Engaged (‘ignorant’) participants are more likely to absorb and re-share information if they can do it on their own, instead of it being forced from above.

I can see some of you out there in Engineering Land giving me the wary eye… :)

‘What, he wants me to admit I don’t know something!? – Is he crazy?’ Well, that remains to be seen, but I speak from experience in this regard. Admitting that you don’t know is incredibly freeing when you turn it around and look at it as a challenge (something we engineers love) to become better at something. So, I heartily encourage you to embrace your ignorance as a stepping stone to improving yourself and, even more importantly, the companies you work for.

Wednesday, November 11, 2015

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

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.

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 especiallyso 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.

Thursday, November 1, 2012

I've built several communities and been a part of many others during the course of my career, including some that have nothing to do with software and technology.

Unfortunately, two communities I've been a part of have recently suffered devastating losses. Not long ago, I wrote about my friend Greg Junell, and what he meant to a community of college kids who've now grown up and gone on to do many amazing things. Just this past Saturday, my Cal Fire community lost an amazing member in the line of duty, Chief Rob Van Wormer. He was the head of the fire prevention battalion at the Cal Fire Santa Clara Unit, which includes the group I volunteer with - the Volunteers in Prevention (VIPs). The chief was a vocal and strong supporter of our volunteer team, and the many functions we perform for the department, including emergency radio communications, fire lookout staffing, public education programs, and media center operations (fielding calls during a major fire).

My Badge Shrouded for Chief Van Wormer's Passing

He was a man we all respected and admired (and truth be told, feared just a little bit, in a good way). I'm sure the chief would never have characterized himself as a community catalyst - fire departments are paramilitary organizations by necessity - you have firefighters (privates), engineers (lieutenants), captains, and various levels of chiefs working in a command & control fashion. Chief Van Wormer ascended these ranks through 24 years serving the citizens of California, and I know that he was very proud of his department and his entire unit.

However, his leadership style, while firm, provided for flexibility, and that allowed a community to form within his unit - one that I'm extremely proud to be a part of. The interesting thing about the fire service however is that there is a bond (some call it brotherhood, but I think community is a more all-encompassing term) that binds not just individual units and departments together, but brings together everyone involved in the fire service. The sad part is, most people don't get to see that put on display until there is a tragedy such as Chief Van Wormer's passing.

The amount of support that Cal Fire has received, and the incredible way our department has come together to help the Van Wormer family through this, is the highest form of community engagement I've ever seen. While this is no surprise to those of us who've been a part of this community, it should serve as an inspiration for community managers in other disciplines as well.

While you may not ever have to go through something like our community is going through now, it never hurts to consider how your community reacts in bad times. It's easy to show strength when things are going well, but it takes a special kind of community to pull together when the chips are down and showcase its caring, understanding and strength.

As for me, I'll be attending Chief Van Wormer's memorial this Saturday, in a hockey arena - because that's how large and supportive our community is. Despite how much this hurts all of us who've lost a friend, colleague, and leader, I know we'll all be much stronger from the collective support of our fellow community members.

Sunday, August 12, 2012

"You never forget your first _____"
This phrase, with the blank filled in, is often used while looking back fondly at something you experienced that still touches your soul - and so, it's true of me today as I reflect on the loss of an amazing person - Greg Junell. Who, you might be asking, is Greg Junell?

Greg Junell - 2011

Greg was and still is the heart and soul of my very first experience with community. We didn't call it 'community' back then, but looking back on it now, the slo.punks was the first community I can remember being welcomed into with no reservations. When you are a teenager away from home for the first time, experiencing college at a very competitive school like Cal Poly, San Luis Obispo, life can be scary, awkward, and downright difficult. Though 'The Punks' (think Cyberpunk, not punk rock) didn't have formal leadership per se, Greg was the closest thing they had to a community shepherd.

Even now, I think back to meeting him for the first time - big tall Greg, red beard sprouting out in every direction, but with a smile and a heart that just oozed out of every one of his pores. Greg was one of the few people I've ever met in my life who always seemed happy to see an old friend, or make a new one. Part computer guru, philosopher, pirate radio DJ, and big kid, he could engage in manic silliness one minute, and then dive deep into his psyche to argue philosophy with you the next.

Greg didn't always agree with everyone (I know he and I had vastly different political views for example), but he truly was the model that I think we need more of in our society today - reasoned discourse. I never came away from a conversation with Greg angry or upset about our differences. I frequently came away enlightened or challenged to look at my life and views in a unique way.

I think the best testament I've heard about Greg though is one shared by several of my classmates at Cal Poly through the years - even those of us who had not had as much direct contact with him as we used to are feeling his passing in a very raw and emotional way. His impact on our lives is something I know we are all grateful for. He spent the most recent years of his much too short life helping inspire the next generation as a teacher - I can only imagine the awesome times those kids who got to learn from him had! :)

I'll always carry the experience of my first community with me going forward, and I have Greg to thank for that. Rest easy my friend, you've earned it.

Wednesday, August 1, 2012

'Festival Magic'
I've heard this phrase for the past 8 years while serving with an amazing group of 4000 volunteers who put on the Gilroy Garlic Festival - lauded by most as the premier food and entertainment festival on the West Coast. While the saying started out as a bit of a joke to explain how things get done, the reality is those two words are the bedrock of an annual event that has been taking place for almost 35 years.

The history of the festival is long and storied - this video gives a great overview. However, the elements behind the concept of 'Festival Magic' are applicable to communities of all types, whether it's open source software development, social media communities, or affinity groups. This 'magic' isn't really all that magical - it breaks down to the following main ideas:

Empower Everyone to Lead

Gilroy Garlic Festival volunteers are expected to lead (and follow) at all levels of the organization. Even the most junior volunteers are given some form of responsibility and ownership of their designated tasks, and they are always encouraged to share ideas on how to make things better.

Additionally, in the words of Hugh Davis, Garlic Festival president for 2012, 'no job is too small for a volunteer to take on.' It's worth noting that he said this while responding to a patron who was both grateful and shocked to see him helping pour cups of free water for festival guests waiting in line to board buses back to the parking lot.

Empowering your volunteers and community members to lead in their own way gives them a sense of pride and ownership in your community. The Garlic Festival learned this lesson early on, and it's baked into the DNA of the organization. When people are interviewed about why they volunteer for the festival year after year, the two main themes that come out are pride in the event and a sense of ownership/family. In short, none of the volunteers wants to be the one who lets the festival (or each other) down.

Nurture the Next Generation

The Garlic Festival's founders had amazing foresight (and the experience of seeing another similar festival fail in leadership development) and decreed that no person would ever serve more than one consecutive year as the festival president. Additionally, there are defined terms for board members, advisory committee members and committee chairpersons. These limits are not meant to discourage volunteerism at all - in fact, it's quite the opposite. Encouraging volunteers to find and mentor new leadership talent builds an organization that not only continually strengthens its ranks, but also brings a new influx of ideas and passions to the table.

A strong community is not afraid of leadership change - finding a way to embrace and encourage turnover keeps things fresh and vibrant. In our case, a future Garlic Festival president may well emerge from the volunteer pool of teenagers at this year's event!

Make it Fun!

You can probably file this one under the 'yeah, tell us something we don't know' category. However, it is always easier said than done. In the case of the Garlic Festival, we accomplish this primarily by focusing on making the event fun for the patrons. When they are having fun, it's infectious - our volunteers can't help but feel the atmosphere of fun when they see festival guests enjoying themselves. Does this mean that there isn't serious business going on with our festival volunteers? No, but purposely making the work fun makes the time go faster and encourages people to volunteer and contribute year after year.

The next time you are evaluating your community, think about the fun factor, and what you can do to improve it. Sometimes this can be as simple as letting a team develop their own identity in the form of t-shirts, slogans, or nicknames. Remember, fun doesn't necessarily have to cost a lot, but enabling people to make their tasks fun goes a long way toward encouraging continued community involvement.

The Bottom Line

Building up this kind of community is not easy or quick - the festival has had its share of bumps along the way. However, by continuing to focus on bringing in new ideas and talented people, the strength and bonds between the volunteer community have continued to grow. At the end of the day, the most powerful thing you can work toward building in your own community is a pride of ownership that guides your members long after you have stepped away from leadership.

My hope is that you'll take some of these fundamentals of our 'Festival Magic' and sprinkle them liberally within your community to help it thrive and grow. Who knows, one day you might be as lucky as we'll be next year in Gilroy to celebrate 35 years of community, food, fun and fellowship! :)

Friday, March 16, 2012

I just recently wrote a post talking about job titles, which got me thinking of how I would classify my current career role. That, combined with other discussions which have been happening inside the walls of my employer, made me realize that the best way to describe myself would be as an Open Source Community Pragmatist.

I can see the heads shaking, the puzzled looks, and even the sighs from some of my colleagues who are a bit more on the idealistic side when it comes to these topics. Let me assure you, I have total respect for those folks who make everything they do in life about the ideology - it's just not the path I've chosen for my career, and here's why:

The vast majority of the day-to-day work of society & business happens between the ideological extremes:

Conservatives vs. liberals

Proprietary vs. open source software

Emacs vs. vi (a little inside joke for my technology readers)

Does this mean that we don't need the extremes? No, I think they need to exist to define the boundaries, and in many cases, to push better ways of doing things to the center of the spectrum. The reality though, and those of you at the extremes may chafe at this, is that most people are closer to the center than to either extreme, and their primary goal in life is to get their jobs done, stave off starvation, and pay their mortgage on time. That is the cold hard reality of life, and these people are the ones who make the trends happen via purchasing decisions based on how easy it is for them to utilize things like technology as a tool to get their jobs done, stave off starvation, and pay their mortgage on time. :)

People of this ilk are very much in the 'easiest tool that gets the job done', vs. 'absolute best tool for the job' mindset. These are the people that choose Windows and Macintosh computers instead of putting in the time to get Linux properly installed and working on their laptop. Has Linux made great strides on the ease of installation and desktop use? Yes, but still not enough to displace the ease of use (or perception thereof) of Microsoft or Apple products. However, there are opportunities to mix these two camps, and this is where the pragmatism label comes in.

I'm very proud to work at Red Hat because of what they stand for in the Open Source world (disclaimer - these opinions are not necessarily reflective of those of Red Hat, our mascot Shadowman, or anyone else who might or might not be wearing red fedoras today). However, because of my role in consulting, and my frequent travel and personal usage habits, I chose a Macbook Air as my primary computing platform. Cue the wailing and gnashing of teeth from the ideological camp. :)

However, the Open Source Community Pragmatist in me justifies it easily by running virtualized instances of Fedora 16 (Red Hat-sponsored community distribution of Linux) as well as Red Hat Enterprise Linux 6.2 (our enterprise version of Linux). Oh, and also, with the exception of iCal, pretty much all of my day-to-day productivity application needs on Mac OS X are met by open source tools (Thunderbird, Firefox, Adium, LibreOffice, etc.).

Do I use proprietary tools on this machine - yes, as customer needs dictate (primarily MS Office).
The main argument I get from the ideological side is that I'm doing a disservice to my company by not using the products we sell. First of all, I've already noted that I do use the products, and also, I believe that pragmatism wins many more hearts and minds with a customer than blind devotion to an ideology. Are Red Hat's products great choices in the enterprise/data center? Absolutely, and I champion their value in that arena all day long. Are they the best choice for end-user workstations? In some limited cases, yes, but by and large, customers are better served using their existing infrastructure and supplementing it with open source productivity apps (as I showcase on my machine).

Obviously, we all have our passions and particular opinions about why we do the things we do. I guess my point in writing this post was to simply highlight that the motivations for why we do things are different for each individual (and business), and while we may not necessarily agree with someone else's viewpoints, we cannot function as a society or community unless we learn to respect the need for those viewpoints to exist.

About Your Host

I'm an Open Source Community Pragmatist with a passion for collaboration, social media, and emerging technology. This blog is my take on the 'mashed potatoes' of all of these technology areas. Please feel free to comment on any of these ideas, and as always, these are my *personal* views, which don't reflect those of current or previous employers. :)