They promised to revolutionize development. A software pro who makes a
part-living from components explains why they’ve taken so long about it
They’re the software equivalent of the integrated circuit. Need a small
timer or signal amplifier in an electronic device you’re making? Thirty years
ago, you’d have had built them from scratch, using transistors, capacitors and
resistors. Post-1980, you’d simply buy an IC–a 555 timer or a 741 op-amp,
for instance, for a few rupees each–and plug them in.
Components. Modular development. Code reuse. The holy grail of development.
Small, pre-tested modules, the software version of the IC chip, that snap into
place in an application, to do a specific job, rather like an integrated jigsaw
puzzle.
Components are prefabricated software units that encapsulate discrete
application functionality. Most software components can be manipulated visually.
Others can be accessed using a (published) interface.
The use of prefabricated components as building blocks for software
applications began to emerge as a viable option for software developers around
the world in 1993-94. This is around the same time the world wide Web was
beginning to entice us all into a loosely-wired collective.
Before components became a part of my life, I had the choice of using APIs
(application programming interfaces), or reusing published code. There wasn’t
much of the latter, and to really reuse published code you had to thoroughly
study both code and documentation, which could take weeks. I recall doing this
while using Borland Turbo C to build my first software product ever, a DOS based
portfolio-monitoring application. The product was based on database and windows
management libraries published in two books authored by Al Stevens, an author
well known to Dr Dobb’s readers. I took months to develop the application.
|
The alternative of using APIs encapsulated into Windows DLLs was quicker, but
expensive and limiting. The latter, since a developer ended up using what was
essentially a black box. The approach was viable only where a software company
of repute published an API. In other words, access to an API did not come cheap.
The promise of components
The allure of components was powerful. Indeed it was a dream come true for
developers. Components allowed visual programming, something that was not
possible using reusable code or APIs. No more wading through arcane
documentation or coding samples before you got to use code written by someone
else. You just dropped the components into your form, set their properties, and
you were ready to go.
Just as the component paradigm was taking root, the Internet was expanding
exponentially. It became possible for component developers to offer their
products to a market that spanned the whole world. Application developers could
download components free of charge to try them out in their applications. If and
when satisfied that they had what they needed, they could buy the components as
binary objects. Later, if they encountered a need to modify or customize the
components, they could buy the source code.
Like many developers, I went on to the components bandwagon, confident that I
could make a living selling quality components to application developers, with
access to the end user markets overseas.
Components for free…
The Internet made access to the market place for component developers
relatively cheap. Not burdened with marketing budgets, they were able to offer
their components at low costs, often unrealistically low. As a result,
application development costs plummeted.
Another imponderable emerged. The Internet evoked a strange streak of freedom
and rebellion that caused experienced developers to buck the system with free
but otherwise excellent software components. As a result if you needed to
include an email client in your application, you could do so in hours using a
free and reliable component pack, something that would have been unthinkable
before the components era.
Application developers followed in the footsteps of component developers who
gave their ware for free. As a result some very powerful and useful applications
became available free of cost. These included editors, FTP tools and archiving
utilities.
While the component paradigm brought a bonanza of great freeware applications
for end users, most component developers failed to make a living building
components.
Delphi rules
Visual Development tools, most notably Borland Delphi and Microsoft Visual
Basic, ushered the popularity of software components. Delphi’s component
architecture was outstanding for its purity and simplicity. Delphi’s
Integrated Development Environment (IDE) was itself built using Delphi
components! So confident was Borland of its implementation that they chose to
offer it using a language that was hitherto confined to academic circles. They
gambled that once the component paradigm was in place, the underlying
programming language would become incidental. They were right.
On the other hand, Visual Basic’s implementation represented an
evolutionary turnaround that centered on Microsoft technologies, mostly ActiveX.
Buoyed by intrinsic support from within the Windows operating system and
propelled by Microsoft’s considerable resources, Visual Basic took a
commanding lead in popularity over its worthier rival.
A great strength often turns out to be an easily overlooked weakness. Visual
Basic’s intrinsic link with the Windows platform is now beginning to turn the
tide against it. Borland’s Delphi on the other hand, has been ported to the
Linux platform providing for the first time, a mature, cross-platform component
architecture. The lead is beginning to change.
The c-flood
Thanks to development tools such as Delphi and Visual Basic, developers
worldwide began to create components at a pace that was fast and furious.
Components flowed by the hundreds on a daily basis into shareware and components
sites. Very soon, these sites were bursting at their seams causing new ones to
sprout by the dozens.
Too much of anything is bad, and it is no different with components. With
barriers to entry into the market place practically non-existent, it wasn’t
surprising that most of the components that flooded the marketplace were poor in
quality. Owners of shareware sites that hosted these components had banked
exclusively on ad revenues, assuming the rapid expansion of the Internet economy
would continue unabated. That, however, did not happen. As a result, host sites
simply did not have the resources to monitor the quality of what was uploaded to
them.
The flooding of the marketplace made it difficult for component vendors to
earn revenues that were enough to sustain their development efforts. Component
building, which started as a part time endeavor by component builders, remained
just that! All too often, excellent components were inundated into oblivion by
the flood.
For application developers, it became increasingly difficult to find what
they are looking for on the Internet. They could waste hours, even days,
searching, downloading, testing and discarding components before finding the
right one. Without any quality assurance, the effort involved in evaluating and
testing a component could often equal the effort involved in developing the
component from scratch! To begin with, you needed to visit several sites to
locate a component that you were looking for. Later, search engines came in,
which were robots at best. Each search engine had its own dubious way of
deciding what it should list. The quality of a software component, of course,
was never the deciding factor for the robots.
The dream sours
Despite having delivered on their promise, components did not revolutionize
software development in a manner that many had anticipated. Software development
continues to be the painstaking, expensive and often risky process that it has
always been.
One of the reasons that the dreams soured somewhat, was because the pundits
failed to appreciate that the software development market did not just consist
of packaged software. Customized software development comprised a vast chunk of
the pie. Off-the-shelf components, being generic in nature, play a limited role
in the development of customized software. Worse, the packaged software market
is largely in the hands of Microsoft and a couple of vendors. In other words,
small component developers never did have much of a chance.
The dams go up
The flood produced soon produced a morass, which made it increasingly
difficult for application developers to use components. Component developers on
the other hand, began to spend increasingly greater time and resources in
promoting their products and cutting back on their development effort. Three to
four years ago, their quest for visibility forced component developers to
grapple with the idiosyncrasies of search engines. A developer began to spend a
lot of time getting a product listed on shareware sites.
Eventually, even listing your site or component on other sites stopped being
of any help. As the realities of the Internet sunk in, search engines started
demanding money to bring traffic to shareware and components sites. Today,
typically, you need to pay $0.60c or so to Google for every visitor it brings to
your site! Clearly, there is now a barrier to entry into the marketplace, as the
software development revolution unleashed by the component paradigm is tempered
by the forces of capitalism. To be a successful component vendor, you don’t
just need to be a skilled developer but also a savvy businessman with a
significant amount of seed capital.
The India connection
Like most independent component developers worldwide, I too failed to make
the transition from part time component development to a full time business.
What I managed to do, however, was keep afloat both as a component developer as
well as the developer of a Web based application that I put together using
freely available components for email, file upload, etc.
More disappointing than my own failure to make good has been the failure of
other India based developers to ride the component bandwagon. My part-time
efforts easily yield $500-1,000 a month even in this difficult market. I am
US-based today, so this amount alone is not enough for me to break free of my
day job. However, a developer in India could easily manage on such earnings,
continuously improving their product and increasing revenues!
While India based application developers maybe constrained by their distance
from the US or European end user markets, component developers in India can
easily target US application developers using the Internet.
Looking ahead
While the correction in the component paradigm maybe bad news for small
component developers, it signals a maturity of the market place that bodes well
for the future. Component developers with good products and some financial
backing have a good chance of making it in the components and development
marketplace.
Vijainder K Thakur, a former Indian Air
Force fighter pilot, is a software developer now based in Atlanta, GA.