Canned Platypus

Yet again, I’m going to post about something related to my employer. Yet again, I’m going to reiterate that this is not an official Red Hat position. In fact, I more than half expect I’ll get in trouble for saying it, but it just had to be said. You see, there’s a discussion on Slashdot about How Can I Justify Using Red Hat When CentOS Exists? The poster wants the functionality of Red Hat Enterprise Linux, but the CIO doesn’t want to pay for it and demands that they use CentOS instead. A lot of people have tried to explain the various aspects of what a RHEL subscription gets you. I’m not going to expand or correct those comments, because that will definitely get me in trouble and partly because I just don’t care. Here’s the reason that apparently carries no weight at all with CIOs and never even occurs to Slashdotters.

Because it’s the fucking right thing to do, you assholes.

Yeah, I used profanity on what has almost always been a family-friendly blog. I did that because it’s so utterly infuriating that such an obvious and important principle has totally escaped notice elsewhere. If you value something, you pay for it. Even the worst free-market zealots claim to believe that. They often use the same rationale to justify eliminating regulations (especially environmental ones) or replacing public aid with private charity. Red Hat folks do more work than anyone to improve the Linux kernel, GNOME, and dozens of other projects. They write the code, do the testing, fix the bugs, write the documentation, and provide all kinds of logistical support. The beneficiaries include not just obvious derivatives like CentOS and Scientific but even commercial competitors from Oracle and Amazon’s obvious clones to completely separate distributions like Ubuntu which also package that code and fixes. This work isn’t done by volunteers. It costs a lot of money. The fact that we allow the code to be distributed for free should have nothing to do with the principle that you pay for what you value. When you violate that principle you ensure that there will be less of what you value. The result will be a net loss for everyone, as less innovation occurs and more energy is wasted making sure everyone’s “intellectual property” remains under lock and key. Even the thieves lose.

I’d really like to hear from someone who can offer a better moral justification than “we can so we should” for using CentOS on thousands of machines without paying for even one RHEL subscription, because nothing I’ve heard so far is even close. “Duty to maximize profits” arguments will be deleted, because I’ve already turned that one into swiss cheese enough times in my life. Does anybody seriously believe that freeloading should be on the “good” side of our collective moral map?

Charles Hooper wrote an interesting article about Letting Tech People be Socially Inept, in response to a recent incident at ThisWebHost where a technical director got mad at a customer and deleted data. There’s so much wrong here that it’s hard to know where to begin. “Jules” at This* was totally in the wrong. Charles is also wrong when he says that every position is customer-facing. Some people can do really great work only interacting with one person – usually their boss – and referring to that one person as a “customer” seems rather facile to me. Most of all, though, the puntwits on Hacker News are wrong too.

Probably the most common theme in the HN responses is that high technical skill and eschewing social niceties are closely and necessarily related because they both involve pruning away extraneous detail to get to the heart of something complex. For example, the very first comment there refers to “seemingly-meaningless boilerplate and social grease that we call people skills” and sets the tone for many that follow. The problem I have with this is two-fold. First, a lot of the bad behavior I see from my colleagues has nothing to do with social niceties. Go look at How To Ruin a Project and you’ll see that many of the items listed there don’t have anything to do with social skills. You don’t need a fine understanding of social cues to realize it’s wrong to miss the point, focus on the trivial, or wage “guerilla warfare” against a decision you don’t like. Those things might well have social effects, but they’re wrong even for purely practical reasons as well.

My other objection to the “boilerplate and grease” meme is that social cues actually do serve a practical purpose. They help to identify how strongly someone holds a belief, and how much importance they attach to the subject. Without that information, it’s easy to waste enormous amounts of time fighting wars that didn’t really need to be fought, and sometimes that leaves little time or energy – or poisons the atmosphere – for the debates that really do need to occur. One of the real problems I see with my fellow techies is a general lack of perspective, proportion, or priority. People who fail to give or read cues regarding these three important factors are demonstrating a deficiency that can affect even the most purely technical decision making. Being socially inept is not just cosmetic; it has a real and tangible effect on overall competence.

