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.
Comments (32 posted)
With the release of Inkscape
we decided to take a look at the latest release and get up to speed with
the status of the project. Inkscape started as a fork of the Sodipodi
project, but has evolved into
a robust project in its own right.
Inkscape is a drawing tool that uses the Scalable Vector Graphics (SVG)
specification for its native format, and also exports to PNG, as well as
saving in Adobe Illustrator format, PostScript, Encapsulated PostScript and
PovRay formats. Inkscape will open or import graphics from Adobe
Illustrator and Dia, other programs' SVG documents and a wide array of
bitmap graphics formats. Inkscape runs on Linux, Windows and Mac OS X.
We installed the Inkscape static RPM on a SUSE 9.2 system to see what the
program is capable of, and whether Inkscape was stable and feature-complete
enough for productive use. The Inkscape download
page on SourceForge includes source packages, RPMs and Windows
To test Inkscape we started off by creating basic shapes using
Inkscape's rectangle and ellipse tools and fiddling with color fills,
stroke styles, rotation and so forth just to get a feel for Inkscape's
tools. It took about fifteen minutes for this writer to get comfortable
with the Inkscape interface.
With an application like Inkscape, using a mouse (or tablet) is almost
unavoidable. However, Inkscape's shortcut keys allow the user to perform a
lot of actions, such as selecting different tools or raising and lowering
an object from one layer to another, from the keyboard -- rather than
having to grab the mouse to switch between tools or adjust layers. For
example, to toggle the current tool from Inkscape's path tool to the select
tool, all that's necessary is to hit the space bar or F1. To move an object
up one layer, simply hit "Page Up" or "Page Down" to move it lower.
Speaking of layers, layer management is one of the major new features in
Inkscape with the 0.40 release, according to the release
Another new feature in 0.40 is a "text-on-path" feature. This allows the
user to conform text to a path -- which is useful for creating interesting
logos and other artwork that requires text to wrap text to a shape other
than a rectangle. The feature is certainly easy to use. All that's required
is to select a path and the text object that is to conform to the
path. Rectangles, ellipses and other objects must be converted to a path
before the user can wrap text to fit that object. By manipulating that
object, the user can change the flow of the text even if the text has been
removed from the object or if the object is "invisible" because there is no
fill color or stroke color associated with the object. The only thing we
couldn't figure out was how to specify a starting point on a path for the
We also enjoyed Inkscape's "Trace Bitmap" feature, which allows the user to
trace an imported bitmap. By importing a photo or other bitmap, it's
possible to create an scalable object that can then be turned into paths or
otherwise edited in Inkscape. Inkscape has incorporated the potrace utility for this. The
trace bitmap feature works best with line art, but can be used to produce
some fun effects with photos or other artwork.
Inkscape's performance and stability are excellent. We created a number of
documents using Inkscape, exported our documents and some of the Inkscape
tutorials to PNG, EPS and PS, and didn't see any glitches. The program
never crashed while we were testing, and all of the features that are
currently in Inkscape seem to work as advertised. We did notice that some
detail was lost when exporting to EPS from the tutorials, but this may not
be an Inkscape limitation.
Though Inkscape doesn't have a full user manual at this stage, it does
include several useful tutorials for basic and advanced concepts when
working with Inkscape, as well as an excellent man page. It also features
an "Elements of Design" document, which may be useful for users who lack a
background in art and design. The Inkscape interface also features context
help for most tools as well as context-sensitive tips in the bottom status
For the most part, this writer found the interface to be straightforward
and intuitive. The "Vacuum Defs" item under the File menu was a bit of a
puzzler at first, though it was finally determined that it was for removing
unused information from the
defs tags in a document. We
presume this is a good thing.
Some of Inkscape's functions can be used without even needing to start the
Inkscape GUI. For example,
inkscape file.svg -e file.png will
convert an SVG file to a PNG. This can be particularly useful for users who
wish to convert a number of SVG files into PNG format.
SVG experts can edit an SVG document directly, if they so choose, by using
Inkscape's built-in XML editor. Very few users will be likely to need this
tool, but it's there for those who need or want to edit a document's
Inkscape may not be at the same level of functionality as Adobe Illustrator
or Corel Draw, but it's certainly capable of creating some excellent
graphics -- even if this writer isn't quite up to the task of fully
exploiting its potential. With other open source applications like The Gimp and Scribus, Linux is a serious contender
for users who are looking for a desktop publishing platform.
Comments (10 posted)
Sun has submitted a new license
"Common Development and Distribution License" or CDDL) to the Open Source
Initiative's license-discuss mailing list. This license, derived from the
Mozilla Public License, may (or may not) be what Sun chooses to use for its
possible open-source Solaris release, so it is worth a look.
This license is GPL-like in its intent, but (as Sun acknowledges up front)
it is not compatible with the GPL. There are certain extra terms in the
CDDL which, while not necessarily objectionable in their own right,
conflict with the GPL's "no additional restrictions" terms. This
incompatibility came as a surprise to few people; nobody has ever expected
Sun to encourage the mixing of Solaris and Linux kernel code.
The CDDL licenses the copyrights in the code for use, distribution, and
modification - the usual free software rights. It also contains a patent
grant, but here the language is a bit more constrained:
(b) under Patent Claims infringed by the making, using or
selling of Original Software, to make, have made, use,
practice, sell, and offer for sale, and/or otherwise
dispose of the Original Software (or portions thereof).
In other words, the CDDL does not license any patents for use in derived
products. Other terms in the license suggest that Sun is concerned about
patent infringements caused by modifications, but the above exclusion is
not restricted to such infringements.
The license requires that anybody distributing the code in binary form make
the associated source available under the CDDL. The license says nothing
about how the source must be made available; in theory, one could satisfy
the license by requiring people to pick up the source in person at one's
Mongolian software distribution center. Interestingly, the license
allows the binaries themselves to be distributed under any license, so long
as (1) the source is available under the CDDL, and (2) the person
distributing binaries under a different license indemnifies the copyright
holders for any liabilities.
Unlike the GPL, the CDDL allows developers to make modifications to the
license text itself (for their own code).
The CDDL contains patent defense language: if you sue a copyright holder
for patent infringement, you can lose your rights to use the code under the
license. In any patent litigation settlement talks, the value of the
patent license granted by the CDDL must be taken into account -
essentially, the party initiating the lawsuit loses any patent license
granted by the CDDL. There is one other strange term:
6.4. In the event of termination under Sections 6.1 or 6.2 above,
all end user licenses (excluding distributors and resellers) that
have been validly granted by You or any distributor hereunder prior
to termination (excluding licenses granted to You by any
distributor) shall survive termination.
So if you are a software distributor, and you got the code from somebody
who later turns around and sues Sun, you can lose your rights to the
software under the license.
The discussion has been relatively muted; there seems to be an early
consensus that the license, possibly with some small tweaks, is, indeed, a
free software license. It will probably get the stamp of approval that Sun
seeks. What Sun will then do with this license remains to be seen,
Comments (7 posted)
Page editor: Jonathan Corbet
Next page: Security>>