Sometimes the question isn't, "buy versus build" but buy versus borrow.
One of the questions surrounding Delphi components is whether third-party vendors can survive in the competitive components market, especially when so many components are available as cheap shareware or even freeware. The question was the topic of a birds-of-a-feather session at the last Borland conference in Philadelphia. I was invited to join the panel discussing the issue and the ensuing discussion offered a wide range of viewpoints.
Delphi's Visual Component Library is the foundation on which all Delphi applications are built. Some programmers use only the Borland and third-party components (QuickReport, TeeChart, and FastNet) provided in the Delphi box. Others make frequent visits to Web sites like the Delphi Super page or Torry's Site to download the most recent components and to keep track of what's new and interesting. Some programmers prefer not to rely on the freeware and shareware components, but instead buy packaged components from various vendors, often choosing the native Delphi components over the generic OCX ones. Still others take advantage of Delphi's ActiveX support and use some of the variety of ActiveX controls available in the Visual Basic add-on market.
But whatever form the component takes, and whether for sale or for free, third-party VCL components have played a significant role in the success of the Delphi programming language.
If you're not part of the Delphi community, you might wonder how Delphi's components differ from others. The Delphi components market has a few distinctive features.
Delphi components are easy to write, so there are many available. A lot of components are given away for free to the community from the same people who earlier used free components produced by others -- a way of "paying forward". What are programmers looking for in Delphi components? They invariably want them to include the source code, as it helps them use the components with the next version of Delphi before an official upgrade to the component is available. They expect the components to be well integrated into the Delphi IDE. They want something that resembles, as closely as possible, the approach of the native components provided by Borland.
Delphi components, like others, have been distributed in many ways. There are the commercial components (often packaged with a manual), which are typically high quality and provide tech support, free bug fixes, online documentation, and so forth. There are probably a few dozen vendors of commercial components, most of them small companies -- with some notable exceptions.
The second level of distribution is covered by a variety of shareware licenses, from 30-day trial versions, to the IDE-only approach (the component works only while debugging, but not in a stand-alone application), to the source code including the component itself. There are also totally free components, including open source projects.
Such a variety of distribution methods is great for the Delphi community, but sometimes leads to disagreements among proponents of the various models, many of whom make their living in the components business. These fights have been exacerbated by accusations of stealing source code and ideas.
Everyone agrees that stealing source code is illegal. But unless you're copying source code, it can be difficult to define what is illegal and what's not. More difficult still is determining what's ethical? What if you copy the exact user interface of a Delphi add-on, rewriting the entire source code from scratch? What if you take snippets of code published in a book and use them as a starting point of your development? What if you look at the capabilities of an existing component, its properties and methods, and write a perfect clone with your own code?
Let's forget about the law for a second. Writing a component is not only writing its source code, but also designing its API: its interface to the program (properly-designed properties account for half of the design of a component and most of its success); defining the behavior of its user interface; and preparing intuitive property and components editors. Sure, no one has exclusive rights to a user interface idea, or to the name of a property. But if all you do is copy what others have done, your contribution to the community is, at the very least, questionable.
Also contributing to the components debate is the fact that Delphi programmers live in many different economic environments; the way they choose to distribute their components depends on their economic needs. The Delphi community is as large as the world and encompasses citizens of all ages and economic situations. US$100 doesn't hold the same value for an American professional programmer as for an Indian teenager. Wages in some countries are so low that individuals have built impressive class libraries, spending hundreds of hours of work, just to give away their libraries to showcase their skills. Others have created impressive programs and sell them for a tenth of the price of a professional tool, sometimes even providing better and more responsive technical support. Time and money don't have the same meaning for equally knowledgeable people of the global Delphi community. Have you ever wondered why some of the most popular component collection Web sites are created in eastern Europe?
The Delphi community needs to remember that vendors and writers of free components all play roles in the community. If we want Delphi to penetrate the corporate world -- where using a free but unsupported component is not a common practice -- we need professional, commercial tools. Borland would benefit from this as well, and should probably do more to promote third-party vendors than it has done in the past.
Third-party vendors are judged by the quality of work they produce. Many have provided innovative ideas that have helped Borland to push Delphi in new directions, and they should be rewarded for their efforts. My advice is to let vendors know you appreciate their work by buying the original tool instead of the cheap imitation. Make sure, though, that you ask vendors for the quality documentation and support they've promised you.
Vendors should do their part by avoiding common practices like charging to make their components compatible with each new version of Delphi. I know that this fee often includes the addition of new features, but I think an upgrade for compatibility only should always be available for free to current owners.
Although I support the efforts of third-party vendors, I also believe that the Delphi community needs freeware and open source projects, which are flourishing. Some of those components are innovative, very high quality, and provide frequent fixes and updates.
What it comes down to is this: I don't think that building a cheap clone of an existing third-party component does a great service to the community, even though some programmers can't afford those existing components. But open source projects can foster innovation, as the Jedi project has clearly done. These projects can push Delphi to new heights, providing a service to Borland and to the community. Borland has recently acknowledged this fact with the Delphi 5 companion CD, but should take care not to support open source at the expense of the vendors.
Finally, I'd like to mention an interesting development
that might help close the rift between the two factions of the
component builder community. Nevrona Designs has announced the "red-hatting" of the open
source project Winshoes. I agree with Winshoes project
coordinator Chad Hower that this can be a win-win
situation. People who want the free components will be able to
download them, as in the past. People who want documentation
and premium support will pay for it and, therefore, subsidize
the project. The relationship is the same as that between Red
Hat and Linux, and makes perfect sense. Look for more moves in
this direction in the future.