That brings me to the second most common theme in the HN responses: Asperger’s Syndrome. I’ve known quite a few real Aspies. I’ve known even more people who self-diagnose or self-identify that way as an excuse for being lazy about social interaction, so I won’t claim that I’m that way myself, but I will say I’m close enough (as is visibly the case for most of the other males in my family) to understand the challenges they face. I understand the “gravity” that always pulls one’s thoughts inward, and I know the pain of having to pull one’s attention away to deal with the “noise” that other people can generate. I will gladly do everything I can to accommodate people for whom these burdens truly are greater. I’ll teach them coping strategies I’ve learned from others, act as interpreter, run interference for them, whatever. However, there’s a difference here. It’s one thing to have a hard time understanding social cues. It’s another thing to understand those cues perfectly well and use that knowledge to troll more effectively. It’s really not that hard to tell the difference between an Aspie and an asshole; those who throw spitballs from behind a shield meant for others are not only jerks but cowards as well.

My conclusion is that Charles was wrong about everyone being customer facing, but right about the more fundamental reality that we techies in general need to stop being such jerks. We need to stop enabling the jerks by applauding when they act in deliberately offensive ways on HN, on Twitter, in conference presentations, etc. We need to stop pretending that the combative style prevalent on HN or LKML is the best way to facilitate progress; there’s no empirical evidence that “culling the herd” or “honing one’s weapons” or other such bloody metaphors really apply. We need to stop encouraging young techies to expend their energy emulating those styles instead of developing real people skills. Social skills really do serve a useful purpose, and anyone can improve them. That doesn’t make you less technical; it makes you more adult.

I think a lot of medium-to-senior programmers think it would be cool to run their open-source project, particularly if they have chafed under the leadership of someone else on another project. I’m not going to say it’s not fun, but after having done this for a while I think a word of warning is in order. You’re going to spend a lot of your time, for long stretches practically all of it, doing things besides the design/code/test cycle that individual contributors get to focus on. Here’s an assuredly partial list.

• Be your own IT staff. Set up a source code repository, mailing list, bug tracker, website, etc. Sure, there are distros and forges that will be glad to help with some of this, and it’s definitely better than having to set up every bit of software and keep up with every security issue on your own leased machines yourself, but even then you get to deal with someone else’s infrastructure team and release schedule.
• Be your own release engineer. The second biggest time-suck in your life is going to be managing branches and shepherding patches. As much as you might hate rigid coding standards and checkin policies, you’re almost certainly going to be the one defining and enforcing those for any project with more than (in my experience) two developers because otherwise things very quickly get out of control. On top of that, you get to deal with packaging as well and packaging issues can often take more time to resolve than almost any technical issue.
• Be your own HR department. Whether you’re actually hiring or just attracting developers for your project, you’re going to have to spend some time recruiting others’ participation. It’s actually harder for pure open source, because you can neither offer money nor do a proper interview. Some people who work in easy/popular specialties act as though interviews are passe anyway, but that’s total BS. There are still fields where most of the advanced work is still being done behind closed doors. If you relied on GitHub profiles to hire people for work on distributed replication, SSD tiering, or especially de-duplication, you’d practically guarantee that you’re getting the wannabes instead of the true experts (not that the “GitHub or git out” crowd is qualified to tell the difference). You’re going to end up interviewing and evaluating people either before they go through the door or after. Since it’s really hard to get rid of an incompetent or toxic person after, you owe it to yourself and the other members of your team to do the filtering before.
• Be your own marketing department. If you work at an actual company, whether startup or established, you might have full-time marketing folks to attract business interest, but they’ll be all but totally useless (and disinterested) when it comes to attracting technical interest so this is going to be the biggest expenditure of your time. Blog, tweet, attend conferences, respond to inquiries in email and IRC. Lather, rinse, repeat. If you’re lucky, you’ll get to spend time presenting to customers/partners as well, which means even more time away from the code but is obviously worth it. “Evangelism” is necessary partly as part of your recruiting strategy – see above – but also so that when you do talk to people about deploying your code you don’t find yourself taking a torpedo in the side from some techie who’s either unfamiliar with your project or already inclined to use something else.
• Write your own documentation. Developers hate writing documentation. They even hate reviewing documentation. However, if you’re running your own project you probably won’t have any trained and dedicated doc writers until very late in the game if ever, so you get to provide not only technical documentation but user documentation as well. No, a wiki doesn’t cut it, and neither does a FAQ on your website. If you’re really serious about letting your users figure things out for themselves instead of bugging you on mailing lists or IRC (which is even more time away from coding) then you’ll need to write not just technical documentation but end-user documentation as well. Writing man pages in nroff might seem like chipping flakes off a piece of flint, but you’ll still have to do it.
• Deal with legal issues. If you’re lucky you can avoid patents, but – as I’ve found out – you can’t avoid trademarks. You might also deal with contributor agreements and such where your project relates to others, even if you eschew them on your own.

