This next installment has us "In the trenches with...Ryan Morgan of Hyperic. When I asked Javier for his recommendation on an "unsung hero" at Hyperic he suggested Ryan. I demurred once I heard Ryan's title (Chief Software Architect). But Javier insisted, informing me that Ryan had grown with the company. He wasn't blessed with executive status from Day One, but instead proved himself over time.
Since that's precisely the sort of tenacity that I was looking for in this series, I capitulated. Here's a guy who has done just about everything at Hyperic (including the accounting), and who helped to see the company through its sometimes rough transition from Covalent Technologies to Hyperic. Talk about bootstrapping....
Ryan is particularly interesting because he represents the next (people) wave of open source: developers and business people who have never known anything beyond open source. Ryan's first job was an open source company. I suspect his last will be, too.
Name, company, title, and what you actually do
Ryan Morgan, Co-founder and Chief Software Architect, Hyperic. My primary role at Hyperic is the technical lead for Hyperic's main product, Hyperic HQ. In addition to those responsibilities I frequently engage with Hyperic's larger customers to ensure their HQ deployments are successful. I'm also an active member of Hyperic's online community. Prior to Hyperic raising funding I also managed Hyperic's books, though I think that had more to do with being the son of a CPA than it did my financial skills.
Do you work remotely or in an office with co-workers?
I work from Hyperic's office in downtown San Francisco.
If you've had a similar role in a proprietary software company, how does your current role compare? Similarities? Differences?
I've been fortunate enough to work for open source based companies my whole career, so I really have no direct comparisons to make. Indirectly, I have learned through interviewing candidates at Hyperic that many developers at proprietary software companies feel isolated from the end users of their software. These companies protect their engineers from distractions (in most cases customers) to ensure schedules are kept. When interviewing for a job at Hyperic, that is the stand-out benefit that candidates get excited about - to really get that hands on influence and satisfaction of seeing your efforts at work.
How familiar were you with open source before you joined your current company?
Prior to Hyperic, I worked for Covalent Technologies, a provider of commercial support and add-on modules for the Apache web server. This was my first job out of college and my first experience with open source. Covalent has a great group of engineers, many of whom are part of the Apache Software Foundation. Working with that group taught me a lot about how open source communities work, and eventually led to me contributing code back to the project. That experience also prompted me to develop mod_ftp, a plugin for Apache 2.0 that allows content to be served via FTP directly from Apache. The mod_ftp module has recently been folded into the core Apache source tree, and while I no longer have the time to work on it, it's something I'm pretty proud of.
Why did you join an open source vendor?
I really enjoy working in the systems management space - it presents a set of problems that I think we can do a better job of solving. I didn't choose to join an open source company solely for the sake of being open source. That said, I do enjoy the open source aspect because it builds an environment where end users and developers can interact to help build a better product. It's very rewarding to see our work helping others do their work more effectively.
How long did it take you to adjust to an open source operational mode?
Since the open source model is all I know, no adjustment was necessary. But, for what its worth, I think I would have a hard time adjusting to not being involved with open source in some way.
What do you think open source companies could learn from proprietary vendors?
At Hyperic we build software that can be used to manage just about any product you can think of. Because of this, we deal with a wide variety of both open source and commercial products and their external management APIs. One of the more frequent problems we have to deal with are open source products changing their public APIs in-between point releases of the software. This may sound like a minor point, but it really imposes a big burden on the vendors that are forced to support them.
I think that's one big thing open source can learn from proprietary software - Keep the public APIs stable between maintenance releases, and only change them if there is a good (non-cosmetic!) reason to do so.
A child of the open source movement. Interesting to see just how easy it is to have an open source mindset when you haven't grown up with something different. Expect an entire industry filled with people like Ryan - people who expect a tight relationship with their customers, and who develop software accordingly. I can hear John Lennon singing "Imagine" now.... :-)