[dot] Guest Series: Interview with Inkscape Founder Bryce Harrington

[Dot Stories]

URL: http://dot.kde.org/1099664490/

From: Frans Englich <frans.englich |a| telia | com>
Dept:  
Date: Friday05/Nov/2004, @15:21

Guest Series: Interview with Inkscape Founder Bryce Harrington
==============================================================

   In a very short time, the Inkscape [http://www.inkscape.org/] project
has developed into a flexible, solid, and user friendly vector drawing
program. What does the project owe its success to? Bryce Harrington
[http://www.bryceharrington.com/], one of the main developers behind
Inkscape, reveals in this interview his thoughts about project
management and keeping the focus on the big issues.

     Frans Englich: Bryce, feel free to introduce yourself.

     Bryce Harrington: I'm an engineer at the Open Source Development
Labs, but work on Inkscape in my freetime. I've been involved with the
project since the start, doing a mix of release wrangling, development,
and other organizational type things. I've dabbled in a lot of open
source projects, but Inkscape's my favorite.

     From even a glance at Inkscape's website [http://www.inkscape.org],
one quickly realizes that this project has sharply-defined goals with a
clear focus.  What did you have in mind when formulating this plan?

     When we formed Inkscape it was important to us to communicate where
the project intends to go, and what steps are needed to get there. There
were several reasons for this.

     First, having an established plan makes it easy to figure out where
to "fit" your work in. When working on projects where the overall vision
is not communicated, you find your patches getting rejected for
unpredictable reasons. By specifying a clear vision, it helps new
developers in figuring out how to make their contributions tie into the
project's goals.

     Second, we get a *lot* of feature requests. Quite often we hear
about some "must have" feature that isn't implemented yet, and that we
simply haven't got the time to work on. By putting those features into a
roadmap we can say, "Yes, that's a good idea, and we plan to work on it
for the XYZ release." This is received better than an ambiguous, "I
dunno, maybe I'll work on it later."

     Third, it really helps us organize our development efforts. New
contributors can identify where the major development activity is, and
track the work. Also, users can see what cool new things have been
implemented that they can play with; this is an invaluable way for the
development team to get early testing and feedback on their work.

     What role does the website play?

     The website really is just a communications tool, and while it's
the most important "outward facing" communications tool, internally it's
simply one of many tools. The bug list, roadmap, release notes, jabber,
and development mailing list are all key tools; we couldn't do without
any one of them.

     Of course, success in open source projects requires a lot more than
just good tools - it requires skill, cooperation, dedication, focus, and
most importantly a desire to be successful. If you're missing any one of
those, the best tools in the world won't help.

     Some think a common problem in open source is the "pet project
effect", that developers start new projects from scratch, instead of
reusing existing ones. Inkscape focuses strongly on following
established standards, and contributing back to and re-using existing
libraries. How do you achieve that productive mentality? Why not write a
program from scratch when perhaps it would be more fun?

     Taking the second question first:

     Yes, creating a piece of software from scratch has a very strong
lure -- one I've succumbed to more times than I could count.

     I think part of the reason is that when you start from an existing
codebase, you have to invest a lot of time coming up to speed in
learning it before you can start making meaningful changes. Often it
*seems* like it'd be faster to start anew.

     However, after doing a few projects from scratch, you learn a few
things.

     First of all, it's a heck of a lot of work to create a full fledged
software product that's worth releasing. Starting from something that
already exists means your time to first release is as short as you like;
for Inkscape our first release came 4 days after the founding of the
project, and was immediately usable.

     Second, despite what it seems like, it's actually quite hard to get
very many people to contribute to Open Source projects. It's easy to
make the assumption that if you do the first 80%, other developers will
magically appear and take care of the rest for you. In reality, you
pretty much have to be prepared to take it 100% of the way, and then,
*maybe* if you're really lucky, you'll get a smattering of
contributions. But if you start from an existing codebase, that's sort
of like getting the Mother of All Patches; plus, it's already received
some amount of testing and benefitted from critique and real-world
usage.

     Third, and probably most importantly, you realize that there's a
lot of drudgery work in completing a full fledged software product. You
probably only care about some portion of it, like the rendering
algorithms or the internal data structures, and the rest holds minimal
interest for you. Starting from an existing codebase means you can put
off having to work on those other areas and focus on the part you are
most passionate about. Heck, maybe you'll get lucky and someone will
join in that enjoys doing the part you consider drudgery and save you
the work entirely. :-)

     Back to the question regarding libraries and standards. When
developing a piece of software, it's not unusual to get frustrated with
the library or standard; there are integration hassles, bugs, or missing
features you have to spend time working around, and sometimes you just
plain disagree with how it's implemented.

     However, there are other benefits to reusing existing libraries
that should be kept in mind. Think about libraries as a way to
modularize code responsibility among multiple people; you only have a
limited amount of energy to devote to creating and maintaining code, and
you should focus it into the areas you want to be in, and let others
take care of the other parts. It is also important to consider the
larger perspective: if you use (and improve) a library, then the
benefits are gained by the whole community, making it better even for
people who don't use your program.

     Also, from a sociological perspective libraries are a great way of
organizing effort. I believe that communities have optimal sizes, and if
you get too many people involved, dissent and acrimony can make the
community unsuccessful. With published libraries, you don't even have to
know the developer in order to use them with your code. So you can build
a much more sophisticated application by integrating the work of several
communities. With standards and libraries, you also avoid a lot of
arguments in your project - if folks disagree with the approach, you can
just forward them to the appropriate standards body or development
community.

     Standards are also extremely valuable because they represent a huge
amount of arguing that you won't have to do. Because we have the SVG
standard, inside the project we don't have to waste a lot of energy and
hot air hashing out how to store the data or what syntax to use; it's
already defined for us. And it helps even more outside the project; if
we find another program isn't interoperating with Inkscape very well,
having the standard means we simply check each program's adherance, and
the one that is not in compliance has to change.

     On Inkscape's website there's a roadmap
[http://www.inkscape.org/roadmap.php], where you carefully plan what is
to be implemented in each release. Why are the benefits of having a
roadmap? Can't one simply implement features at one's convenience?

     As I mentioned above, a roadmap is a helpful communication tool
both for users and developers. We use it as a way to communicate what we
intend to do, not as a mechanism to "control" development, as one might
be tempted to think. It is extremely common for changes to get
implemented out of order due either to necessity or personal interest,
and that's fine -- the goal is to get the work done, the plan is just a
means to that end.

     It's not unusual for us to periodically review and revise the
roadmap. For example, for this upcoming 0.40 release we realized we'd
bitten off more than we could chew, and split it into two releases so
that we could get our recently implemented features out to users more
quickly. We wanted to do a release, and so we simply adjusted the
roadmap to make it fit what we intended to do.

     We also find the roadmap to be an effective way to get closure even
on drudgery tasks. Being able to get stuff "checked off the list" can be
enough motivation to do some work that would otherwise not have any
particular lure to do. It's also helped us coordinate large scale
changes to the codebase, although there's no substitute for having a
smart, gung ho developer with time on his hands to do the massive change
work. :-)

     The Hacker's Jargon Dictionary writes about featurism
[http://www.catb.org/~esr/jargon/html/C/creeping-featurism.html], when a
software project strays from its main course, beginning to neglect the
larger audience in favor of smaller features for a smaller set of users
such as developers or power users. How do you stay on track? How do you
ensure Inkscape does not wander off in a short term direction, as the
feature requests rain in?

     Given that Inkscape is only one year old, this is still a problem
we have to be attentive to. However, I think there's a number of reasons
why we've been able to stay on track so far, and that I think will help
us keep on track in the future.

     The roadmap and mission statement provide a compass we can use to
detect whether a given new idea fits to where we want to go or not. The
feature tracker gives us a place for new ideas to be proposed without
disrupting the overall development effort. We use the feature list as a
place to mine for ideas and to judge the demand for particular features;
we have a saying, "Patch first, discuss later", which means that we
expect discussions about where to go to begin after we see working code,
not with a distracting debate on the mailing list over how it "should"
be done.

     But beyond that, there's little that would actually prevent the
project from wandering. We hardly ever tell people, "No, you can't do
that", and it's rare that we would actually refuse to integrate a patch
(although we may tweak it beyond recognizability later). So I think it
is largely due to the dedication and experience of each of the
developers on the team that we stay on track. The team *wants* to stay
on track, and so they stay on track fairly naturally. It probably helps
that we know the track can be changed if and when necessary, and that we
have the freedom to choose whether or not to follow it.

     Some usability engineers say that first the interface should be
designed, and then it should be implemented, such that the interface
doesn't become a "symptom" of the coding, or a secondary aspect which
needs to adapt to the code. One of the early project goals
[http://www.inkscape.org/roadmap.php] was to establish a usability
design, and rearrange Inkscape's code to it.  What was the difficult
part of that "establishing an interface design" development phase?

     Actually, as I recall the only hard part was convincing users that
the change was a good idea. The user interface change was pretty radical
from the original Gimp-style layout, so all the users had to re-train
their fingers. Technically the change was straightforward.

     Bulia deserves the lion's share of the credit for the good
usability that Inkscape has today. I think one of the secrets to our
success was simply recognizing that he had a strong vision and good
ideas, and encouraging him to run with them. Bulia is a professional
artist and uses Inkscape in his daily work, so has a built-in motivation
to make its usability perfect. He's also an extremely active developer
and puts an amazing amount of time into changing the codebase.

     Of course, Bulia doesn't do this work in a vacuum; Inkscape
benefits from ample feedback from users, who test out each new feature
and comment on whether the given key binding makes sense to them, or if
the location of the feature's command is inconvenient. The team also
listens seriously to ideas for changing how the drawing tools work, and
adopt ideas that make it quicker or more painless to get work done. The
project provides nightly snapshots to make it easy for users to download
and test the latest version without having to compile it themselves.
This close feedback loop between the developers and the users testing
the usability means we can optimize the usability of a new feature
within a matter of days.

     What can we expect from Inkscape in the next few months?

     The major new feature coming up in the next month is Mentals'
layers work, which extends SVG's grouping feature to allow artists to
put drawing objects on different layers.

     We're also on the short path to the 0.40 release, so you can expect
a new Inkscape release in November. Right now, a lot of bugs are getting
fixed as developers prepare for this release. Particular attention is
being placed on Windows bugs this time, so maybe Windows users will gain
the same level of stability that the Linux Inkscape users have been
enjoying.

     In the months to come after this release, I suspect a lot of
attention will focus on some planned changes to the user interface,
including conversion from GTK+ to Gtkmm, overhauling several of the
dialogs including Object Properties and Gradient Fill/Stroke, and
updating the look of the icons and cursors. Of course, what actually
happens also depends on the passions of new developers that join in with
their own itches to scratch!

     This is the official start of the Dot's Guest Series, which will
house articles and interviews relevant and interesting to the KDE
community, but not necessarily about KDE. The previous article, despite
its sneaky start, was Pete Gordon on Portable Usability Laboratories.
 [http://dot.kde.org/1097763942/]