My current gig at Red Hat puts me in an interesting position within the FOSS world. I work on what’s called the Performance Team, part of the CTOs office. Most of our efforts are what you’d expect a CTO Office to be doing…playing with the new stuff.
We’re often the initial evaluators (outside of development) of a feature or other piece of code. My most significant (and completely hidden) contribution to FOSS is early adopter type feedback…hopefully while the code is still malleable, and the planets align in terms of product cycle.
Which brings me to my point…It’s not how good you are, it’s how fast you get better. Here, “you” is FOSS. Myriad articles have been written, code studies conducted etc, to prove the merit of the FOSS development model which is typically quantified in terms of “feature velocity” or bugs-per-LOC. The feature velocity fire-hose is where I’m standing.
The Red Hat model of upstream-first, means that raw RFC-type code submissions are common, and ideas are fleshed out in the open. I (and many other non-developers) observe this process and provide feedback or guidance. It’s this iterative, public development process that is precisely (but not exclusively) the value that customers get from choosing an open source platform for their business. It’s also the reason why I love my job.
Development peers do care about the quality @ initial submission. I also care about initial code quality, though mostly in the functional sense…does it boot. Further along in my personal workflow, I begin to get very concerned with the mechanics of the code itself.
- How it’s designed.
- Where are the long poles, and can they be mitigated?
- What makes sense for defaults?
- Do we need tracepoints — how do I observe the critical sections under load?
- Finally, a personal goal…How do we avoid surprising the sysadmins, who are again further downstream, and the very lifeblood of a infrastructure provider like Red Hat. The guys on the ground wired to a monitoring system, who we absolutely want as our “well-slept” allies 🙂
Cut from the same cloth, I take particular care in approaching my work from that perspective because I always hoped there was some developer out there who had my back. As it turns out, there are countless people at Red Hat who sincerely care about the impact that our software has on our customer’s bottom line. And countless more who’s job is “simply” to enable the first group.
In the recent linux.com series profiling linux kernel developers, a very common answer to the question on how to get involved, is to scratch your own itch. A valid approach, and like any other community, the FOSS community naturally needs to be concerned with care and feeding of existing developers as well as inspiring new ones. With that in mind, I tend to think of a hidden value we provide our customers; staffing developers to write code that scratches other itches, solves someone else’s problem, or otherwise enables the success of business.
Our industry has a “Linux Plumbers Conference”, possibly one of the most accurate analogies identifying the market we serve: open source code enables differentiation-by-extension. We’re the home improvement store for your neighborhood and our shelves are always fresh.
Jeremy Eder's Blog 