Cairofication of Inkscape took a big step forward today, with Bulia's announcement that several canvas items (bpaths, ctrllines, and ctrlquadrs) now being drawn using Cairo. Regular objects are still rendered as before, so there's still further work to be done.
There were some great comments to my previous blog entry, Pay bounties in time, not money, including this one:
I would love to pay in time and not in money. But I don't have any programming skills whatsoever. I'm an office manager by trade. I'm skilled in interactions between people and (basically) herding cats... and I'm good at it, if I can say so myself :)
How can I use this experience to help Inkscape or Ubuntu? I don't really know if I can.
For Inkscape, I've already written up an answer in depth in Inkscape's FAQ entry: Are there non-coding ways to help? There has been a huge number of non-coder Inkscapers who have gotten involved with the project in these ways and helped to make it a roaring success. So for that half of the question let me just point there, and focus on the Ubuntu side of things.
A lot of people don't realize they CAN contribute. A widespread assumption is that software is technically hard and that you need advanced coding skills to do anything to contribute. It simply isn't true. And in fact if people think that way, it holds FOSS back from its true potential. Have a look-see at the above Inkscape link to see the big breadth of non-coding things that an average piece of software needs done to make it succeed: Tutorials, clipart, teaching other users, mocking up dialog changes, translating, testing, marketing, and (especially!) helping with the bug queue. Working on any of these (especially bugs!) can have the add-on effect of freeing up those who DO have coding skills to focus them on coding instead of all the other non-technical tasks that need to be done in order to make the software successful.
Let me focus specifically on management ("cat herding") since that was the question, and try to slant it towards Ubuntu.
I suspect one of the things developers enjoy about working on open source is that they don't have a boss! I'd bet that hardly any FOSS project would say they "need a manager". However, there is more to "management" than "being a boss", and indeed I think these aspects are among the highest areas of need with most open source projects.
For these reasons, let's also distinguish between "project owner" management where you are the primary lead of the project, and "contributor" management where you're a regular team member, and narrow our focus to the latter.
With Open Source management, I like to think it involves three kinds of work beyond regular development: a) Cheerleading, b) Taking out the trash, and c) Operating the switchboard.
"Cheerleading" is essentially just encouraging good behavior and motivating and inspiring people to do more work. If you've ever worked in a demoralized environment you can know how big of a productivity difference it can make when people are happy vs. not. With volunteer projects - as most FOSS projects are - morale is HUGELY important, and unfortunately there are a LOT of demoralized open source communities out there. Getting morale back is very hard, but imagine what a difference it makes for FOSS overall to take a dispirited, nearly defunct community, turn things around, and get developers excited again about pushing their software project forward.
With Ubuntu, this could involve simply cheering folks on at e.g. bug hug days, issuing thank-you's to people who fix bugs you care about, etc. or to identifying ineffective communities around particular areas of Ubuntu you think could be better, and stimulate them to be better organized and better focused towards progress.
"Taking out the trash" is the idea of handling the chores that other people don't wish to do, yet that have begun blocking up the project. This could be helping get the indefinitely-delayed release finally out the door, cleaning up an out-of-control bug tracking system, organizing a marketing effort, researching into the background of a serious blocker bug, fixing the website, or resolving some differences of opinion that have split the project. In other words, find the things that EVERYONE complains about, but no one actually does, and to devote yourself to doing THAT. Often, once you demonstrate leadership charging right into the problem, others will follow your example and assist - sometimes even taking care of the technical hard parts you are apprehensive about doing yourself!
In Ubuntu, certainly the biggest "chore" right now is the mass of bug reports in the bug tracker. Organizing testing activities is another area where contributions could make a huge difference.
"Operating the switchboard" is probably one of the most rewarding (and unrecognized) management contributions you can make in FOSS. Everyone knows that lots of issues end up just being failures of communication. So if you turn this around, you realize that many problems can be solved just by stimulating the right channels of discussion. Thus, without really needing to deeply understand a technical issue, you can solve problems just by finding the right two people, and linking them together. For example, this might be by linking a well motivated but inexperienced coder banging their head on a bug, with an experienced coder who can give advice; or it could be putting an upstream developer in touch with an engineer at a hardware manufacturing company with the data sheets about the HW you care about; or it could be getting developers of two different applications together to discuss issues like a consistent protocol format. You know when you've made the right introduction, because you see the two instantly go off into technical depths way over your head. Be sure to check back in a day or two to see how the discussions went, so you can help see that follow up actions get taken, or results communicated to third parties appropriately.
For Ubuntu, there are probably infinite areas where locating the right upstream person and hooking them to the right MOTU or core-dev person can advance a bug a LONG way.
I can't count the number of times people have offered $100 bounties for implementing some feature or other in Inkscape.
From what I've seen - and I've seen MANY features come into Inkscape from folks who aren't developers - $100 is the wrong way to do it.
Not that people are anti-money or anything like that. Certainly we've gotten rabid success out of our Google Summer of Code projects, but these pay out $4500. So maybe $100 just isn't the right price point to stir interest (even a simple feature is going to require 10-20 hrs work, at which point you might make more flipping burgers!)
In any case, aside from GSoC, I've not really seen that many successful cash-for-code projects in Inkscape.
But I *have* seen a number of similar situations that ended up *quite* successful, but didn't involve money at all.
The Mac port of Inkscape is my favorite example. Inkscape started as a Linux-only product but quickly gained a Windows port. A lot users were also very interested in seeing a Mac port, but few of the active developers were all that interested. I think maybe someone even offered a $100 bounty for it, although I'm not certain; in any case none of the existing developers took interest in doing the port.
But there was one user that was really interested in getting it, and he sat down and hacked away on it. After a few weeks he talked to me and said it was just too frustrating to get something that worked properly and he was giving up on porting it. (IIRC, he was able to get it to build but not cleanly, and when it ran it didn't work properly.)
I sympathized but encouraged him to write up his notes into the Inkscape Wiki, to explain how far he got and the problems he ran into. "Maybe someone else will know how to sort those issues out some day."
Meanwhile, people continued to clamor for a Mac port. Eventually, another person took interest in just doing it himself, and when he asked me about it, I pointed him at the wiki page the prior person had written. This was useful in getting a leg up, and he was able to sort out the build problems the first person had run into, but he eventually also gave up frustrated with the limited results he saw. I encouraged him to update the wiki page with his findings.
This cycle went on for some time, but eventually enough knowledge had accumulated that someone (JiHo I think) was able to clean it all up into a proper procedure, and to start getting successful builds that more people could use. This enabled people to focus on the next layer up - fixing the Mac-specific bugs.
Now there were also complaints that while it ran on Mac, it looked out of place and was hard to install due to its dependence on libx11. People started clamoring for a "Native Mac Inkscape Port". And so the cycle began again...
In Inkscape I've seen this pattern repeated again and again. And not just in Inkscape. This seems to be a universal mechanism for how open source works. I'm sure there's an aphorism or law or something that describes it.
In any case, the lesson that can be taken from this is that if you want to get some feature or fix into an open source project, rather than offering money, have a go at it yourself. Even if it is well beyond your technical ability or time availability, your efforts may be enough to simulate someone else to eventually have a go at it too. This could be a detailed procedure you followed that got close to working but had a fatal problem. Or a messy patch you made that *should* work but doesn't. Or it might be a list of possible solutions you've ruled out and why.
If you think, "I want a way to just throw money at the problem and make it just work," then remind yourself, "Time is money" and throw time at the problem instead of cash. Spend $100 worth of your time banging your head on the issue, trying out ideas and hacking on code if possible, and posting the results even if they turned up negative. They may give someone enough of a clue to stand on your shoulders and reach the goal.
If you asked me what the worst day in the world is to announce an open source project's release, April 1st would be it. Yet here we are, and the announcements for 0.46 are hitting the wire now.
Actually, our true release was about a month ago, but we had to delay announcements because of a series of bad problems with the Windows package. I set an ultimatum that we would be announcing on March 24th regardless - the ultimatum worked at getting fixes in for all the issues, but we still didn't have them integrated into a working .EXE. But thanks to a bunch of new and old Windows contributors, in a week all this got put together and sorted out... just in time for April Fools Day. Heh.
Anyway, make up a Windows rant and insert it here. An apropos one for today would have something to do with open source projects not supporting monopolies that subvert ISO standards processes. But pick your favorite, I'm sure I'd agree.
Meanwhile, go get your Inkscape 0.46 from our website. There's been a year's worth of awesome features and fixes added to it since our 0.45.1 release.
I'm thrilled to see mailing list support added to Launchpad! We switched Inkscape over to Launchpad for bug tracking
a while back and the community has been loving it.
Our mailing lists are currently hosted at SourceForge. Most of the time they work okay, but there's a lot of little annoyances. Archives are hard to browse and usually not up to date. Administration is a hassle, generally requiring a dozen clicks just to check someone's subscription status. And so on. So I'm really interested in test driving Launchpad's lists and see how they stack up. From what I've seen so far it looks damn sweet. The integration with teams is brilliant and gives *so* much better organization potential than what can be done with our current tools.
So, thinking further afield, what other Launchpad features would nicely solve Inkscape's infrastructure needs ?
First and foremost on the list would be file hosting. When we put out a release we get tons and tons of downloads, especially of the windows packages. Putting an Inkscape .exe on a "normal" server is basically giving it a death sentence; we are absolutely dependent on mirroring. PPAs really aren't suitable, and really are intended to solve a different, specific problem. What we need is just plain old mirror distribution. It would be nice to have access control to limit who can "officially" post packages for a given platform, so like only our OSX packagers can post OSX packages, and so on.
Somewhat along with this, we do thrice-daily automated builds of our SVN tree, and build packages for various platforms. Indeed, a lot of our hard core users eschew our official releases in favor of the dev builds. This works great for them - they risk bugs but gain access to the latest features no one else has. And for us it works great because we get swift feedback when things break. We don't keep every built version around, but it's important to keep some older versions available in case the latest version is completely trashed.
So it would be wonderful to have an automated build functionality in Launchpad that we could hook into for doing all of our builds (not just Ubuntu, but also RPMs, EXEs, and DMGs). One extra nicety would be an ability for people to tag particular builds, to flag ones that have issues, so other downloaders can avoid them.
Next on the wishlist would have to be project forums. While I am a dyed in the wool mailing list user, we have *tons* of users that constantly ask about forums.
Web hosting is another area high on the needs list. In particular, we'd like to see drupal hosting, and/or mediawiki.
Statistics are another feature we'd love to see, particularly download numbers/charts. I used to script a lot around SF to extract interesting metrics and stats, but frequent UI changes kept breaking my screen scrapers.
Periodically, someone on the inkscape list proposes the idea of a simplified inkscape interface, to make it more child friendly or whatnot.
When I was fiddling with ume and playing with the EEE PC I wondered about a simplified inkscape for subnotebook and embedded hardware, and what it'd take to achieve.
So, in a couple hours of ifdeffing out various things, this is what I came up with:
The main challenge was the aux toolbar - I think we'll need JonCruz's toolbar rework (which missed 0.46 but will definitely be in for 0.47); I just hacked it down. Deciding what to keep in the left toolbox was a tough choice, but I think I kept the most useful tools; the paint bucket would be the next on the chopping block, but I understand kids love it, so it just made it.
You'll note I turned off the scrollbars, ruler, and color palette - this was trivial to do via the menus, and could be turned back on as desired.
I tried getting rid of the grippy handles for the toolboxes, since for this use case people probably wouldn't need to be tearing off toolbars, and it'd save a touch of space both horizontally and vertically.
One thing I noticed as an issue is that some of the tool panels on the right take up a large proportion of the canvas space when at 640x480. A few of the dialogs are rather big too.
So, I think we could quite easily support an 'inklite' version of inkscape, built from the same codebase. Implementation-wise, it'd be easiest to do it as just two different executables via a #define INKLITE type thing; a lot of the menu code and stuff uses structs and static strings that can't be modified at runtime. This is analogous to what we already do for inkview.
As we near in on the Inkscape 0.46 release, I've been increasingly focusing on the few remaining "critical" bugs. A lot of these are specific to the Windows port, which is a bit frustrating for those of us whose big hope in life is to *replace* Windows, not to support it.
For Inkscape, popularity on Windows was sort of a side-effect not an objective. The entire raison d'etre of Inkscape (going back to the Sodipodi and Gill origins) was because of the lack of drawing tools on Linux. The proprietary Windows drawing app vendors refused to support Linux, so we all set off to fix that issue ourselves, and in so doing help make Linux a more viable alternative to Windows. For me personally, solving bug 1 is a big motivation to working on Inkscape.
In fact, while there had been some work on Sodipodi to do a Windows port, when we started Inkscape we dropped that, so we could focus on the Linux core. But it was not long before people who loved Inkscape and wanted it to work on Windows volunteered to undertake the porting work. We figured, hey, if it didn't impact the Inkscape core, and if these Windows contributors took care of all the porting work, what could it hurt to have more platform independence? These porters deserve a lot of credit - not only did they pull off a decent port, but the Windows version of Inkscape has proven to be extremely popular, and today our estimates are that we have vastly more Windows-based users than any other platform.
One could also argue that a Windows port could help provide a "stepping stone" for people to ease their migration from Windows to Linux. I have no clue whether this has come to be, nor know of any way to measure the significance of it if it has.
A point I often hear made is that having a good Windows port of Inkscape will "increase it's popularity." Perhaps, however popularity by itself isn't valuable - it needs to be translated into something tangible. For proprietary software, increased userbase means increased income, which allows hiring more developers to fix the bugs that the increased number of users are reporting. For free software projects, popularity doesn't bring value quite so directly - although you definitely get the increased number of bug reports!
In theory, you would expect that increasing userbase would result in increased number of contributers. This is the whole concept of Open Source - more eyeballs makes bugs shallow, a rising tide raises all boats, et al. I say 'contributor' rather than 'developer' deliberately, since value to an open source project can come in the form of a lot more than just code - documentation, translations, bug triaging, testing, marketing, tech support, and on and on.
So rather than just looking at userbase size by itself, consider the *ratio* of contributors to userbase. A platform with a high C/U ratio is going to have a lot more luck at stabilizing and optimizing its package than one with a low C/U. Commercial software can get by with low C/U's by paying developers to work on it; volunteer-only FOSS projects don't have that option though.
Thinking in terms of this ratio lets you think of larger problems in a bit different light. For instance, to determine if it's worth supporting a given platform, you could imagine comparing the C/U ratio to a Bugs/Userbase ratio. If C/U is too low in relation to the B/U ratio, the project won't be able to keep up with bug reports, so supporting the platform is going to literally be more trouble than worth.
This also lets you consider whether userbase growth due to increased popularity is going to be a good thing or a bad thing. If you have had a high C/U ratio previously, you can be relatively certain that increasing the userbase will bring with it a lot of new contributors. Often this can take the form of users simply helping each other out with answering questions on forums, helping with bugs, sharing tips and tricks, etc. This all represents value coming into the project, and is a strong sign of success.
On the other hand, with a low C/U ratio, increasing popularity may simply bring with it piles of bug reports and frustration by all involved. With few new volunteers coming in, existing ones risk becoming burned out, and the C/U ratio continues to decrease.
I also have a hypothesis that the base C/U ratio is platform-specific and derived from the level of technical knowledge and culture of that platform. In other words, by default, a Linux userbase will have a higher C/U than a Windows userbase, because the coder/non-coder ratio is higher, and because of cultural differences: Windows users are more accustomed to business models where they are simply consumers of products and their role ends at the point they submit a bug report; volunteer-involvement in a company's software product is not only a foreign concept but indeed something that can get you sued! On open source platforms like Linux, it's a completely different story - users are welcomed to be part of the collaborative process.
Another obvious question is, how do you improve your C/U ratio while allowing U to increase? A lot of ideas seem obvious - making the project more welcoming, encouraging people to get involved, providing ample training material, demonstrating how new participants can scratch their itches, encouraging them to learn coding, etc. Even though these ideas are so obvious, it's amazing that projects run into trouble fairly regularly because they've not done them - which can result in people not in the "inner circle" to not get involved; keeping C fixed while U goes up is just a recipe for disaster.
But I'm particularly curious how to deal with the situation of C/U on Windows. On the one hand, I don't particularly care to make life on Windows easier - I want people to switch to Ubuntu! But on the other, I want other people to take care of the Windows bugs; the existing Windows Inkscape supporters are obviously pretty overwhelmed, so really this means we need to get more Windows contributors. Telling Windows bug reporters the equivalent of "send a patch" gains either blank stares or outrage. Others would like to, but don't have the time or interest.
Sometimes, one way to increase contributions is to simply put the software bugs and all - in keeping with the "Release Early, Release Often" adage. This exposes the bugs to more people, at least some of which will be sufficiently bothered to put in the effort to fix it. But this is a mean thing to do deliberately to users.
Some would like to offer bounties, but honestly the amount of money required to compensate a developer for the time they spend fixing a bug is usually way beyond what a user can reasonably afford (and who wants to do the paperwork?) Personally I like the idea of bounty systems, but for whatever reason they don't seem to work in practice.
It's sort of ironic, that many of us got involved in Inkscape to further the aims of Open Source with the intent of getting people AWAY from Windows, yet since there aren't enough Windows contributors to cover all the problems particular to that platform, here we are with an expectation that we spend extra time supporting it. Do Not Want!
Felipe Sanches had an idea to add a link to our Answers site in Launchpad to Inkscape's Help menu. I encouraged him to go for it, and presto, Felipe made it so:
Users will enjoy this - it will make getting answers to usage questions much much point-and-clicky. :-)
This is a modest change, but I think it will bring big benefits. Inkscape's a fairly sophisticated program and there's a deluge of questions from users on how to use it. Not bugs, usually, but just plain old legitimate usage questions. Sometimes the questions asked are covered in documentation, but often not, especially for the advanced topics.
We already have user mailing list, forums, and tutorial sites, all of which serve the community well. However, Answers has a nice feature in that it tracks the state of the question, so a user has control over indicating when her question has been suitably answered, and keep it open until they feel they have the info they need.
As well, Answers (like the Launchpad bug tracker) awards karma for people to help provide answers. Karma doesn't buy anything but bragging rights, but that's more than we usually get for this often thankless task! While we've only been using it a short while, our current answers site has gotten a fair bit of traffic, and a nicely large proportion of the questions are answered. I've got a sense this will scale up well when we release. (Indeed, the only complaint I've heard is the thoroughly reported bug 50699)
I think this may also prove useful in cutting down on the number of invalid bug reports filed, as it will provide a more suitable outlet for people with questions that they think might be bugs, but aren't.
Additionally, I think Answers will provide a long term resource for users finding out tricks and techniques for better use of Inkscape, with a better signal/noise ratio than might be found on the mailing list or forums.
A tradition we inherited from our Sodipodi roots was to change the about screen in each release, and showcase the new or improved features in that release. Ted Gould put together a Museum of past Sodipodi/Inkscape about screens that's always fun to browse.
After a couple releases, we started to get some of our artistically skilled users involved in making the about screens. Partly this was because we've always wanted Inkscape to be a place that anyone can get involved in - even non-coders - and found About Screens to be a great way to integrate our users into development. Of course, the other part was that our users were much more effective at getting beautiful work our of our tool than the developers! (some due to lack of time, others like me due to lack of skill).
Of course, an about screen is typically a single-artist kind of thing, so this brought some problems. With multiple good artists on hand, how to select the person to do it? What if they can't complete it in time for the release? What if several people have good ideas for the about screen?
Then, someone (Josh perhaps?) came up with a brilliant idea: Hold a contest, and let all the artists compete! It worked like a charm, and we ended up with an amazing screen. We've done this time and again, with always great results. The contributors love the opportunity to help their favorite art program, and it's a great way to encourage early adopters to start experimenting with the new features - often gaining us more testing than we would otherwise!
Anyway, this release is no exception, and we've got some really excellent submissions. Some of my own favorites are shown in this post. Currently we're in voting mode - and please feel free to vote! The 14th is the last day of voting, so cast your votes soon!
As I mulled over some of our recent packaging issues with UME's X components, it struck me that in Open Source there's (at least) two drastically different approaches for handling dependencies.
It's really common when developing some bit of code to learn that a fix for some issue you've run into is already available in a newer version of the library, kernel module, xserver, or whatever that you're developing against. What do you do?
The first philosophy is to immediately upgrade to that version of the dependency, and shift your program's requirements to require it. From your point of view, this makes the most sense - you solve the problem you're having with a minimal amount of time investment on your part.
However, the trade off is that it shifts the time investment to your code's users. If they wish to use your code, they find they must upgrade to whatever versions of dependencies you're using.
