As of this writing, the DNS/infrastructure hasn’t quite caught up, but ofbiz.apache.org ought to be live soon. “Apache Open For Business”, aka OFBiz, has been promoted out of the incubator (the term the ASF uses for projects hoping to become full-fledged ASF projects) to its own top level project.

As J Aaron Farr mentions, they managed most everything on their own, and were a project that wouldn’t have looked out of place as part of the ASF even from the beginning of the incubation period, which made my job as a “mentor” pretty easy.

What will be interesting is to track the project going forward. It has tremendous potential, because it focuses very much on providing not only the low level tools (which is still where most open source is), but also on creating good business models and processes, which is relatively newer terrain in the open source world.

I think they face a couple of important challenges. First and foremost, a way to lower the barrier to entry. OFBiz is a big collection of code that in some ways tends to stand alone compared to the “mainstream” in that it uses its own tools in terms of the framework. Also, since it encompasses so much, it’s a lot to come to terms with when you get started. This means that the initial step of the “learning curve” is pretty high, and I imagine that a lot of people stumble. Clearly, it’s not a simple application, but I think efforts to make it more approachable will pay off in terms of attracting more users (and eventually, developers).

The broader challenge is simply the fact that in some ways, this is uncharted territory for free software, so it remains to be seen what sort of “ecosystem” (if you’ll pardon the buzzword) grows up around it. For instance, at this point in time, no one, least of all the core developers, sees it as a program that you simply download and run, but rather as a place to start from for integrators and developers who mould the code to fit the needs of the particular firm adopting it. That’s working right now, but perhaps at some point it will be more of an out of the box system. Or maybe not – attempting to make it work well for a vague ‘everyone’ might just be chasing taillights and prove ultimately fruitless.

Unfortunately, I still haven’t had the opportunity to use it “in anger”, as they say, so I don’t have much to say about it technically, but from a business point of view, I really like their data model, and the system of processes they’ve put together, which allows you to capture a great deal of use cases in a very flexible way, which is no mean feat.

In any case, a big round of congratulations to the core developers, and best wishes for the future!

In a few days, I hope to launch a little project that I’ve been working on, that was inspired by some concrete needs at work. That’s nothing new, as I’ve often undertaken new projects after seeing needs out there in the ‘real world’. What’s going to be different this time, though, is that I’m not going to release it as open source software. Instead, I’m going to make the basic version available for free on the web, and charge money for more advanced versions, in various ways.

That’s a pretty big change for me, as I’m very dedicated to the idea of open source software. It’s simply more fun than the proprietary sort, and I love cooperating with other people on things, and all in all, it’s just easier to release stuff that way.

However, I want to try something new… I want to see if I can make some money on a few ideas and projects that I have in mind. I’ve thought about it a lot, and the shortest, most direct feedback loop in the types of end-user applications I have in mind is going the ‘commercial’ route. If I can make a bit of money on the applications, I can spend a bit more time either improving them or developing new ones. If they were open source, the most I would get is other people contributing a little bit back, but that doesn’t matter much, as none of these ideas are all that complex.

I’m not giving up on free software… I couldn’t. My hope is that by providing myself some extra income, that I will be able to produce some free software as a ‘side effect’, ala 37 signals or google, or any number of other groups that contribute a lot of ‘side dishes’ to open source, while saving the main course to make their money with.

Hopefully you will see more in this space in the next few days.

Apples and Oranges

A number of people wrote irate comments after my article about Ruby’s eBay API beating PHP hands down. They complained that I was comparing apples to oranges, because the Ruby library I was using was nicely crafted, whereas the PHP one was some crufty crud that just happened to be one of the first things you find when you go to developer.ebay.com.

First things first, let’s look at some better PHP code:

require_once 'EbatNs/EbatNs_ServiceProxy.php';
require_once 'EbatNs/EbatNs_Logger.php';
require_once 'EbatNs/GetItemRequestType.php';
require_once 'EbatNs/ItemType.php';

$session = new EbatNs_Session('config/amd.ebay.config.php');

$cs = new EbatNs_ServiceProxy($session);
$cs->setHandler('ItemType', 'handleItem');

$req = new GetItemRequestType();
$req->setItemID(5652664344);
$req->setDetailLevel($Facet_DetailLevelCodeType->ReturnAll);