So now you’re spending 30% of your time on recruiting and evangelism, 25% of your time playing release engineer, 20% of your time doing all these other things. What do you do with the other 25% of your time that you actually get to spend on code? Probably more than half of that time will be spent on “peripheral” pieces of the code – selecting libraries and debugging their problems, writing config/argument parsers, running static code analysis (including memory-leak analysis) tools, or generally filling in wherever there are gaps. Maybe you’ll get to spend 10% of your time doing the things that you started the project to do. Maybe not.

I don’t mean to seem like a total downer. Even spending 10% of your time on the parts you really enjoy can be worth it if that allows you to prove a point or make the world a better place. It’s better than working on someone else’s dream (or merely lining their pockets) during the day, and getting to spend only tiny scraps of your “spare” time pursuing your own dream. I’m just trying to sound a note of caution here. Be aware that when you turn your tinkering into an actual project you lose a lot of control over both its direction and your own involvement. Personally I don’t subscribe to the open-source mantra that you should start inviting others to participate as soon as you have an idea. That’s great for the kibitzers, but it’s not so great for the players who might actually be better off keeping an idea to themselves for a while before giving up the chance to work on it the way they want to.

(Yes, I’m playing devil’s advocate a bit here. There’s enough “big happy family” rah-rah out there already. Average that with the deliberately negative view I present here, and you might end up somewhere near reality.)

This is a bit of a riff on Jerry Weinberg’s ten commandments of egoless programming (via the also-excellent Jeff Atwood). I’ve found that many engineers, perhaps even a majority, respond more to aversion than to encouragement, so a “how not to” that can be inverted in one’s head sometimes works better than a “how to” taken straight. So here are the ways to turn a promising and fun project into a soul-sucking wreck. Take it from an expert.

