Over the last couple of days I have been searching for some components I want to use in a project to illustrate my writing. There are, of course, many great components out there in open source, and often the struggle is simply to choose one.
In this case, however, there seemed to be many choices, but the selection was quickly reduced by practical realities. My basic concerns are these:
- Functionally fit for my purpose.
- Supports a broad range of Delphi versions.
- Is in current development or maintenance.
There are times when fitness is hard to judge. In this case, I was considering the use of an ORM, and though there have been many created, there is a good deal of variance in their design. Secondarily, they may depend on other open source components, so those must also be investigated.
As to Delphi versions, the obvious question is how far back must we really look? Not easily answered, as I do some work each day in Delphi 2007 on production code. However, I am content for my present purpose to find components which support Delphi XE and later, or perhaps Delphi XE 2 and later. That leaves most published code open to consideration.
Surprisingly, as I explored, it became apparent that many of these components are not available at all. Websites are dead, or still present, but with no downloads available. In other cases, there have been no updates in several years, so support is lacking for recent versions.
So now the issue of longevity.
If your need is to illustrate a blog article, this is perhaps the least demanding, and you can choose almost any component.
If your goal is to illustrate the presentation of concepts in a book—hopefully one which will be around for years—then the life of what you select becomes more important.
If you will make use of the component in a product which is sold commercially, then you need to consider with care the future of the component. Ultimately, if the developer(s) behind it tire of the project, then to keep it alive, you may need to become the support for it. That doesn’t mean you have to keep it alive in open source, but it may mean serious maintenance to ensure that as it ages, it doesn’t cause your product value to suffer.
Open source is a boon—but sometimes not. I am not arguing against its use, but merely urging caution in the choices you make.
Single Developer Components are always a risk, but that is true for closed and open source components. With open source however, you can take a deep look in the source and reference it. You can estimate the code health. That’s something you can’t (easily) do for closed source components where you only have the dcu or have to spend additional money to also get a source drop (which you then most possibly can’t use in examples).
Open Source also has the advantage that if the original developer doesn’t want to work on the project, someone else can take over. That is not possible in the most cases of closed software.
So it depends more one the people behind the component. If it’s a team or group or a big corporation, the chances are good that the component stays alive. If it’s just one person it depends on the will of one individual.
Single developer is a special case, but even with a group, the risk remains. How many members of the group are very active? How many are fully involved in the design, and capable of sustaining it if the founding member loses interest? Certainly we can explore the source and evaluate health, value, and possible risk. And as you say, someone can step in and take over a project which might otherwise die.
In assessing the risk, one must also seriously consider whether he would be willing to take responsibility for the component, in the event it is abandoned. And that is not only willingness, but will and available time. These days, there is complexity in component sets—is the continued development within range of your skills? We all have certain areas in which we tend to focus, and to be master of all realms is unlikely.
But you CAN take over the component or at least modify it for your uses after the owner has lost interest. You can’t do that with closed source. And you can’t look into a company. Even if it’s a multi-million company you don’t know how many people are on the team(s) working on that component you’re using. Maybe it’s just a one or two man team and the moment one of them leaves the company they lose interest because the maintaining burden is to high.
All valid points. However, I would never consider a closed source component. I made the mistake once, and will not repeat that error.
As to companies, while you cannot know their internal details, they remain, on average, a more secure solution than components which are supported by only one person. One very prolific person left the Delphi scene some years ago, and though his components remain widely used, and continue to be supported in open source, his departure was likely a factor in the many branches which have been forked. And none of them that I have seen has made any effort to document the changes well, nor in some cases, even to document the reason behind the fork.
The golden rule when it comes to Delphi libraries and components is this: Whatever you use, make sure you get the source code. It never pays to be cheap and buy dcu/bpl versions only.
Absolutely, Thomas! When I first worked in Delphi, at its initial release, it was obvious to me that components without source were high risk. And yet, when using Delphi 2, I broke my rule, and used a component for which the source was not available. It was early days, and there were not always multiple choices for any given function, so I made my choice. It turned out that I was sorry, of course. That one component held me back from Delphi 3, and it was not until Delphi 5 that I found an alternative and was able to escape the trap into which I had willingly entered.
A dozen years ago, I was in a similar situation, but with a component someone else had chosen. There seemed to be alternatives, but this was an encryption component, and others which implemented the same forms produced different results. We had no source, and had a customer base which relied on that encryption, so could not suddenly switch. The solution at that time was to encapsulate the component in a DLL, and move on. Not ideal, but a workable solution which bought time for plans to be made for an eventual transition to a different encryption tool.