Of course I’m talking about Autodesk’s newly reinvented nomenclature for bug fixes. Once upon a time they were known as bug fixes, then service packs, and now “updates”. Is the Autodesk marketing department running amok? The subtle spin is certainly a sign of the times, but I wonder if the change in terminology comes about for another reason as well.
Autodesk promises “features extensions” to subscription customers. They have had difficulty delivering such extensions on a consistent basis. One of the reasons, I suspect, is that developers of extensions encounter the same brick walls that third party developers battle all the time: AutoCAD bugs, of course; but also incomplete APIs and feature limitations. It’s possible that updates not only fix bugs, but also fill gaps so that extension developers can get their extensions working.
Then again, the change in terminology might be part of a new fad. My wife, who is an engineer working in the automotive industry, informs me that they no longer issue drawing revisions in her company. Instead, they now issue “updates”. I wonder how long it will be before auto mechanics stop repairing cars and start updating them instead.
Category: Philosophy
The meaning of life (and other deep topics).
Hotel Autodesk
Steve Johnson asks “where have all the developers gone?“, and Deelip Menezes wonders in a comment whether Autodesk’s annual release cycle for AutoCAD is part of the problem. I’ve always said that an annual release cycle is untenable. The annual release cycle is motivated by Autodesk’s desire to make the subscription program look attractive. Has it worked?
Based on what I’ve read and heard through the grapevine, it has definitely worked. More customers than ever are choosing the subscription model. In many cases, the annual subscription business model actually works well for software like AutoCAD, providing benefits for both Autodesk and their customers. But subscription is not for everyone.
In typical greedy big corporate fashion, Autodesk have overplayed their hand. Instead of concentrating on those customers for whom subscription makes sense and leaving the others to choose a different model, the “more is always better” marketing machine kicked in. Ergo, the annual release cycle carrot and the AutoCAD retirement program stick were invented. [Oh sorry, it’s called the Autodesk Loyalty Program.]
I am already seeing the beginnings of a movement of discontent among Autodesk customers, and I expect the annual release cycle to collapse under its own weight within another year or two. In the meantime, tremendous damage is being done. Customers, third party developers, authors, and consultants all suffer under the strain of the annual release cycle, but that’s only the tip of the iceberg.
To pull off annual releases, Autodesk have to be working on multiple versions of AutoCAD in parallel. While AutoCAD 2006 was being beta tested, AutoCAD 2007 and 2008 were already under development, and AutoCAD 2009 was already in the planning stages. When CUI was first introduced to the public, the new ribbon UI was likely already in the planning stages. Is it any wonder that the angry feedback about CUI was ignored?
When you have an annual release cycle with 3 or 4 future releases on parallel tracks, you can’t just stop and fix a fundamental design flaw. All you can do is increase your public relations budget. The harm done to third party developers is substantial, but the inability to shift gears and correct fundamental design flaws is the real travesty of the annual release cycle.
The Day the ObjectARX SDK Died
Like that day almost 50 years ago, could today be the day that ObjectARX has died?
There have been a flurry of posts in the ObjectARX discussion group about problems downloading the new ObjectARX 2009 SDK. At first I dismissed the problems as new release hiccups, and expected things to get resolved in short order. Seeing that there were no new complaints this morning, I headed over to http://www.objectarx.com/ to download the new ObjectARX 2009 SDK. Instead of the new ObjectARX 2009 SDK, I received the following:
Maybe it’s a technical problem with the web site, and the download just didn’t start, I thought. I checked my email, and found this from Autodesk:
Thank you for your interest in development tools for Autodesk’s products. If you are not already an Autodesk developer partner, be sure to visit the Autodesk Developer Network website at http://www.autodesk.com/joinadn to learn more. As a member, you can access timely technical information, training and support to help you stay competitive.
If you are looking for self-help resources for your Autodesk software-based development efforts, visit our Support page at http://www.autodesk.com/support or access the ObjectARX newsgroup at news://discussion.autodesk.com/autodesk.autocad.objectarx.
Regards,
The Application Development Team
Putting two and two together, it looks to me like the ObjectARX SDK is no longer freely available. It’s not altogether surprising that Autodesk would try something like this in an (almost certainly misguided) attempt to make it more difficult for organizations like the Open Design Alliance to reverse engineer the API.
If this is true, I foresee a major sea change with a ripple effect that will change the face of third party add-on development. It’s a risky legal maneuver, first of all. Any time a large corporation like Autodesk picks and chooses who it will do business with, it risks running afoul of the Sherman Antitrust Act. Secondly, the practical effect of limiting access to Autodesk’s SDK will be to give Open Design Alliance more influence vis à vis its DRX SDK.
For now, there is not too much of an immediate impact. AutoCAD 2009 is binary compatible with AutoCAD 2007 and AutoCAD 2008, so software developed with those SDKs will work in AutoCAD 2009 (of course without utilizing the new features). Therefore, development of AutoCAD 2009 software can continue with only a minor hit. The problem will not be felt until the next release of AutoCAD, which presumably will no longer be binary compatible.
Where is all this headed? I’m still holding out hope that it’s all a big misunderstanding; otherwise we’re headed for some upheaval in the AutoCAD add-on industry.
[Update: as of early Friday morning the ObjectARX 2009 SDK download is now working!]
Creative Marketing
This Autodsys press release made me chuckle. Their IntelliCAD based AcceliCAD now supports custom entities, announces the press release. “Instead of creating custom objects as is necessary in some other CAD packages the application developer can instead use the primitives already built into the program such as LINEs, ARCs, CIRCLEs, and POLYLINEs.” Hmmm, that sounds an awful lot like blocks in AutoCAD — a feature AcceliCAD has surely supported since its inception.
The press release continues, “That means there is no need to define grip points or editing operations for the entities because those functions are already built into AcceliCAD.”
ObjectARX programmers have been able to create custom objects in AutoCAD for years. One of the most common reasons for creating a custom object is to “define grip points or editing operations”. Otherwise, blocks work just fine in most cases.
Maps Are Evil
One of the defining characteristics that distinguish humans from computers is our ability to act irrationally. Our biological computer system is capable of interjecting an otherwise logical thought process with random perturbations that often result in completely unpredictable outcomes. Looked at in the abstract, this is the essence of how we escape the shackles of destiny and turn an otherwise mundane march of time into a serendipity of human experience.
In practical terms, it’s our ability to make mistakes that gives us supremacy over mere electronic circuits. If we were simply pre-programmed machines, we would be no better, and perhaps no different, than a computer. By making mistakes, we learn. By taking risks, we discover. By challenging and disregarding what is already known, we learn what is not.
And that, my friends, is why maps are evil.