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, 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, 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, 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 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.

<  |  >