More RTL (and I don't mean run-time library)

Although it seems as if I've been ignoring the comment thread for my post on RTL language support, I have been religiously reading everything that's been said there. I don't dispute that RTL language support is a good thing for us to do, or for any component vendor to have, I just have to consider the business rationale.

In the past six months I have been watching our sales, especially their provenance. In very hand-wavy terms, our biggest market is the US and the second biggest, the EU. Third in the list is Australasia. After that, it's a toss-up, there's no real leader in the regions that are left (although, interestingly enough, South Africa is pretty strong).

Hallvard Vassbotn's comment this morning gave me pause though. Although my analysis of where we sell is important, it doesn't give me the whole picture. What I hadn't really considered -- and with hindsight it's an obvious lack of foresight -- is that software companies, no matter where they're located (including our biggest markets), may be selling or wanting to sell into the Middle East and therefore need RTL language support.

Nevertheless, I'm in a bind. In the next couple of days, we'll be publishing our roadmap for 2007. As you'll see, it's pretty complete (and we had to push the teams to reveal some of the detail). Also, it should be fairly obvious that the further out we prognosticate the more fuzzy things get. However, there's just not much room in there for extra unplanned work, like RTL language support.

So, hypothetically, in order to do it we would either have to delay some of the things we're planning, or we'd have to employ more developers (and remember that we have two product lines at least to modify for Windows targets), or we'd have to contract the work out.

The first option, especially after we publish the roadmap, would be a no-no. If we did, I'd love to sit on the sidelines to hear some of the explosions, but of course I'd have to don the asbestos suit and wade into the flames.

The second option is a possibility, without a doubt, especially given that we are already expanding some of our teams; but then again we're only expanding them because we have some aggressive goals this year for them. We're certainly not expanding the teams in order to produce some slack to do other undefined projects.

As for contracting out the work, it's very rare that we do it. The issue is that we also need to manage the project on our side and that requires one resource, and it's a team lead type resource at that. It's those resources that are in high demand already.

So, I'm back to square one: it's worth doing, but I just can't see us doing it this year.

Free DevExpress Products - Get Your Copy Today