The intention is that this API will be accessible from any ABL session (whether character, GUI, GUI for .NET, AppServer or WebSpeed). Obviously, this means that you will need to be able to program against the API and that's where this survey comes in. 

The survey ran between May 7th, 2010 and May 14th, 2010. I received a total of 83 responses. Although I do not consider the survey extremely scientific, it gives a good indication.

The first question asked which version of OpenEdge respondents would be satisfied working with. 68% of respondents said 10.2B. The others said 10.1A, B,C, or 10.2A.

The second question asked what impact it would have if OpenEdge 10.2BSP1 was required as a minimum version, bearing in mind that this would be primarily for an AppServer. 53% said they are already using it, 26% said they would upgrade the AppServer, and the remainder said they could not move as they are tied to their existing platform.

Based on these responses, 85% of the respondents would be OK with using 10.2BSP1 for the ABL client that calls the API. Frankly, that surprised me. I had expected that number to be closer to 60%.

The next question asked about database version and only 2 respondents of the 83 are still tied to V9. That means that more than 97% of respondents can work with the 10.0 restriction on the database. Unfortunately, only afterwards did I realize that Int64 only came in in 10.1. So I am a little skewed on this one, but given the response to the client version question, I think there is probably a close correlation between those who are using 10.1A or later on the client and those who are using the same version on the server.

When it comes to the functionality, everyone (and I mean all 83 respondents) want the E-mail API. 76% are interested in the Calendar API. I was a little surprised that only 30 of the 83 respondents (36%) care about the .NET control.

I was also surprised at how many were interested in the Contacts API – 55%. After I wrote up the survey, I realized that I had left something important out of this. The Contacts API does not refer to contacts in the Active Directory. It refers to Contacts in the user's Contacts folder or shared contacts folders. So I am not sure how that number would change if that was a known factor.

The question on the API style was another interesting one. 72% of respondents said that they would prefer an OO style API. I was surprised that the OO was such a high number. I expected closer to 60%.

What really surprised me was the response to the next question which asked about the OO style API and how people would feel working with it. No one said they were against it. Only 3 respondents feel it would be tough and are having a hard time with persistent procedures. 19% said that if it wasn't OO they wouldn't use it, and 77% told me that they are willing to try as long as it is well-documented.

The error handling question was also surprising, because 60% of people pretty much don't care or don't know anything about the new error handling. The rest want me to use the new error handling.

Finally, I got more interest about the open source question than I thought I would. 15% of people said they were willing to help me with the code. 15% said they would not change the code themselves so they did not expect to contribute and 70% said that they would contribute if they modify the core code. Someone pointed out that I needed a question somewhere between "I'll give you the code if I change it" and "Sign me up!" They suggested that I might want something that didn't require pulling an all-nighter! 

I got some terrific individual responses that indicated that this is something that OpenEdge developers are really interested in. Some of the quotable individual responses went like this:

A easy to use, maintain, modify API into Exchange is moving up our TO-DO list quickly!

I think this is a great idea, and very ambitious. Please keep us posted!

I'm very excited about this. You seem to be putting a lot of time into it.

Needless to say, I'm excited, too, and I will definitely keep you all posted.

Tools that I couldn’t live without include Beyond Compare, Enterprise Architect, WinZip, Nero and various others. One of my upcoming posts will list the tools that I make use of to do my job.  With each of these, I have bought the license because it is worth it. The tools more than pay for themselves in the functionality that they provide.

Recently, though, I have been looking into some significant new projects that need some pretty sophisticated software – enterprise-class AppServers and Databases and powerful, rich clients. Obviously, my investigation has included the usual (and some unusual) suspects.

Before I go any further there are two things that I need to make clear:

1. I am not endorsing any particular technology. Your mileage may vary and I strongly encourage you to do your own investigation; and
2. I am not new to the open source initiatives that I am discussing below. I have used open source code on many occasions for many tasks. What I am talking about here is the use of open source products in a commercial context at an enterprise level.

