Unsung Heroes of Python: asynchat/asyncore

Python is known for its "batteries-included" nature. One of the batteries that gets too little attention, I think, the asynchat module.

One of my pastimes is playing a certain web game, which features live chat. In a previous incarnation of the game, one of the players wrote a very useful "bot"--an automated pseudo-player that sat around in chat, and provided useful information when queried. She quit before the newest revision of the game was released, though, and some of the players were missing the bot.

So, I pulled out the asynchat module, launched Ethereal, and started reverse-engineering the chat protocol (source and some documentation are available, but the version I was talking to seems to be somewhat customized).

45 minutes later, I had a fully-functional bot. Another hour, and I had a nicely-factored module from which you could build a whole new ultra-wizzy chat client. (Teaching the bot all about the game took another eight hours, of course, but I don't think any libraries would help with that...)

Now the cooler-than-thou Pythonistas out there are probably saying, "Bah! Twisted Rules!". That's nice. Twisted may be sexy, but asynchat/asyncore has some advantages:

• It's simple. Two modules, under 1k lines of code (as opposed to a raft of modules and 80k lines of code). No surprises.
  
• It's documented, so I don't have to hang out in an IRC room or grovel through thousands of lines of code to figure out what's wrong.
  
• It's included with Python, so I know it's tested--no surprises when I try it on a new machine.
  
• It's written in everyday bog-standard Python, not its own framework on top of Python, so there's no prerequisite learning to do.
  
• I'm reasonably sure that it's not going to be drastically changed.
  

So, for grinding out TCP/IP-based tools quickly, nothing beats asynchat. It probably would have taken me three times as long in C or C++, and if I'd started with Twisted, I'd still be reading Twisted source code...

Businesses can take hiring tips from Open Source

Dave Friedman and Doc Searls had an interesting discussion on the difference between "hiring" in open source and business. Doc railed against hiring based on flawed measures like academic degrees and IQ tests; Dave concluded that businesses and open source projects are so different that the same practices can't work in both. I think there's a better way.

Dave admits that academic degrees and IQ tests are imperfect, but businesses have to use them to evaluate potential employees because there's no other way to do it. The "anarchic world of open-source coding" doesn't use them, because there's no evaluation to be done: "any person can contribute to the code, at any time, regardless of qualification".

On the contrary, no serious Open Source project would ever think of letting Joe Random contribute changes at will. Sure, anyone can download the source and make their own changes, but "commit privileges"--the ability to make those changes to the official codebase--are tightly controlled. That's a big distinction.

Open Source contributors start by having to submit every change as a "patch" to the existing code, rather than changing the code directly. A current developer examines the patch, then either rejects it or commits it on the contributor's behalf. After slowly establishing a track record of both good patches and the ability to work with the rest of the team, the contributor may receive the ability to directly commit his own changes.

On most projects, even programmers with years of experience and spotless reputations have to go through this process. Some projects are so conservative with commit privileges that even valued, long-time contributors still have to submit patches.

So granting commit privileges to a contributor is the Open Source equivalent of hiring an employee. Both represent serious commitments--an incompetent contributor with commit privileges is as dangerous to the project as an incompetent employee is to a business. And revoking commit privileges carries the same political and psychological baggage as firing an employee.

Businesses try to predict whether a candidate will be a good employee, while Open Source projects say, "show us you're good by doing work at no risk to us, and then maybe we'll offer you a position." It's unlikely that the software industry can get away with this--the media and medical industries do, but only for entry-level positions. So what can we do?

I think the solution is to increase our use of true "contract-to-hire" positions. Contract-to-hire gives the company the ability to bring a candidate on at low risk, then hire the candidate or decline with no repercussions. It's also far better handling the unfortunate case of a competent employee that simply isn't a good fit for the company, because it limits the company's liability (both legal and emotional) while letting the employee avoid a resume-busting dismissal.

Yes, some companies abuse contract-to-hire. I know one programmer who was assured he would be "converted" in six months, only to spend two years in "headcount limbo" before being released with no warning. To be fair to both parties, the contract has to specify both the duration of the contract and a deadline for exercising or declining the option to hire.

The lack of benefits like health insurance for contractors is an issue, too, but it's hardly insurmountable. Contractors already command higher rates than they would get as full-time salary in order to pay for the missing benefits. When negotiating the contract terms, negotiate the proposed full-time salary (and thus the contractor's "benefit allowance") up front.

Fair and honest contract-to-hire is a win for both employers and individuals, and it's the only way I can see to achieve the hiring benefits Open Source projects enjoy. So what am I missing?