Today was also a really good day to be a phparch.com or pythonmagazine.com user—as previously hinted by our “office mole” we distributed over $180,000 in open-ended coupons (meaning that they have no restrictions and can be redeemed even if they exceed the value of the purchase). Except for a small bug that initially prevented $0.00 purchases from going through (if you’ve tried and had this problem, give it another whirl and it should work), things went off without much in the way of problems.

And so, as I wind down for 2007 and enter that most wonderful state of meditative bliss otherwise known as “vacation time”, I bid each and every one of my friends, readers, colleagues and everyone else who happens to stumble upon this post a happy, safe and peaceful holiday.

If one manages to dig through all the noise on the PHP internals mailing list, there’s a strange feeling of caution coming out of the core development team that, for some reason, just doesn’t feel like it belongs in a PHP discussion list.

Historically, PHP has been developed following the scratch-an-itch method: someone has an idea, or needs something that the platform doesn’t provide, comes up with a solution and either discusses it with the rest of the development team, or (in rarer cases, at least in the past) on the internals list and then posts it to the codebase.

This development process makes for some haphazard functionality, and has, in the past, been the source of many annoyances that need to be handled with extreme care—both in how they are fixed and in how they are maintained for backwards compatibility.

However, some of what are arguably PHP’s most interesting and features have also been born out of this very same system—for example:

• Object orientation in PHP 4 were added almost as an afterthought, and it showed. Despite the many problems that they caused, however, they also made PHP development worthwhile for many people and served as the main inspiration for the development of PHP 5, which, in turn, opened the door to many of the new features introduced by the latter.

• SimpleXML was perhaps misnamed, still has a lot of limitations and required several point releases before becoming truly usable, but, at least as far as I’m concerned, it’s what makes XML manipulation tolerable in PHP 5. Without it, we’d be stuck with DOM, which, despite using the same underlying functionality, requires, oh, three times as much code.
•  Type hinting has, more than once, saved my behind. It took it a couple of minor adjustments (e.g.: allowing passing NULL and supporting arrays) before it became truly useful, but without it we’d have a much poorer language from a maintainability perspective.

Overall, the spontaneity with which PHP has been developed in the past is a combination of sheer recklessness (“I’ll commit and deal with the consequences later”) and a process of discovery that improves what is worth improving, while letting the rest wither (but, unfortunately, almost never die).

The recent discussion about namespaces is a clear example of what is wrong about PHP today: not the endless discussion on internals, not the noise-to-signal ratio, but the fact that someone isn’t willing to just jump the gun, commit and let the chips fall where they may. If we continue down this road, I’m afraid that one day we’ll wake up and find ourselves dealing with the new Java: all decisions made by committee, and innovation dead, somewhere in the corner with no-one to care.

As convictions go, everybody seems to be convinced that he got off easy—”just” 72 months in prison and a repayment of around $6M. Personally, I doubt that anyone who learns he has to spend six years in jail would think of having gotten off easy, but journalists obviously have never gotten over him giving them the finger.

What a waste! A person like Conrad Black doesn’t belong in jail—he’s obviously not violent (I would have punched those idiots and their cameras, not just flipped them), and he’s a very capable man. The thought of him folding laundry and cooking lunch (and making sure he doesn’t drop his soap) while taxpayers, well, taxpay for keeping him behind bars.

That’s not justice—it’s stupidity. If you want to punish a person like Conrad Black for what he’s done, there’s no need to humiliate him by throwing him in jail. Justice can better be served by asking Conrad Black to actually repay his debt to society. Instead of locking him up, force him to work his debt off with punitive community service: make him live on the means of a salaried employees—no Bentleys, mansions, private jets… just a monthly salary, like one of the lowly people who used to work for him.

In the meantime, society could take advantage of Lord Black’s obvious talents to do some good—for example, get him to generate at least $60M in revenue for a charity, and limit where the money can come from and in what quantity to prevent his friends and family from simply bailing him out.

