Wednesday, March 29, 2006

win32 socket commits [194.5]

My IRC icon was bouncing in the dock this morning when I got into work, which means someone referred to my nick. I assumed it must have been from conversations the night before, but upon scrolling back realized it was actually rudi talking about committing my win32 socket patch into the repository. Happy, Happy, Joy, Joy. How many thousands of lines of code have I committed to Paragent's repository that are in a shipping product? Hell, I'm the boss, it has to be accepted. There is a certain warm-and-fuzzy feeling when you are able to contribute something that others find of value.

I didn't get into open-source because of all the free-as-in-speech fist-pounding. I enjoy it because I get the chance to interact with some very smart people. I hate to say it, but when I see that a piece of open source code has a GPL license it turns me off. Not because I think "gee, we can't rip this off like BSD or MIT licensed code," but because I assume that the original creator has some anti-corporate axe to grind. The only real argument that I see for a GPL style license is that it allows the powers-that-be to force companies to provide their enhancements to the code base to everyone else--when they get caught. While there have been a few cases of companies being called out on their GPL violations, I would like to know how many of those have resulted in some stunning contribution back to the source tree when they finally complied. My bet is that it has never happened.

An open source software project is not like some Wikipedia that can be edited by anyone at will. Any software project worth stealing is going to be complex. This requires the coordination of some smart people to organize, filter and commit changes. Programmers that want to contribute have to minimally participate in the community. You have to want to do this. Forcing companies to make source code available for applications that anyone can get the code for off of source-forge is just petty.

This reminds me of a parable:

"For the kingdom of heaven is like a landowner who went out early in the morning to hire men to work in his vineyard. He agreed to pay them a denarius for the day and sent them into his vineyard. About the third hour he went out and saw others standing in the marketplace doing nothing. He told them, 'You also go and work in my vineyard, and I will pay you whatever is right.' So they went. "He went out again about the sixth hour and the ninth hour and did the same thing. About the eleventh hour he went out and found still others standing around. He asked them, 'Why have you been standing here all day long doing nothing?' 'Because no one has hired us,' they answered. He said to them, 'You also go and work in my vineyard. When evening came, the owner of the vineyard said to his foreman, 'Call the workers and pay them their wages, beginning with the last ones hired and going on to the first.' The workers who were hired about the eleventh hour came and each received a denarius. So when those came who were hired first, they expected to receive more. But each one of them also received a denarius. When they received it, they began to grumble against the landowner. 'These men who were hired last worked only one hour,' they said, 'and you have made them equal to us who have borne the burden of the work and the heat of the day.' But he answered one of them, 'Friend, I am not being unfair to you. Didn't you agree to work for a denarius? Take your pay and go. I want to give the man who was hired last the same as I gave you. Don't I have the right to do what I want with my own money? Or are you envious because I am generous?'

The parable is actually about the last being first/first being last/everyone is equal, but that is not what I am interested in. It is also a telling commentary on how people can convince themselves that they have been "wronged" because someone got a better deal. The people who contribute to open-source projects do so because they want to, expecting no monetary reward. I certainly don't expect to be rewarded because I contributed some small bit of socket code to a Lisp project. So now some corporation comes along and uses said software. Have I lost anything? Have they taken away that warm-fuzzy-feeling, or the sense of camaraderie that I feel for everyone trying to make a better free Lisp? I contributed the code without any expectation of compensation. Why should I be jealous of the fact that someone else has found a way to make a buck off of it. There is already a perfectly viable method for making sure that individuals are rewarded "fairly" for their work - it is known as "closed-source."

Less politics, more coding.

Sheesh - how did this turn into a GPL rant? ... sorry about that.

Monday, March 27, 2006

SBCL devs gettin bank [194.5]

An employee of ITA Software let it be known that his company might be willing to provide a little incentive to speed up the compile times of SBCL in the way of cold hard cash. So far there haven't been any public takers, but sbcl-devel is a pretty low-traffic list. Also, it could very well be that conversations have been taken offline. I found this post interesting because I have been contemplating a similar move to get work done on the win32-side of the house. Bringing the win32 port to parity with Linux would make life much easier for us. There are also some very specific things that are not high-priority items such as executable packaging and tree-shaking that it would be nice to have done. The economics of this are very interesting. We can either fork out serious money and just get a commercial implementation such as LispWorks or Allegro, or we can pony up bounties for people that are already inclined to do the work to bump it up in their prioritization. The benefits going forward in good-will alone make sense, and the bounties would probably cost less in the long run.