Many of the software guerillas that are out there are actually mercenaries (as Christopher Duncan calls himself). They are contractors hired to do a job. These mercenaries need their weapons of war – tools that they use to build software. With corporations increasingly pressuring IT to reduce its costs, engineers are being forced to look at cheaper development alternatives. They need to keep their costs down too.

In looking at these new projects, cost is a serious concern. I need to be able to develop these applications with very low initial and annual maintenance costs. This needs to be balanced with the need to provide the enterprise with a stable, high-performance, enterprise-class solution. The cost of the software that I use to build the applications is thus a serious concern.

Historically, I have shyed away from software that is “free” because, as the cliche goes, you get what you pay for. If software is given away, where does the money come from to keep supporting it? This includes using open source software to build and run commercial, enterprise-class applications. I could not bring myself to believe that it was possible that non-commercial software was sufficiently stable with sufficient support to make this a viable alternative.

About 5 years ago I started changing my attitude about this when I was involved in building a commercial development environment using Eclipse. At first I was extremely negative about Eclipse because I did not believe it had a long-term life. I guess my experience was tainted by the bad experience I had had with an open source project that had limited success several years earlier.

The Eclipse project I was involved in taught me a lot about the value of the ruthless meritocracy that governs the development of open source code. This same meritocracy can be seen in any of the successful open source projects, including most of the Apache Software Foundation projects. And here’s the most interesting point about this:

Developers produce better quality code in an open-source project than they do when they get paid for it!

That sounds counter-intuitive, but my experience with it seems to indicate that this is a truism. One of the reasons for this is that most software guerillas remain idealists at heart. Any time we get to build what we want to build, we do the best we can and when we are challenged by doing so in the fish-bowl of an open-source project, we are inclined to be even more careful about the code we write.

The effect of this is that much of the code that is produced for an open source project is actually better code than what is available from a commercial application. It is better written, better tested and therefore more stable than something that was produced under a manufactured deadline.

I started out this post saying that I am looking at some technology solutions for some complex applications. My usual suspects are always:

• Microsoft’s .NET, its development tools and its associated backend products, including ASP.NET and SQL Server;
• Progress OpenEdge, its development tools and its associated back-end products including WebSpeed, AppServer and the Progress Database; and
• Java, its development tools and its associated backend products including JSP, Java EE (Glassfish, et al), etc.

The great equalizer in the set above is the cost. Microsoft’s development platform for the cheapest useful development platform (MSDN Professional) is going to set you back $2500. From there, deployment costs for the components are dependent on what you are doing size-wise, but just your software costs are going to put a dent in the better part of $20K for the deployment I am looking at.

Progress OpenEdge is not much better, but its harder to spell out the costs in the configuration I am looking at. I will therefore refrain from attaching a pricetag to the OpenEdge deployment.

The Java configuration is another story. There is an array of free development environments to choose from – I use both NetBeans and Eclipse. Java EE is free to deploy so that means that there are no deployment costs to the production environment unless you choose to spend the money on enterprise-level support.

The operative word in that last sentence is “choose”. With the other product suites, the penalty of not choosing support is significant. You end up paying it later with penalties if you want upgrades. With Java EE, the upgrades are available free. It is only when you need the enterprise support that you pay for it.

I haven’t said anything about the databases at this point. MySQL has become a very viable alternative to commercial products like Oracle, Microsoft SQL Server and Progress OpenEdge. In fact, in some of those cases, MySQL is a better technical solution anyway. Again, MySQL has support options where you choose to use them in a production environment, and again, you have the choice.

IT costs have represented a significant portion of the costs of doing business for the last 50 years. Now, in an economy that is in the worst situation the IT industry has ever seen, IT has got to be willing to step up and realize that the cost of doing business has to drop. Small to medium size businesses are going to be forced to review their development expenses and more and more companies are going to ditch software that costs a fortune to maintain. Developers, particularly consultants, are going to ditch commercial products that come with these costs in favor of cheaper products.

This is not a new prediction – people have been saying it for years. But here’s the real game-changer. The economy is forcing people to review their costs and open source code has got to the point where technically it is equivalent to or better than the corresponding commercial software.

At the end of the day, what business cares about is the cost of it!