• Miss the point. Never try to figure out what the project’s really about, or what it will be used for. Add features that have nothing to do with any valid use, removing or breaking other essential features in the process. Develop and test on a totally inappropriate platform. Confuse scalability with performance, or test the wrong kind of performance and then complain about the results.
• Claim authority you haven’t earned. Assume that your reputation or barely-relevant experience entitles you to sit at the head of the table before you’ve made any significant contribution. Push aside those who started the project, who have contributed/invested more, or are more affected by its outcome.
• Focus on the trivial. Spend all of your time – and everyone else’s – on issues like coding style, source-control processes, and mailing-list etiquette. Carefully avoid any task that involves a more than superficial knowledge of the code. Make others do the heavy lifting, then take half credit because you added some final polish.
• Be self-important. Make sure everyone knows this is the least important of your many projects. Insist that every work flow and library choice conform with your habits on those other projects so that your life will be easier, even (especially) if it’s to the detriment of those doing more work.
• Be dismissive. Clearly, your specialty is the one requiring the greatest technical prowess. If you’re a kernel/C programmer, look down your nose at web/Ruby punks. If you’re a web/Ruby programmer, look down your nose at enterprise/Java drones. If you’re an enterprise/Java programmer, look down your nose at kernel/C neanderthals. If you’re the world’s greatest maintenance programmer, specializing in minor tweaks to twenty-year-old programs representing many person-years of prior work , criticize the “immaturity” of new code that does new things. Above all, treat the specialty most crucial to your project as the exclusive domain of novices and children, with you as the “adult supervision” to bring it up to snuff in the areas that experts really care about.
• Argue from authority, not facts. If anybody provides empirical evidence to support their choice of a technique, algorithm, or style choice, ignore or reject it. Never provide any such evidence to support your own choices. Make sure everyone knows that your own personal experience trumps any such evidence, even if that experience is less (or less relevant) than others’.
• Lecture. Use every interaction as an opportunity to “educate” others about the reasons (rationalizations) for your personal preferences. Bonus points if you deliver a lecture on a subject that the recipient actually knows better than you, without ever pausing to determine whether that’s the case.
• Be persistent. If any decision ever goes against you, resist it forever. Treat every bug from then on, no matter how unrelated or trivial, as an excuse to beat the dead horse some more. If you’re at a company, use company time to pursue your approach instead of the approved one, and drag colleagues with you. If you’re working on open source, threaten to leave/fork.
• Be a hypocrite. Take some valid principle – portability, scalability, loose coupling – and use it to demand invasive change from others, then make your own changes that violate the same principle. Demand code reviews for every checkin, aggressively review others’ patches, then check in your own changes unilaterally. Bonus points if your unilateral changes were clearly never tested and cause grievous breakage.
• Be the martyr. After all doing all of these other things, your colleagues might not be keen to work with you again. Make sure everyone knows you were just trying to help, that you tried ever so hard to make them better engineers, and that the lack of gratitude reflects on them instead of you.

Many thanks to the people I’ve worked with who have inspired this. Without you, the list would be much less comprehensive. I hope its inverse will help others participate in projects that are more successful and fulfilling for all involved as a result.

So good old @dozba, in his typically endearing style, wrote about why MacOS X is an Unsuitable Platform for Web Development. His criticism about Textmate seems a bit silly, but his rants about package management remind me of my own problems with a proliferation of language-specific package systems, and “you don’t deploy to BSD” is spot-on. You would think that people would realize that developing on one platform for deployment on another can be problematic at best, but apparently the lesson needs repeating. At work, we even see glitches when people develop RHEL stuff on Fedora or vice versa, and those are both far more similar than the Mac is to anything you would ever deploy in production. What was even more amazing to me was the Slashdot reaction. Even knowing – all too well – how far Slashdot has declined, some of the stupidity on parade there literally made my jaw drop. Let’s review the main point here, OK?

Developing and deploying on different platforms is only OK if you stay well inside some kind of insulated sandbox and don’t care about performance.

The first part, about sandboxes, is mostly about avoiding functional differences between the platforms. If you ever use platform-specific configuration info or ioctls or anything else that requires an additional abstraction layer to make the code even run on both platforms, then you’re on very thin ice. Nine times out of ten you’ll be giving the people who actually deploy the code on real systems a good reason to hate you. As for performance, there are two sub-points. If you’re running in that nice insulated sandbox of a JVM, then its performance warts with regard to thread and memory handling will probably outweigh the warts in the OS scheduler and virtual memory systems. To a lesser extent the same might be true if you’re using Python or Ruby or Erlang. If the performance that matters is network or storage (filesystem/LVM/disk) performance, then you won’t even have that excuse. You just can not expect two operating systems from completely different families to exhibit the same balance and inflection points at different I/O rates, sizes, thread counts, etc. and all of the knobs for tuning around these idiosyncrasies will be different too. If performance matters at all for your application, you need to be working with the same performance ratios and tuning facilities across development and production. Does the Slashdot crowd seem to get any of this? Of course not.

Of course, you can dual-boot Linux on it or run it in VMWare. But you knew that, right?

Couldn’t be more wrong. If you’re doing anything virtual, then you’ve just made the matching-environment problem even worse, because now you’re subject to differences in both the host and guest OSes (and the hypervisor between them). Also, if you’re so addicted to running stuff in virtual machines then you’ll probably have a lot of them contending with one another and distorting the performance picture even more.

I can’t imagine writing code so finicky and unstable that it can only be cajoled into running under such a specific environment.

