This is Jack Repenning's Typepad Profile.
Join Typepad and start following Jack Repenning's activity
Join Now!
Already a member? Sign In
Jack Repenning
A MacMudgeon lost in penguin-land
Interests: Straight-ahead jazz Pre-classical music Pinot Noir Film noir Fly fishing
Recent Activity
Well, Mr. Lehrer did ask something like the right question, though he saved it for last and had to spend overtime on it. I'd summarize Romney's response as "consensus-building takes a lot of dialog and time," and Obama's as "sometimes, you just gotta be tough." While both are true statements in the broad generalizations, I think Romney's response comes closer to what seems to have been lacking, lately. OTOH, one of the places it seems to have been most lacking, lately, is in his own dealings with his own party, and the insistence of some corners thereof that he take positions he has historically rejected. So, if his intent has been to talk his way to consensus, his record, most especially of late, seems to be dismal.
Oh, harsh! You apologize to those two-year olds. Right now!
On the other hand, it just might be a good idea if everyone were required to be trained in "looking through the menus of whatever program you're using to see if one of those commands might help you get unstuck."
Toggle Commented May 15, 2012 on Please Don't Learn to Code at Coding Horror
My university had a series of "Programming for Non-Majors" courses. Having tutored them, I'm pretty sure the whole purpose was to make the non-majors just go away. Perhaps not so bad an idea.
Toggle Commented May 15, 2012 on Please Don't Learn to Code at Coding Horror
(reposted comment, due to TypePad damage): Note that if you're using SSL (anywhere in the configuration, even if it's not actually for your svn stuff), you need one additional line, inside the "Location /repos/svn" block : SSLOptions +StdEnvVars Without this, you won't get any logging to your logs/svn_logfile file.
1 reply
Note that if you're using SSL (anywhere in the configuration, even if it's not actually for your svn stuff), you need one additional line, inside the : SSLOptions +StdEnvVars Without this, you won't get any logging to your logs/svn_logfile file.
1 reply
It seems to me that reuse repositories are a bit like corn fields. You can go down to Safeway, buy some ears of corn, bury them in the field, then dig them up ... and voila! you have corn! But not very much. And you probably don't want to eat it, anyway. If, on the other hand, you take a handful or a hopper full of seed corn, bury it, care for it, raise it up, and then harvest it, you get hundreds or thousands of ears of corn. Nice corn. Corn you want to eat. It's the same with reuse: if your attention to reusability starts when the product is finished, if you begin "reuse" when you toss the finished products into the repository ... then you won't get much reusable stuff, and it won't be very tasty. CollabNet products, services, and training enable you to produce software that's worth reusing, and to capture the development metadata like discussions and decisions as they happen. You don't have to build a separate catalog or generate separate documents any more than you have to bury corn silk and cobs: the process itself takes care of those parts, you just harvest them when it's done.
Toggle Commented Sep 21, 2010 on The Illusion of Control at On CollabNet
1 reply
The links in the base post for downloading Subversion are a bit stale. The community members who were keeping regular Subversion builds on Tigris have stopped doing that, because there are now professionally built and QA'ed (and still free!) binaries available, such as those on http://www.open.collab.net/downloads/subversion/ Also: the process of setting up and administering a server just got immensely easier, with the release of CollabNet Subversion Edge, also available at the above URL, and free: a 1-click install, and a web admin console.
Toggle Commented Sep 14, 2010 on Setting up Subversion on Windows at Coding Horror
One of the most lovely discussions of community management I've ever read is Karl Fogel's "Producing Open Source Software." The book captures his long history of community building, up through his leadership in the Subversion project. While there's some content there that's specific to software development, easily half the book is of very general interest. Karl makes the point that both kinds of "weeding" are needed. Guy's points about a light front-end process are represented here, but so also are some key stories about "weeds" that spring up later in the garden's life cycle. And I know, in my own garden, I certainly have to get out there and pull that oxalis periodically, not just at planting time! You also help to control weeds by ensuring that the crop plants are as healthy as possible: tend the garden, and the crops will squeeze out the weeds, rather than the other way around. It's a testimony to the front-end and on-going weed prevention that Karl can only come up with one "back-end weeding" story, from the whole history of the project: a case where a discussion contributor turned toxic -- not malicious, but somehow irreformably distracting. The model of pulling this weed, told in the "Difficult People" section, is an amazing lesson for us all, in how to handle such situations, and also in how healthy the community was fundamentally (as measured by the number of community members who were able to contribute to the weeding-out in an effective, inoffensive, yet firm way).
1 reply
Yes, thats the sort of thing I was shooting for. Good examples, thanks. Im not familiar with the nuances of EnterpriseDB/PostgreSQL, but I think Collabnet/Subversion is considerably closer to the open core / open infrastructure line than {IBM,Oracle,PrettyNearlyEveryoneOnEarth}/Apache: CollabNet doesnt own Subversion, but CollabNet is and has always been the clear and principal corporate sponsor of Subversion, whereas the Apache Foundation model has a longer list of rough equals.
1 reply
Thanks for your thoughts, Henrik. Im glad you find nothing objectionable in either Subversion or CollabNet! I wasnt particularly interested in defending either CollabNet or those other vendors you list. Rather, I was trying to move the conversation a bit towards how to do it right, and away from confrontation. If I may restate the objections raised by your blog and others, the offensive thing here is, as I understand it, obscuring the line between open and proprietary source. Your blog focuses on one form of obscurantism, mixing the two types into a single product and brand. But the obscuring also happens in another way: labeling all mixed-mode work with the same name. You left as an open question whether [CollabNets] model could be in the open-core bag, but thats the question Im opening. My belief is that open core is the most appropriate way currently available to describe the CollabNet / Subversion relationship, but I wouldnt choose to use that term because of the negative associations with other models within the space. I want a new term, not only to stitch onto my own golf-shirts, but to recommend to other companies looking for a successful and inoffensive model. Instead of excoriating people who use terms badly (when no better terms are available), lets set the terms of discourse so they identify and reward constructive models.
1 reply
It's also worth noting that this community functioned so well because many community members took the time, on their own initiative. That's why we call 'em "communities," and that's what makes 'em great!
Toggle Commented Jun 14, 2010 on Community Is... at On CollabNet
1 reply
Guy (with whom I've hashed this topic before), in his last two comments (a quote and a comment), can lead us out of the woods. I have no objections to the quoted statistical argument, "engagement outweighs most of the concerns, most of the time." And I think Guy himself captures what may be the central determinant: the fabric of trust. The cases where anonymity is not merely acceptable, but actually crucial, are just exactly those where "the fabric of trust" is already so riven that it can't be restored.
1 reply
Andreas - At the risk of repetition: your point, as I understand it, is that developers *can* use a DVCS in ways that provide the benefits I claim for central systems. I wasnt challenging that. My point was that they *might* *not*, which concerns enterprises, both because of the complexities of large organizations (such as conflicting goals), and because of the magnified risk in large scale (if each product team only makes such an error once a year, and there are 1000 product groups in the enterprise, how often does the error happen?). And, what particularly concerns me about the current crop of DVCS-based community sites: they seem *not* to be taking these measures, they seem rather to be concentrating on the liberties DVCS grants, with the consequence that they lose the characteristic benefits of central systems.
1 reply
I think you missed my point: its not that one *cant* operation in a centralized manner using a DVCS tool--indeed, most such projects do, to some degree. The concern raised by some is that you *neednt*, that centralization depends on the cooperation and memory of the developers at the edges. In the enterprise context I was describing, the shippable product often ships out of a point in the hierarchy a level or two below the top / center. If implemented in an DVCS, this means a separate push up-tree is needed. Pushing changes all the way to the top / center is not technically necessary to release the product, so theres no functional reminder to do it. If developers, project leads, and even managers forget, get too busy, or resist, then the delivery to the central repo might not happen.
1 reply
To restate your point a bit: open-source work needs a degree of community management not necessary in the enterprise. Is that close? I put it that way in order to lead up to another point: DVCS seems to encourage communities to neglect their community development. In the central-VC open-source world, theres a watchword Patches welcome! When used as a response to someone complaining about a missing feature, it means both more and less than it appears. More, because if the complainer goes on to actually provide a decent patch for the problem, then youve won another contributor. But less, in that the most probable response is to walk away grumbling. Its a put up or shut up kind of response, and its part of the process of developing users into contributors. Theres a similarly popular response in a DVCS community, but it means something rather different. Clone the tree and do it yourself is an easy response to end a debate going nowhere, but it lacks the implicit promise to review the result, should it appear. Of course, the community still *can* review a contribution made in this way--thats what DVCS is all about, the reason Linus gives for inventing Git. But it also can mean go ahead and make your changes, theyll just sink below the flood of private forks. The technical details of DVCS make a small but not insignificant contribution to this altered dynamic; the culture thats growing up around them looks a bit more to blame. But whatever the roots, one net benefit of switching to a DVCS is a lessened expectation of community development. Im not worried about Linux or JBoss or Python or any of the other high-profile projects--they have excellent community leadership in place, and well-established history and culture. But for the broad sweep of open-source projects, projects run by folks with less rooting in community development, this worries me.
1 reply
The implications of all this for innersourcing are subtle, and I was saving that for another post. First, as to the cost saving of Agile process: this is real and important, but I dont think it changes the fundamental balance in this situation. Agile process is a significant way to reduct the costs sunk in failure, but not in the same sense as open-source does. Agile has a fail early effect, and thats a cost reduction, but its real impact on the cost is that you spend your investments wisely: features and frills fail early, but its rare that the Agilista will scrub the whole project: in the enterprise, youve definitely decided you need a new web site, or a new widget, or whatever. Those requirements come from fundamental business and market needs that arent subject to Agile pruning. Agile process reduces the sunk cost, but never to zero. Open-source cheap failure is much closer to zero-cost, and includes a very high incidence of complete abandonment of the project. What DVCS really adds is cheap forks, and thats not an Agile idea (Agile is about doing the right thing, not doing everything imaginable and hoping something works), not an enterprise idea (enterprise is about doing the best we can afford). Similarly, innersourcing is a way of spreading costs throughout the enterprise, and holds the possibility of finding spare cycles among the consuming groups that approach zero-cost contribution. But it all still comes out of one companys payroll, and the community size is never enough to completely conceal the costs. Well, maybe if you have the whole DoD to play with ... but were not all that fortunate, Guy! So central management remains critical for enterprise work, and cheap forking remains inefficient, and a little scary. The bottom line, I guess, is this: if youre paying the bills one way or another, as is true within an enterprise, then you likely have a need to monitor centrally, and a central system is a useful management tool. If, on the other hand, you have significant hope of volunteers (or corporate contributors with independent budgets), as in the highest-profile open source projects, then decentralization might be a useful way to encourage it. Really large enterprises might have a sufficient ecosystem to approach the really large open-source dynamics (although with the rise of compliance requirements like Sarbanes-Oxley, its getting harder all the time); most (smaller) open-source projects are somewhere in the gray area where personal preference might just as well rule. As for requiring appropriate project management to match the tools ... well, thats true of any process/tooling shift. You know ... new wine, old wineskins?
1 reply
"Integrated hardware-software stacks as potential delivery vehicles for standardized workloads" sounds an awful lot like "appliances," to me. Didn't we do the hardware appliance dance, just a couple years ago? Didn't we "define where [we've] got to have choice and openness" already? Wasn't the answer "we *want* to buy the hardware separately; give us virtual appliances?
Absolutely, Brent! And don't forget the community-building mechanisms of "retweet," "via," overheard conversations, and the non-judgmental dynamics of following. Twitter is a strikingly simple technical product (you type, people see) with startlingly effective and numerous opportunities for linkage. And it's remarkably effective. A study has just been published (http://www.steverubel.com/study-twitter-is-made-of-80-meformers-and-20, which I learned of "via @JesseNewhart," as we say in Twitter) that reports an 80/20 split in "messages that are simply about me" vs. "messages with some discernible purpose." There's a lot of debate as to exactly what the two categories really imply, but one fairly safe conclusion would be that pretty much all of the 20% is about building the Macro Community--and not a little of the 80% as well. You might think that "only" 20% was a disappointing proportion, but here's a different perspective on that: Twitter is often compared to a cocktail party, or a neighborhood pub: no over-all agenda, groups form and re-form constantly and spontaneously, and it's more or less expected that you'll hear something interesting said over your left shoulder, and drift over into that conversation for a while. You've been at such gatherings, I'm sure, so think back and tell me: how many of the individual remarks were conscious attempts to include someone into a new group? 20%? I don't think so! 10%? 5%? 1%? "Consciously include--what's that?" Call me a wall-flower, but in my experience it's extraordinary to get more one person reaching out to me in an entire evening. But in Twitter, 20% of remarks are reaching out!
Toggle Commented Nov 25, 2009 on Building Relationships with Twitter at On CollabNet
1 reply
What a great question that is! As I considered an answer, it helped me realize that there's no such thing as "an online community" -- that is, no one such thing. Just like any other human groupings, there are many kinds, ways of forming, purposes, tenors, and answers to the question. Your answer to this question isn't about some absolute, eternal, singular truth: it's an insight into the community you think of as you answer. You might say "socialization," or "chat." That identifies a casual, friendly, informal community, an on-line analog of your favorite coffee house or pub or student center or living room. You might say "perspective," as Guy did, identifying a group with more focus: at least intent to consider substantive, difficult issues (whether life-issues or design-issues). You might say "answers," identifying a customer-support kind of community. While I agree with Guy that there are developer communities that function at the "perspective" level, though, I think the goal of the innersource Community Manager needs to be "synergy." As I watch highly functional development communities (such as the Subversion development team), the primary dynamic I see is an organized multiplication of the famous idea that "given enough eyes, all bugs are shallow." People come to the Subversion Developer's community (in email, discussions, or IRC) to lay a problem on the table, open it up, point out its thorns, and then hope someone else spots at least a thread of solution. A conversation may involve two people or ten; it may last an hour or only a minute, but very very often someone is able to spot something, or suggest a possible direction, or drop a keyword that sends the asker away better equipped to resolve the issue.
Toggle Commented Nov 17, 2009 on Community Perspective at On CollabNet
1 reply
It's not just mobile devices: http://bit.ly/2utafX For another view of the "Vanilla Soy Latte" story, see "Minority Report."
Fair enough, Matt, I'll take you at your word ;-) As to your question: of course you're right, that both copyleft and copyright are about controlling the down-stream developer. The difference is in the intended control: the one intends to increase the amount of sharing, the other intends to limit it.
Toggle Commented Jul 15, 2009 on Esteem, peers, and communality at On CollabNet
1 reply
Assessing community management by numbers of members or posts is a little like assessing navigation skills by the number of left turns—the real measure is "do you get where you want to go?"
Toggle Commented Jul 6, 2009 on Community Chameleon at On CollabNet
1 reply
Well, I disagree that open source is purely a money sink: rather, it's an investment. You get out more value than you put in. For example, we've several times tried to calculate how much we spent sponsoring Subversion, versus how much value resulted. That's a pretty hand-wavy sort of calculation, of course, but we've done it several ways, at several stages of the project, and the answer consistently comes out about the same: CollabNet invested about 25% of the cost of developing Subversion. But we get 100% of the value (and so does everyone else, of course). We deliberately reduced the cost of a key component by 75%, so we could spend that building the rest of the product. To some degree, that's covered in your "wallet wars" post, to which you've linked, but you show this "reduce the costs" phenomenon only for operating system and database, components that most of us out-source anyway. In this example, we applied the magic of open source development to reduce our *own* costs: it's a "money source," not a sink!
1 reply
From the Kniberg article, the single most important remark: On the whole, many teams seem to over-rate the benefits of implementing many stories concurrently. It gives a nice feeling of speed but can be an illusion since it pushes the risky and time consuming bits to the end - merging and integrating and testing.
1 reply