KarlieRobinson.com

Rural Housewife or Tech Entrepreneur? You Decide

The Rule of Two

with 4 comments

I was following a thread this morning on the TeachingOpenSource.org Mailing list about using Scribd for source materials.

Five messages in, there’s a reply that sends up a red flag for me.

This is the second time hearing a story that’s so similar that it can’t be considered a coincidence.

I’ve mentioned my “Rule of Two” theory of customer/community relations before. It states…

If one person comments, take note but use your best judgment on how seriously to take it. If a second person tells you almost the exact same thing, there’s no guessing, you’ve got trend.

While I would hope that the trend isn’t larger than the two accounts, there’s no way to ignore the fact that Adam’s email echos what another developer said to me just a few months ago while standing in my kitchen drinking beers with my husband.

The trend conveyed by both guys is that there is a tendency for Fedora/Red Hat people to start from scratch rather than start with the finishing touches.

This worries me not because two guys might be feeling frustrated, but that these guys work with different parts of the FP.o/RH organization and have similar stories. I’m also a bit concerned because I’m not up on day to day operations yet I know of two cases.

That leaves me wondering… Who else might be feeling the same way? Is there something about the project culture that encourages people to avoid collaboration outside of the project core? Is it that there are so many resource available that the practice of external collaboration is rusty? Or maybe just the communication conduit between internal and external projects needs a look. (as in – this is why we decided not to collaborate, or this is why I want to collaborate with you)

I’m also a plan-for-the-worst-hope-for-the-best kind of girl and at the moment am thinking not just about the missed opportunities to collaborate on solutions that meet everyone’s needs, but also about letting these concerns grow to become community rifts and/or future barriers to collaboration. You can’t please everyone all the time, but I’m looking the future potential for this to get out of hand.

I can’t pretend I know the answers to any of the above. Just that the Rule of Two is in effect and the powers that be need to give a little time to address the break down.

Working together 3 by Mark Robinson

Written by Karlie

June 25th, 2010 at 7:01 am

4 Responses to 'The Rule of Two'

Subscribe to comments with RSS or TrackBack to 'The Rule of Two'.

  1. I'm not sure that this story you've got from the Teaching Open Source (TOS) mailing list counts as one of your two. I'm compelled to respond briefly before addressing your main point.

    Regarding the TOS thread, I responded, and while clearly a series of communication mistakes occurred, I don't think anyone rejected outside collaboration. We worked on the book inside of FLOSSManuals for a while, it didn't end up working for us, and we switched to … MediaWiki and DocBook XML. Not technology we invented. Tech with a long pedigree inside and outside of Red Hat and Fedora and TOS. Using FLOSSManuals.net in the first place was a departure from practices, was an attempt to collaborate with an upstream publishing platform instead of managing our own instance, and the writing team sunk quite a bit of time into trying to make it work for our needs before switching back to the tried-and-true:

    http://teachingopensource.org/pipermail/tos/2010-June/001315.html

    Back to your main point. Does Red Hat, and by extension folks who work for Red Hat who work in parts of Fedora, ever get a case of NIH (not invented here) syndrome? Clearly, yes. Is that to the detriment of a better open collaboration? Sometimes, yes. Maybe even often, yes. Is it always the case that the NIH reaction was incorrect? No, it is not always the case. Innovation is sometimes from scratch as well as from the shoulders of other giants.

    There are two fundamental truths at play here:

    First, Red Hat is an engineering organization. Like many software companies, the engineers have long had influence on the direction and decisions of the company. I don't neccesarily mean daily-in-the-code engineers, but especially their engineering managers, directors, vice-presidents, presidents, and so on. Many of whom got those roles because they had similar roles at other software companies. Engineers like to come up with new ideas, and *every* engineering organization has suffered from NIH.

    This is one reason why we have "The Open Source Way" handbook, to have something to teach from for newly hired engineers/sales folks/marketers/etc. to help steep them in the upstream, cross-stream, and open collab cultures that we know tend to be the best way to do things. Tend to. Not always. Sometimes, you do need to do stuff from scratch, even though it is usually a better idea not to. (BTW, I reviewed the literature before starting "The Open Source Way" from relative scratch, and based on the response so far, this was clearly a need for a new invention because one didn't exist.)

    Second, Red Hat has been mucking around in myriad FOSS projects for almost two decades. Over the years, it is probably the one company with the single widest and deepest influence in FOSS projects. In many of those cases, the Red Hat teams have been clear users of the "start with finishing touches." In other cases, it has failed to do that where it could or should have, and instead started from scratch. Too many cases, yes. But not the majority, not by a long shot.

    (The rest of this comment in a second post due to character limit.)

    quaid

    27 Jun 10 at 6:24 PM

  2. (This the continuation from the previous comment.)

    There are a few sad effects from this second fact. One is wasted effort, a loss for FOSS communities and RHT investors, which can't be predicted but can be viewed in 20/20 hindsight. But R&D is like that. Sometimes NIH *is* the right way to go, most often it isn't, but the fact that it can be the right way in some cases means engineers are always going to consider it. Another sad effect is on relationships, when people have tried to get over the citadel walls and just aren't being heard.

    Most often it is simply a combination of the small stuff. In the example in your post, Adam feels he has a solution that did all that we needed. Those of us doing the work didn't agree. In one case, I didn't understand that Adam was showing me a tool that he thought did what I needed (I don't think it did, but I wish I had noticed what he was doing and properly responded.) These are human foibles, good ideas, bad ideas, and the way things go. I don't detect any hubris in this situation, and I'm sad that others do.

    Being at Red Hat for almost 9 years, I have seen all sides of these situations. I have seen when Red Hat was villanized unduly, and other times when it should have been villanized and escaped unscathed. I do think we have an ongoing problem that is endemic to the situation we are in (for-profit software engineering firm leading and following many thousands of FOSS projects), I'm frustrated by any inability to make changes, but I stop short of calling it a crisis.

    Red Hat should be held to higher standards than other companies, and it is. So, let's not forget that the higher standard is in effect when we make judgements. Our goal should be to make it better than other companies in similar situations, against a similar standard. I wouldn't be overly concerned with squashing all NIH.

    Thanks for bringing this up, it's not something that should be ignored. As you might have guessed, this is a long complaint against and concern about Red Hat. Diligence is needed, yes. But take heart, it's most likely just part of a process we are all learning as we create it, and not as much of it is bad and wrong as we fear.

    quaid

    27 Jun 10 at 6:25 PM

  3. Yes, and the Rule of two is just that point where I begin watching for trends to forms.

    For me, it's always better to begin taking note of any potential issues or successes as early as possible so that organizations can be proactive.

    I realized that there could be any number of issues, but there is a bona fide trend in the making.

    The solution in these cases may simply be that external communication conduit. My opinion on this situation is that it's just as much an external issue as an internal one.

    If there is frustration on either side, they must say something. If they don't and it festers, they're just as much to blame.

    A 5 line email is usually enough to break the barriers and provides me with valuable information. "I saw you're going with XYZ Inc. Could you tell me why?" Then I have to accept what's said and correct any misunderstandings. But mostly I do it to make myself more competitive in the future.

    Karlie Robinson

    28 Jun 10 at 9:55 AM

  4. […] mean that you should jump on the band wagon.  I know this flies in the face of my “Rule of Two,” but there’s a difference between spotting a trend and knowing if it’s a good […]

Leave a Reply