This guy has obviously never written anything but toy code. In the real world it’s very easy for code to run well on one platform, run poorly on others, and not run at all on still others. All you need to do is use one platform-specific feature, or rely on one platform-specific aspect of performance to guide your implementation tradeoffs. It’s writing code that runs on many platforms that can be a challenge, and code that runs well on many platforms is quite rare.

OK, so picking on Slashdotters is like shooting pithed fish in a very small bucket. The real point, though, is that all those developers using their MacBook Pros to develop code that’s supposed to run on Linux are doing their colleagues and users a great disservice. You don’t like the Linux environment as much? Too bad. Make it better. That’s how your deployment platform got to the point where you’re using it, after all. People used it, mostly liked it, and fixed/replaced the things they didn’t like so much, and added new stuff to scratch their own itches. If you use the same platform for development and deployment, then every improvement you make has twice as many chances to benefit someone else, and every improvement someone else makes has twice as many chances to benefit you.

Even before dot-bomb, I’d learned that “entrepreneur” meant two distinctly different things to two distinctly different groups of people. To one group, it meant an activity; to the others it meant an identity. It’s the difference between doing what entrepreneurs have historically done (mostly inventing things) and being like entrepreneurs have historically been – or, even more cynically, appearing like they have historically appeared. Having spent more time in startups than the vast majority of those who are or call themselves entrepreneurs, I feel a great deal of kinship with the first group. The second group? Not so much. These are the folks who come across as MBA types even if they actually have technical degrees (and sometimes non-trivial technical abilities). They dress like they believe entrepreneurs should dress, whether that fashion calls for suits or pure grunge or some blazer-and-jeans hybrid in any given month. They eat at the restaurants and drink at the bars that they think entrepreneurs are supposed to. They read the books and blogs that they believe entrepreneurs should read, they put in the hours that they believe entrepreneurs should put in (even if those hours are mostly on Twitter), they gravitate toward the office locations and layouts that they believe entrepreneurs should prefer. It’s like the old saying:

Sincerity is the key. If you can fake that, you’ve got it made.

Individuality is valued, so these folks try to cultivate it . . . but they all cultivate it the same way and end up looking more conformist than ever. Nowhere is that more apparent than in their adoption of entrepreneur jargon. Some of that jargon, such as that associated with VC/angel term sheets and such, actually has some grounding in reality. Other terms don’t, and the ones that have really been annoying me of late are “pivot” and “iterate”. I know all too well how important it is for a startup to be adaptable, but pivots and iterations are still ways of recovering from mistakes. They’re still something to avoid, not something to strive for. On average, the interval between such “about face” maneuvers should be longer than the interval between founding and whatever exit you prefer. It’s nice when a figure skater recovers from a botched landing, but if they spend their whole routine proving that ability then they’re not going to win a lot of titles. Somehow, though, many entreposeurs seem to think that being able to jump from one product idea to another is more important than being smart enough not to chase such ephemeral pseudo-markets, or executing quickly enough not to miss the boat on the first idea, or having the courage/honesty to admit that you goofed and move on to the next thing. Failure is not supposed to be a liability, right? We learn from failure, if you’re not willing to fail you’re not thinking big enough, yadda yadda . . . or maybe that was last year’s management-consultant money machine, because this year it’s apparently preferable to keep flailing around for something – anything! – that will keep the founders from having to get new business cards. After all, “founder of X” is their identity, couldn’t possibly let go of that now, could we? The irony is that I will almost certainly get comments from people who say the value is all in the team anyway, even though when the issue is inflated social-media-startup valuations those very same people will immediately forget the team and justify their paychecks solely by making up stuff about potential markets. It’s over here, no it’s over there, why cheat people out of dollars with three-card monte when you can play the same game for millions in Silly Valley?

Here’s a hint: don’t try to be an entrepreneur before you’ve generated any wealth for anybody. It doesn’t work. The way to be an entrepreneur is to have an idea you’re willing to stick with, and then build a business around it. If you have to put aside the starving-artist chic and actually work in the corporate trenches until you have some clue which ideas are actually worth pursuing (and haven’t already been done), so be it. That’s how every real entrepreneur I’ve known did it.

