In the trenches with...Brent Fox of Red Hat

At the core of any successful open source business is support. However much technology companies (open source or proprietary) may want to escape the need to actually support the products they ship, they can't. Customers love you until something goes wrong. Whether they love you afterwards depends on the quality of a vendor's support.

In Red Hat's case, support plays a central role in the company's business model and in its high ranking with customers. Brent Fox plays a central role in Red Hat's organization, helping to ensure the continued happiness of some of Red Hat's biggest customers. It's one of those jobs that doesn't get the attention it deserves...until something goes wrong.

The Open Road caught up with Brent to discover how support at Red Hat supports its customers, and how its model differs from that of other vendors.

Name, company, title, and what you actually do

Brent Fox, manager, Global Support Services, Red Hat. I am the manager for the customer Technical Account Management (TAM) team for North America, which is responsible for the technical relationship between Red Hat and some of our largest customers. TAMs act as the advocate inside Red Hat for the accounts with which they work. Prior to that, I was a programmer on the operating system development team from 2000-2004.

Do you work remotely or in an office with co-workers?

I work at Red Hat headquarters in Raleigh, North Carolina. The majority of my team are in the same office, but we have a growing number of TAMs that work in other offices or remotely.

If you've had a similar role in a proprietary software company, how does your current role compare? Similarities? Differences?

My first job out of college was with a consulting company that did custom programming projects. It is difficult to make a comparison between that job and my role at Red Hat. However, I do remember suggesting to my manager that we have some of our consultants start building up their Linux knowledge. He looked at me with a straight face and said, "Linux is a fad. Red Hat will be out of business in six months." That was in mid-1999. He was wrong on both counts.

How familiar were you with open source before you joined your current company?

I first started playing around with Red Hat Linux in college around 1997 because it was something new and different. It took a while before I started to think about open source as a development methodology rather than just software for which the source code was available. I recall having a vague notion that something important was happening in the industry, but I certainly did not foresee all the changes that would follow. By the time I joined Red Hat in 2000, I was very familiar with the open source development model as well as the various licenses and philosophies involved.

Why did you join an open source vendor?

Think back to what was happening in late 1999. The Dot-com boom was near its peak. Red Hat had just completed its initial public offering. The Microsoft anti-trust trial was in full swing. I was working at a small Linux start-up before moving to Red Hat. For me, it was exciting to work on an operating system when it was just starting to hit critical mass.

How long did it take you to adjust to an open source operational mode?

To be honest, my adjustment period had little to do with whether the source code was open or not. For me, the biggest adjustment was the pace of work at Red Hat and how much work needed to be done with so few people. Everyone was so busy, and it took about six months before I really started to feel comfortable and find my role with the team, but I was having fun the whole time.

What do you think open source companies could learn from proprietary vendors?

A very smart man once said to me, "What is the best way to compete with traditional software companies? Answer: Don't become one."

Put yourself in the shoes of the customer. What would you like your open source vendor to learn from proprietary vendors? How to limit your choices with vendor lock-in? How to plow features you don't want into the next version? How to threaten you with vague intellectual property mumbo jumbo? No, no customer wants all that.

I would argue that the open source approach is inherently more customer-friendly. It puts the customer back in control over their data and their IT infrastructure. I think that the last thing that open source companies should do is to adopt the practices that have made the proprietary software world so anti-consumer and unexciting.

Having said that, I think that open source companies could benefit from combining an open source development model with a design-driven approach to problem solving. If you take the time to really understand the needs of the user before you start to write the code, then you have a much better chance of creating a product that is elegant and easy to use.

Design has become a hot topic at Red Hat over the past couple of years, and I think we've already seen our interest in design manifest itself in our products and services. For example, our Production Support team reworked the multi-page Scope of Coverage document to just one page. The idea was to strip out all the unnecessary fluff and just present the customer with the information that they care about, which is, "What do you support and what do you not support?"

Again, another child of the open source movement. I never thought I'd see the day where there would be a sustainable, critical mass of people for whom open source is pretty much all they've known. I fall into that camp (mostly), and I look around at my open source peers, and they're largely minting new devotees to the open source ethos. Brent is a great example of how open source changes one's perspective of the value of customers and the role vendors play in delivering it.