$res = $cs->GetItem($req);
echo "<pre>";
if ($res->getAck() != $Facet_AckCodeType->Success) {
echo "we got a failure<br>";
foreach ($res->getErrors() as $error)
{
    echo "#" . $error->getErrorCode() . " " .
    htmlentities($error->getShortMessage()) . "/" .
    htmlentities($error->getLongMessage()) . "<br>";
}
} else {
//#type $item ItemType
$item = $res->getItem();
echo "ShippingTerms : " . $item->getShippingTerms() . "<br>";

print_r($item);
}

versus our Ruby code:

require 'rubygems'
require 'ebay'

include Ebay
include Ebay::Types

require 'localconfig'

ebay = Ebay::Api.new

begin
  response = ebay.get_item(:item_id => '110011765264')
  puts "ShippingTerms : #{response.items.shipping_terms}"
rescue Ebay::RequestError => e
  e.errors.each do |error|
    puts error.long_message
  end
end

So, they get closer with that, but the Ruby code is still clearer and more concise. If you look around at some PHP5 based examples, they start to be decent as well. As one tutorial writes:

These components combine to create a kick-ass tool that PHP 4 can’t replicate without lots of work, if at all.

Leaving aside the fact that a lot of people are still more or less stuck on 4, I think there is something more important to be learned.

Culture

There are a lot of really smart people who work with, and on PHP. As much as anyone grumbles about any language, it’s not easy to create one, let alone create one and make it as popular as PHP. However, as I’ve said elsewhere, one of the things that made PHP so successful was its ability to “scale down”. Part of its value is that it made it much easier for more people with less advanced skills to create things. That is, without doubt, a very fine accomplishment, but it does bring some baggage with it. Namely, that there are a great deal of PHP programmers who do not write very nice looking code. Going back to the eBay example, the code featured on their site is not very tasteful, if you ask me. My bet is that in Ruby-land, that sort of code would not be displayed very prominently. Why? It’s not the computer, it’s the culture that has grown up around the different languages.

Computers do not care one bit about programming languages. They interpret bits and bytes, whatever language is used, so it’s really all the same to them. Programming languages matter only to people, because they are the tool we use to comunicate our instructions to machines. This means that they are a very human thing in some ways, and that human aspects of them matter a great deal.

What this means is that it’s important not only to design a cool language, but to create a good culture around it. To take aim at something nearer and dearer to me than PHP, one of the major failings of the Tk toolkit was that there was little to no attempt to create a good design culture around it. Anyone who was using Linux 10 years ago will surely remember some of the truly horrible things that were created with Tk. Why? Tcl and Tk made creating a GUI an order of magnitude easier than with C and Motif (or whatever windows used at the time), and turned them loose with no instructions or idea whatsoever of how to go about creating a good, intuitive user friendly one – the Tk docs themselves make little to no mention of usability, and even the best Tcl/Tk books pay almost no attention, even in the form of recommended reading, to what to make with this beautiful tool whose hows are explained very well. The unixy community also wasn’t exactly a wellspring of creativity and critique in terms of good guis, either.

So, yes, I know that it’s possible to write good, clever, readable PHP (or Perl, or FORTRAN) code, and bad Ruby (or Tcl, or Python, or whatever) code. However, I’m also convinced that culture counts. People who value clean, beautiful code gravitate to cultures, and, where possible, workplaces where they find other like-minded people. Others, not having as many options, find themselves staring at 13000-line PHP files that grow malignantly by dint of cut and paste, wondering how to tame that which others have wrought!

At work, we’re doing some coding to integrate our system with Ebay’s system, which is kind of big and complex. Here’s some PHP code to get a listed item, from eBay’s developer site:

$verb = 'GetItem';
//Regulates versioning of the XML interface for the API
$compatabilityLevel = 433;

//get an array of strings containing the required headers
$headers = buildEbayHeaders($devID, $appID, $certID, $compatabilityLevel, $siteID, $verb);

///Build the request Xml string
$requestXmlBody = '<?xml version="1.0" encoding="utf-8" ?>';
$requestXmlBody .= '<GetItemRequest xmlns="urn:ebay:apis:eBLBaseComponents">';
$requestXmlBody .= "<RequesterCredentials><eBayAuthToken>$userToken</eBayAuthToken></RequesterCredentials>";
$requestXmlBody .= "<ItemID>$id</ItemID>";
$requestXmlBody .= '</GetItemRequest>';

$responseXml = sendHttpRequest($requestXmlBody, $serverUrl, $headers);
if(stristr($responseXml, 'HTTP 404') || $responseXml == '') {
    die('<P>Error sending request');
}