I’m in Tempe for the Fedora Users and Developers Conference, a.k.a. FUDCon. Here are some random thoughts.

• Enhanced pat-downs aren’t so bad.
• The weather’s nice. I should have expected the palm trees, but I totally didn’t expect to see orange trees with ripe fruit hanging just out of arm’s reach (because the ASU students picked everything lower already).
• The ASU campus is much more interesting and varied architecturally than any other campus I’ve been on. Sure, the color palette is a bit limited – light brown, dark brown, reddish brown – but the shapes and textures make up for it. Actually there was one nice splash of color, which was a gigantic wild rose bush clinging to the side of one building. That ugly bump just north of campus doesn’t do much for me, though.
• I haven’t seen a single squirrel on campus. I did see two cats, though – fluffy persians who must be very uncomfortable in all this heat. I’ve seen and heard lots of unfamiliar birds, too – mostly grackles, I think
• Meeting people in person is great. The Fedora crowd is notably casual, international, and friendly – even by technical-conference standards, in all three regards. I’d particularly like to thank Robyn Bergeron and Seth Vidal, very busy leaders in that community who have nonetheless gone out of their way to make me feel welcome and included. It was also especially nice to meet Pete Zaitcev and Major Hayden, because we’ve interacted so much online but never met until now.

Here’s a Flickr set for some of the pictures I’ve taken while here. OK, enough of the fluff. What about the real stuff? More bullet points, because that’s how I roll.

• The whole “Bar Camp” style of pitching and voting on sessions was new to me. It did seem to work, though.
• The first talk I attended was Marek Goldmann talking about BoxGrinder. I was pretty familiar with this work from my own involvement with Deltacloud/Aeolus, but Marek deserves kudos for presenting it well and even giving a live demo.
• After lunch, it was Steven Dake talking about Sheepdog. Again, it’s work I’m familiar with. I think Steven and I will never quite agree on the value/importance of Sheepdog. On the one hand, the notion of distributed block storage has been very appealing to me for a long time. It’s why I went to Conley in 1998, and worked on C3D at EMC a few years later. On the other hand, block storage using a single specialized application interface which isn’t even as complex as the real system-level block device interface seems a bit unambitious to me. It just limits the applicability of the result too much IMO, and that seems a meager payoff for all that work solving the harder distributed-data problems. Of course, in this case it’s all NTT’s effort anyway. As far as the talk, a comparison to RBD would have been nice since anybody who’s interested in one should definitely check out the other as well.
• Next up was Mike McGrath, talking about how cloud computing is going to displace non-cloud computing. Even as somebody who’s working on cloud stuff, I’m a little bit skeptical. Still, it was a good talk to get people thinking about all the implications.
• I’ll skip the next talk, since it was mine and I’ll have more to say below.
• The last talk of the day, for me, was Chris Lalancette talking about cloud management – especially Deltacloud and Aeolus. Having worked for a while on this project (and sitting about twenty feet from Chris most days) this was also pretty familiar territory, and Chris did a good job presenting on a complex subject. I apologize to both him and to Tobias Kunze (with whom I had an awesome chat later in the evening BTW) for putting them on the spot about the relationship between Makara and Aeolus.

So, how did my own presentation go? Somebody pointed out that I’d seemed a bit on edge the night before. Partly that was just the stress of travel and of being an introvert mingling with an unfamiliar group of people, but there’s another factor that I hadn’t even consciously realized until I was writing this post. I’ve presented about CloudFS privately and/or in fairly abstract terms so many times that I’d actually forgotten this was the first truly public presentation about a concrete thing that I’ll actually be delivering in the near future. That’s a big deal. I was a bit concerned at first because they’d put me in the largest room and at five past the hour it was still three-quarters empty. Nobody likes talking to an empty room. Shortly after I started, though, the room was pretty much full – not standing-room-only full, but I don’t remember seeing many empty seats. Not that I was trying too hard to count, of course; I was otherwise occupied. Even better, people were engaged. There were many questions, and they were good questions – questions that to me indicated genuine curiosity and constructive intent, not just the “I’m going to prove I’m smart” or “if you don’t get this one right your project will look silly” kinds of questions that one often gets. The post-presentation chatter even went on so long that Chris had to kick us away from the lectern. Good problem to have. :)