Our experience with Microsoft support has definitely opened my eyes to the economics of coding. Sometimes it is simply more cost effective to pay someone else to do the work. I think that all good programmers like to think that they can get anything working. Calling for reinforcements only makes sense if you do it soon enough to make up for the wasted time that would have otherwise been poured down a black hole. A Microsoft incident costs $245. Depending on what you pay your programmers your break-even point will be different, but if it is something you think will take more than two or three days to figure out, you will "save money" by having a Microsoft programmer figure it out for you. I had to put save money in quotes just then because most likely the work you are displacing to your support structure is being done by a full-time employee, and therefore you will be paying them regardless. In fact, you are not saving money in a way that can be tallied up very easily. The real cost savings comes from how much it is worth for your company to ship its product two weeks or even two days earlier. For it really to be cost effective, you probably need to be saving a week or so per call, and there has to be some definite benefit to getting your product out sooner. If you need that product for revenue, it makes all the sense in the world.

The trick is knowing when to throw in the towel early enough on an intractable problem to get the most bang-for-the-buck. Of course, these aren't double-blind experiments here. We only know how long something is going to take to fix after we've fixed it. This is probably a good reason to keep your bug-tracking items up-to-date with estimates of how long it will take to fix. After time, you can get a sense for whether you are a good estimator of bug difficulty. Use the bug-tracking system as training. Once you have developed the skills to accurately estimate what bugs will take the longest to fix, you could do a simple sort of all your current issues, take the ones that have long estimates, and figure out if it is something you could have done by bringing in the big-guns.

Sunday, March 26, 2006

a Mini update [196.5]

hmm, it has been a couple of weeks since I have posted anything. Typical.

The win32/sbcl work has been in a two steps forward, one step back kind of mode. I had all but two contribs building, and was even getting asdf-install worked out when I decided to update my tree from CVS. While necessary, it pretty much borked my tree. I had to do a clean checkout, and then move everything back over by hand to figure out where the breakage occured. Sockets are working again, but I seem to have lost the asdf-install build. sigh. Since those aren't strictly necessary for what we need in the agent, I am not going to worry about it.

Jasko got his MacBook Pro this week, and we spent a few days messing around with it. Tim got Windows XP installed on it. Hopefully someone will work out the video driver stuff. The XP install took several reformats to get right. Unfortunately, it does appear to have the infamous "whine." Tim kept complaining about the fan noise, so I suggested the mirror widget trick, and that seemed to solve it. I am assuming this is something Apple can fix in a software update. The laptop is otherwise pretty sweet. I can't wait to get one! We had fun playing with the photobooth software and making funny pictures of ourselves. Tim ended up with a great alien shot.

The rest of the laptop install was getting sbcl/slime/emacs/mysql/clsql/ucw up and running. The sbcl port is still in a, ahem "fluid" state right now. It mostly works, but seems to periodically fall over. slyrus and nfroyd from #lisp are working hard at getting the last issues worked out with the new lutexes. While sbcl has a great threading implementation on Linux, its dependency on the linux-only futex has created problems porting it to other platforms. The x86/darwin threading port is the main front in attacking this problem with the creation of a lisp futex - lutex. While our production servers will all be linux, we really need threads for the agent running on a variety of platforms. Getting lutexs working reliably appears to be the bottleneck for that happening. Once lutexes on x86/darwin are reliable, it can be used to get threads working on ppc/darwin and win32.

What this is all leading up to is the news that I bought a Mac Mini yesterday. In fact, there were a number of small excuses for getting one: a) I want to take my G5 back to work so I can get back to a Mac as my primary environment. b) I want to help get lutexes working to make sure Jasko is able to do lisp work under OS X on his laptop without going crazy. c) lutexes are the gatekeeper to being able to use a single platform to deploy our agent across linux/os x/win32. d) I was jealous of Tim's new laptop.

I got the core duo with 512MB of ram. It is a pretty sweet little machine, and should do a pretty good job. My only gripe so far is that I am getting the beachball of death a little too often when I switch between apps, but I am doing a lot of heavy lifting. My assumption at this point is that the 512MB of memory is borderline, and that I am seeing paging activilty as I bring different apps into the foreground. I am going to save up my pennies and buy some more ram for it in a month or two. I assume that most people aren't doing multiple sbcl builds while they are also installing applications, browsing the web, and generally mucking about.

What this thing really needs is a new monitor. I have my eye on the Apple 23". I need to set a suitable goal for getting that thing. Maybe when I reach my target weight...