//Xml string is parsed and creates a DOM Document object
$responseDoc = domxml_open_mem($responseXml);

//get any error nodes
$errors = $responseDoc->get_elements_by_tagname('Errors');

//if there are rrror nodes
if(count($errors) > 0)

… and so on and so forth (it just gets more painful)…

Compare with Cody Fauser’s Ruby eBay API

ebay = Ebay::Api.new

begin
  response = ebay.get_item(:item_id => '110011765264')
rescue Ebay::RequestError => e
  e.errors.each do |error|
    puts error.long_message
  end
end

It’s not even a contest. Best of all, most of the code that turns the XML interface into Ruby code is auto-generated. Very nice work!

OFBiz passed its vote to exit the “incubator” at the Apache Software Foundation. For those not up on the inner workings and jargon, this means that it should soon (as of the next board meeting) become a regular project at the ASF, like httpd, Tomcat, and so on

Si Chen, one of the core team, sums up the whole process here, which is an interesting read for those considering approaching the ASF.

Having helped set things in motion via an out of the blue question on their mailing list, I’m pleased to see that things are working out well, and continue to be impressed with the progress they are making, as well as the dedication with which they pursued integration with the ASF (and the bureaucracy that entailed). It would have been nice to use OFBiz where I’m working, but unfortunately that was not to be. In any case, I do glance at the code and data models from time to time, because they encapsulate a lot of good ideas.

Hecl is a weakly typed programming language, which, for a scripting language is often an advantage. Instead of cluttering your code with lots of (casts) or performing.to_s all the time, things “just work” depending on the context (and assuming that you’ve verified your data or have error handling for when things go wrong).

I’ve been pondering a weakness of this model that Tcl doesn’t adequately solve, discussed here:

http://sourceforge.net/mailarchive/message.php?msg_id=37354848

The summary is that if anything can and will be converted to a string at some point in its lifetime, GC’ing “complex objects” (things that can’t be represented by a string) gets difficult. In order to be able to go back to an object from a string, you have to maintain a hash table with string handles that point at the actual objects in whatever language you are using, and that in turn requires that you somehow keep track of the lifetime of those objects. Doing GC in Hecl itself is something I’d hoped to avoid – up until now, we have managed to get by ok with Java’s GC.

The ‘best’ solution seems to be Salvatore’s, discussed here:

http://wiki.tcl.tk/13847

But even that is relatively complex, and at least initially, involves a couple of tours through the entire string-space of the running program.

Unfortunately, I don’t think there’s really a clever way around the problem, though… what the weak typing giveth, the weak typing taketh away (or something along those lines).

I am not sure what this means for Hecl at this point, whether we simply say “clean up after your own objects”, introduce some sort of string typing, or something else entirely…

It seems that EveryDNS.net is being harassed with a DDoS attack. I’ve found them a convenient way to manage my DNS records over the years, so I went ahead and chipped in some money via their donation link.

I set up a new server for rails applications, including this “online journal”. So far, so good, although it was certainly a pain in the neck getting everything agreed to and set up with the hosting company (although they were helpful when I broke down and went ahead with the international call to get things fixed up).

We had some friends once, who had a dog that would run after anything that you threw for it to fetch. It would run up hills, down hills, through bushes, jump into water…absolutely anything to bring that stick back to you.

Sometimes, I have a sneaking suspicion that certain programming systems are sticks that you simply shouldn’t chase after, unless you want to end up like that poor dog, crashing down the hill.

I’m not an economist, but I suspect that companies, like countries or other entities that participate in trade, in some ways adhere to the principle of comparative advantage, in the sense that they do some things relatively better than others. For instance, big companies are probably better at slogging through big huge API’s in more tedious languages like Java. And that’s where the chasing the stick idea comes in. If you’re a small company, you’re going to get beat up if you chase after the stick, trying to keep up with IBM in grinding out Java WS-* code. That’s something they’re better at, because they have lots of people to throw at any problem. You had best stick to something where having a few bright people makes more of a difference.

At times, I wonder if some of these ideas are thrown out there on purpose, to try and get people chasing after them, and compete with big companies on terrain that the big companies are guaranteed to win on.

In something very reminiscent of this:

http://thedailywtf.com/forums/thread/102936.aspx

I just got some instructions today on how to interact with with a web service, complete with WSDL, SOAP, and some other acronyms. The goal of all this? To send a comma,separated,value file to the recipient.

Ooooo-kkkk.