Do you remember enterprise application integration? Those were the days. First you paid to bury your information in someone’s proprietary silo, then you paid to excavate it from there, then you paid again to bury it again in someone else’s silo. Everybody was happy. Except for the guys paying the bills.
I went to see the guys in Osmosoft yesterday, it’s always a pleasure visiting them. At BT Design, our approach to innovation has a significant community focus: Web21C, now integrated into Ribbit, was formed on that basis; both Osmosoft as well as Ribbit are excellent examples of what can be done with open multisided platforms.
While I was there, I spent some time with Jeremy Ruston who founded the firm and leads the team. Incidentally, it was good to see Blaine Cook there, I hadn’t seen him since he joined BT. Welcome to the team, Blaine.
When it comes to opensource, Jeremy’s one of the finest brains I know, we’re really privileged to have him. We got to talking, and somehow or the other, one of the topics that came up was the ways and means we have to figure out if someone’s any good, in the context of hiring. After all, there is no strategy in the world that can beat the one that begins “First hire good people”.
When you’re hiring people with experience, the best information used to come from people you knew who’d already worked with her or him. Nothing beats a good recommendation from a trusted domain. You can do all the interviews you want, run all the tests you can find, do all the background searching you feel like; over time, the trusted domain recommendation trumps the rest.
Now obviously this does not work when the person has not worked before, where there is no possibility of a trusted domain recommendation. Which is why people still use tests and interviews and background checks.
Which brings me to the point of this post. Jeremy brought up an issue that he’d spoken to me about quite some time ago, something I’m quite keen on: the use of subversion commit logs as a way of figuring out how good someone is.
And that got me thinking. Here we are, in a world where people are being told: Don’t be silly and record what you do in Facebook; don’t tell people everything you do via Twitter; don’t this; don’t that; after all, the bogeyman will come and get you, all these “facts” about your life will come back to haunt you.
As a counterpoint to this, we have the opensource community approach. Do tell everyone precisely what you are doing, record it in logs that everyone can see. Make sure that the logs are available in perpetuity. After all, how else will people find out how good you are?
Transparency can and should be a good thing. Abundant transparency can and should be a better thing, rather than scarce transparency. Right now we have a lot of scarce transparency; people can find out things about you, but only some people. Which would be fine, if you could choose who the people were. Do you have any idea who can access your credit rating? Your academic records? Do you have any idea who decided that?
Scarce information of this sort leads to secrets and lies and keeps whole industries occupied. Maybe we need to understand more about how the opensource community works. Which, incidentally, is one of the reasons why BT chose to champion Osmosoft.
An aside: David Cushman, whom I’d known electronically for a while, tweeted the likelihood of his being near the new Osmosoft offices around the time of my visit, so it made sense to connect up with him as well. It was good to meet him, and it reminded me of something I tweeted a few days ago. How things change. In the old days relationships began face to face and over time moved into remote and virtual and electronic. Nowadays that process has been reversed. Quite often, you’ve known someone electronically for a while, then you get to meet them. Intriguing.
Finally, my thanks to gapingvoid for the illustration, which I vaguely remembered as “Excavation 47”. It was a strange title so it stuck. Which reminds me, I have to start saving up to buy one of his lithographs, they’re must-haves.