That, to me, sounds like a smarter way of punishing a man who is used to walking all over those around him. Since it would keep him out of jail and give himself a chance to make himself respectable again, he’d probably jump at the opportunity and save more taxpayer money by not dragging his trial case on for another five years. In the process, he might actually learn some humility, instead of humiliation, and actually be useful to society, instead of costing it money.

And, if you’re worried about him cheating his way around his community service limitations, have the court impose supervision in a way that becomes more complicated and expensive the less transparent he makes his dealings—and make him pay for it out of his court-imposed earnings.

• First of all, J.B. Nicholson-Owens posted a very detailed and well-written (if a little acerbic) rebuttal to my post (trackbacks are off in this blog, so if you write something referencing one of my posts, please leave a comment saying so). J.B. and I have a very different idea of freedom, best summarized in this sentence:
  

  Of course we can’t have all possible freedoms, as some freedoms conflict.

  Call me a hopeless naïve, but I believe that true freedom doesn’t need to be picked-and-chosen.

• Believe it or not, I have read the GPL, and I do understand it. Despite my unfortunate choice of words, I realize that using a piece of GPL software does not require redistribution of the source code. I meant the term “use” in relation to redistributing a binary package.
• The goal of my post was not to state that the BusyBox developers don’t have the right to license their software any which way they want, or that they don’t have the right to
  enforce the GPL, or that companies that do not comply with it are right, or that (at least according to the GPL) there is a difference between free as in beer and free as in freedom:
  

  Personally, I have no problem with the BusyBox folks suing the pants off of those companies that infringe on their license. They are, after all, very clear on their adoption of the GPL and what they expect those who use their software to do.

  I’m not sure how I can make it more abundantly clear than that, so I’m not even going to try.

• Ultimately, my point was simply this: is the value of BusyBox enhanced or reduced by their choice of license? Or, otherwise stated, if there were a compatible BusyBox replacement that were licensed under a BSD-style license, would it be more successful?

BusyBox is released under the GPLv2, a license which they have been aggressively enforcing, thanks in part to help from the Software Freedom Law Center. So far, they have sued companies like Monsoon Multimedia (note how the plaintiffs’ addresses are redacted from the complaint, but how the defendant’s was left in) and Verizon for selling and distributing products that incorporate BusyBox without disclosing their firmware’s source code as required by the GPL.

Personally, I have no problem with the BusyBox folks suing the pants off of those companies that infringe on their license. They are, after all, very clear on their adoption of the GPL and what they expect those who use their software to do.

Morally, however, I find the GPL repugnant. Its fight-fire-with-fire principle of forcing anyone who uses a piece of software to disclose all their source code in turn betrays its purported ideals of freedom in a disgusting way. There is nothing free about inflicting the GPL on someone just because they use GPL’ed software—it is no different from, say, your cellular provider preventing you from connecting anything but their devices to their network, or forcing you into a contract in exchange for a discount on the cost of your handset.

Open-source software should exist and thrive not necessarily because it is better from a technical perspective (although that is usually a consequence of its other characteristics), but because it is unencumbered with artificial limitations that throttle’s someone’s ability to use it. These could take the form of a commercial developer preventing changes that encroach on their business model, or non-commercial developers who impose limitations on usage and development on others to “encourage” transparency and openness. They are both artificial and limiting—but because the first set of limitations is enforced with profit as the ultimate goal, the peddlers of the GPL want us to think that it is somehow “wrong,” while the GPL’s viral characteristics are just and fair.

As a case in point, I am convinced that if someone came up with an alternative implementation of BusyBox that provides a compatible drop-in replacement that is not, however, encumbered by the GPL, but, say, released under a BSD-style license, BusyBox would suffer an immediate and definitive death for the simple reason that the “freedom value” of the replacement would be so much higher. I would even be willing to be that participation in the development of the replacement would be higher, simply because developers who use the software would not feel constrained by the overbearing limitations of the GPL.

