Certain proprietary vendors have long liked to criticize Linux for its lack
of a "roadmap," a multi-year plan with release dates and included
features. Without such a roadmap, they say, customers have no idea where
the technology is going, cannot plan for the future, and have no assurance
that needed features and capabilities will be built into Linux. This
Information Week article
is the latest contribution to this debate; the
way the Linux kernel is developed, says the author, "...makes it
even harder for technology professionals using Linux to plan around one
major release that's, say, 18 months down the road.
" The lack of a
roadmap is said to be a sign that the kernel development process has not
yet "grown up."
We contend, instead, that the lack of a PowerPoint-friendly release and
feature plan is a sign that the free software development process is
different - and better.
It would be interesting to ask the aforementioned "technology
professionals" how useful corporate roadmaps truly are - especially in the
software arena. Betting the company on another vendor's promised future
software releases seems risky at best. Relying on a vendor's claims for
software which is available now is dangerous enough; competent
"technology professionals" know that reality often fails to live up to
those claims. The only way to know whether a given software release will
work in a given situation is to try it, and trying it is difficult for
releases which exist only on a timeline in some roadmap.
Then again, Linux can be said to have a roadmap which can make reasonably
reliable predictions fairly far into the future. One need only look at the
projects which are being worked on now. With a bit of research, anybody
can see what features are contemplated, which of them work now, the amount
of development effort which is going into those features, whose priorities
are driving development, and more. So, for example,
one might make some reasonable predictions about future distributions by
looking at what the developers are doing today:
- They will almost certainly include enhanced security technologies,
including mandatory access control mechanisms and, perhaps, heavier
use of encrypted filesystems. SELinux looks likely to be the
technology deployed by many distributors, unless the ongoing
complexity issues end up forcing a shift to something else.
- The kernel will continue to scale to larger systems with more
processors, memory, and disks. Some additional scalability work will
be done for 32-bit systems, but the emphasis will be on using 64-bit
processors to the fullest extent. There will be improved support for
clustered filesystems, and, perhaps, for leading-edge, transactional
filesystems as well. Future hardware will be quickly supported as
long as the requisite information is made available to developers.
- The desktop experience will continue to improve, especially for
business users. The available applications will continue to develop
quickly, and future distributions will include advanced search
capabilities. More home-oriented applications, including personal
finance, high-end games, Feng Shui garden layout assistants, etc. will
be rather slower to develop.
And so on. Predictions of this sort are somewhat unreliable, but they are
nonetheless far more trustworthy than a corporate marketing department's
rendition of an otherwise obscure development process.
Roadmaps can also force a company to ship what it promised, rather than
what is best. Imagine if IBM were in charge of the Linux kernel, and that
IBM had promised that 2.6 would include its own EVMS volume management
software. Can you imagine IBM subsequently announcing that EVMS would be
passed over for inclusion because the developers like the device mapper
code better? If you make promises about future releases, you have to at
least try to live up to those promises. It is hard to switch to an idea
which turns out to be better in practice without losing credibility.
Without this ability to make decisions based on what actually works and is
maintainable, the free software development process would be weaker.
The final problem is that the free software development model is resistant
to central planning in general. Linus Torvalds can express his vision and
desire for future kernel developments, but he is unable (and unwilling) to
force anybody to work on those developments. The community makes its own
decisions about what it thinks is important. The results are often
surprising, but the success of Linux so far makes it clear that they are
meeting somebody's needs. Trying to impose a roadmap on this
process is unlikely to improve it.
to post comments)