Niches are not comfortable places to live in the software world. There are two over-riding dangers to long-term survivability of any niche tool:
- the tool is not useful, and is ignored (and the company dies)
- the tool is incredibly useful, and the hosting OS vendor incorporates the features (or a useful subset of your features) into the base OS for a future release, depriving the company of revenue (and so the company dies).
If you are lucky, the vendor of the hosting OS tries to buy you or your tool technology before just blowing you out of the water.
Niche tools have a definite limited product lifespan, and it is unreasonable for any company to assume otherwise.
Re: Missing concepts and tools
> At least two important concepts are
> missing with regards to build
> Completeness; That the correct
> versions of all components are built
> into a release and Consistence; that the
> whole system is build with all
> components. That the author forget to
> mention the make tool but instead focus
> on Perl is strange. Make provides a
> dependency graph of components which is
> important for consistent builds and make
> also provide a much better tool for
> completeness and automatic build than
> I also find it strange that the
> authorís descriptions of release
> management donít mention Version control
> and Change control. For version control,
> CVS is probably the common single most
> used tool in the OSS community and
> should have been mentioned. And Bugzilla
> is a good example for change control.
You are both right.
Building software does not being or end a the
Makefile. You usually have to fetch source code,
confirm the environment, do the build, then process
the output and confirm the integrity of the result.
Make does only a fraction of this, and it isn't
especially good for situations where you have
mulitple architectures operating in parallel. This is
where tools like autoconf and imake can come in
But the point is that perl is a convenient, flexible,
portable, and powerful tool to do all the associated
fiddling around that is necessary in any non-trivial
In my own discussions, I tend to break everything
out: Source Code Control is different from Change
Control, which is different from Build Management,
which again is different from Release Management.
And don't forget Environmental Control and Tools
Management. All wrapped up together we can refer
to the whole mess as Configuration Management.
Since the author was talking about Build and
Release Management, I don't think he was out of
line to promote perl as a important tool.
To further split hairs, the most important goal of build
management is neither completeness or consistancy
(not that these are unimportant) -- the number one
goal of build management is repeatability. In other
words, you have the ability to duplicate any
arbitrary build from any arbitrary date in the past --
so that bugs can be duplicated and then later be
confirmed to be fixed.