I love, in particular, Rule #10 on this list, which reads:

Law #10: Technology is not a panacea

I wish more people would pay attention to this rule—outside of the realm of security. The ready availability of technology, together with the “your safety is someone else’s responsibility” attitude that pervades our society, has lulled us into thinking of technology in general, and software in particular, as something that has to be foolproof.

The problem is that software can only be as smart as the person who wrote it. Where more than one person is involved, the software they write is less smart than the sum of the intelligence of its creators. This means that the cost of development is not linear, but becomes exponentially higher with the complexity of the features that are being programmed.

Unfortunately, the complexity of a feature is usually inversely proportional to its simplicity from a user’s perspective. The mere act of insert a key in your car’s lock these days calls upon many high-precision features, both in software and hardware, that make the key and lock safe and secure, impervious to theft and, well, easy to use. But, to you, the user, it’s just a key and lock. If somebody told you that getting the key to fit in the lock and the whole mechanism to work probably took several million dollars worth of development time—and, still, the end product is susceptible to problems like freezing—you’d think that somebody was either crazy or outright lying. If that somebody were an engineer, you’d probably be wrong.

If complexity makes development expensive, in a controlled environment it’s relatively easy to do a bit of cost analysis and determine whether building something is worth the time (and money). A feature that saves, say 5 hours a month of customer support time but takes 100 hours of development time to develop must be considered very carefully—but the math is fairly straightforward.

The real—and hidden—threat behind not managing your development process well is, of course, feature creep and bloat. It is sometimes hard for a developer to refuse writing a new feature in a piece of software because of a number of overlapping problems: programmers like to program, and nothing is quite as challenging and rewarding as writing software that solves a problem—regardless of how real the problem is; it is difficult for a developer to make a user understand that because something looks simple to use, it isn’t necessarily simple to write. And users (including the developers and their increasingly bloated development tools) are simply jaded by the impossibly complex, and yet affordable technology that surrounds them.

How do you solve bloat? With a firm, but simple and unobtrusive development policy:

• Analyze every addition. Cost analysis doesn’t have to be complex, difficult or time-consuming. Simply ask the person who requests a feature to give you an idea of how much time that feature will save, and what benefits it will bring. Refuse to take answers like “it would help me greatly,” or “I’ve had many requests about this.” Always, always quantify these things in a way that can be measured.

• Estimate the cost of development. This is always hard, but it mostly depends on two things: first, have a clear spec from which to start. Have the developers discuss how a feature is supposed to work with the requesters. Second, get in the habit of coming up with reasonable estimates. Write down the steps required to implement the feature; ask your colleagues for opinions.
• Consider the long-term consequences. Even the simplest of changes can have disastrous effects on the long-term viability of your software. A feature that helps your users perform a task that has the potential for creating inconsistencies in your data, for example, is obviously a bad idea—that’s an extreme possibility, but there are usually unintended consequences to writing any piece of software, so be careful.
• Always explain a refusal. One of my biggest pet peeves with the PHP bug-tracking system is that it is built with more sarcasm than care. Terming a bug “bogus” and providing a canned answer to a bug report are simply stupid ideas for two reasons: first, they don’t add anything to the knowledge base built into the system, and second they discourage anyone whose skin isn’t thick enough to take it under the chin from ever filing a bug again—what’s the point if they’re going to make fun of you? Similarly, you should never dismiss a feature request on a project you’re working on simply because it’s silly. Remember—the whole point of software is to enable users to perform tasks that they wouldn’t normally be able to perform in the first place; therefore, the users won’t understand how the software works, or why implementing a particular feature is a bad idea, unless you explain why to them. Educating your users also has the side benefit of improving the quality of their relationship with the software they’re using—so that feature requests will, with time, become more reasonable and more useful.

On the subject of cost analysis, I think it’s important to point out that there is a good way and a bad way of doing it… but that’s the topic for a future post.