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.
Continue reading “It’s not how good you are, it’s how fast you get better…”
Jeremy Eder's Blog 