The best part of all, in my opinion, was outside of the talk itself. In at least two other presentations, and in even more hallway conversations, the possibility of using CloudFS to solve some problem or add some functionality came up. Also, at least one person had clearly given the code a pretty detailed look since my talk, asking questions and making comments about internal details that he could not have known about otherwise. That is so cool. It’s all very well to have people’s attention for an hour or so before people move on to the next new thing, but when something you’ve talked about shows up in colleagues’ own thinking about how to solve their own problems that’s an even surer measure of being on the right track. Thank you, everyone, for letting me be part of the broader progress we’re all making together.

I try to keep blogging about $dayjob to an absolute minimum, but this is kind of a big deal. Today, I pushed the first bits of CloudFS out to a public git repository. A week or so ago I registered cloudfs.org to hold non-code content, but it’s not really up yet so for now you can clone that repository and look at the README.md therein, or at the Fedora 15 feature page. Here are a few nuggets to get you started.

• CloudFS is basically GlusterFS enhanced to allow deployment by a provider as a permanent shared service, rather than as a private thing that users can run within their own compute instances.
• The enhancements necessary fall into several broad categories: authentication, encryption, isolation (each tenant gets their own namespace and UID/GID space), quota/billing, and some necessary enhancements to existing GlusterFS functionality.
• This is a very pragmatic and unambitious release, explicitly not including the improved-DHT and multi-site-replication functionality that I think will make CloudFS really cool. Think of it as a warm-up to the main attraction.
• The code is nowhere near complete. The three translators I’ve written are complete enough to do useful things – and more importantly to be worth reviewing – but all need to be improved in various ways and there are other bits (mostly around configuration and management) that don’t even exist yet. To put it another way, I think the code represents that point on a journey where you’ve climbed the highest hill and can see the destination, but there are many miles yet to be walked.

Once I get cloudfs.org set up the rest of the way, I’ll probably start posting more info there. Stay tuned.

When you hear that someone’s a good programmer, what do you think that means?

• They write lots of code.
• They write good code (e.g. clear logic , good error checking, etc.)
• They write difficult code, that’s difficult to get right or debug when it goes wrong.
• They write innovative code, representing new algorithms or techniques.

All of the above, you say? Sorry, you don’t get all of the above. An average programmer can do two of these things, but not at the same time. That means nearly half can’t even do that well. A pretty good programmer can do three, two at a time. A very good programmer can do all four, perhaps even three at a time. There are programmers who can do all four at once, but they’re like people who can juggle eight balls at once – you’ll probably never meet one.

My point here is not to say programmers suck, or that one combination of abilities is better than another. The real point is that programmers can be good in different ways, even if none of them are perfect, and if you want to get the most from a group of programmers it can really help to recognize these differences. Programmers with one set of strengths love to dump all over programmers with a different set, but specialization is the cornerstone of our profession (if not of the entire economy that supports it) and specialization cuts across styles as well as technical areas. If you can get your specialists to complement and reinforce one another, instead of undermining and alienating one another, you can do great things that no band of generalists could match. Don’t celebrate diversity for its own stupid sake; this ain’t no hippie commune. Exploit diversity to get things done. It happens to be true that people are happier when they’re working to their strengths instead of conforming to some arbitrary “jack of all trades and master of none” standard, but that’s just icing on the cake. Being successful makes people happy too.

As always, follow @Obdurodon for more.

• It’s an antipattern to use “it’s an antipattern” as the worst insult you can think of for something that’s not a pattern.
• OH: “I’d run Eclipse to take a look, but I want my machine to have some resources left for real work.”
• I’m going to stop talking about cloud storage. Clouds are ephemeral. OceanStore had the right naming idea.
• Every time a programmer uses goto, an architect dies a little. Die, you bastard, die!
• If you want authority, take responsibility.