On Fri, Sep 20, 2013 at 06:41:52PM +0200, Krzysztof Kosiński wrote:
2013/9/20 Bryce Harrington <bryce@...961...>:
When Inkscape started there were several bug-bounty projects in operation which we watched drift into non-success. I suspect that's why many of us have been a bit skeptical about the feasibility of bug bounties generally. But it's definitely gotten a lot of discussion. By now there must be some good "best practices" identified, so maybe it's just a matter of having someone come up with a plan.
The way I see it, Inkscape is just very complex and fixing bugs correctly requires a rather deep knowledge of its idiosyncratic architecture, which is moreover poorly documented. The limiting factor is not money, but insufficient manpower / lack of knowledge.
I think I can safely say it's not just you - many other devs I've spoken with have expressed similar sentiments. It really feels like direct money-for-bugfixes is a square-peg-round-hole type of problem.
So indirect solutions might be more the way to go. These require a bit more thought to plan out, but are probably going to be more straightforward to implement.
For instance, you mentioned lack of knowledge as an issue. Addressing that using funding could be done with subsidized training for existing developers, tutorials to bring new devs up to speed, contracting a technical writer, or the like.
I particularly like indirect concepts that focus more on education because of the "teach a man to fish" angle - you're investing in the _people_ rather than in the _codebase_. The trained people will be better able to fix bugs, better able to *avoid* bugs, and better able to spot bugs in other people's patches. And any training materials could be made available online for future devs.
I'm not sure how that would be put together though. Doesn't seem like it'd make a sexy kickstarter to say, "We'll send X devs to bug school." Perhaps somehow we could tie bug fixes into the application process (e.g. "you must fix 10 bugs to qualify for attendance"), and then let the donors have a say in what bugs are "on the list" for attendees to select from. Then however much money is raised, start with the person that fixed the most bugs on that list as attendee #1, then the next most prolific as attendee #2, etc. Or something like that; ideally not too complicated, but I think the fundraiser would be more successful the more donors felt confident the money was going to result in fewer bugs in the codebase. Then, whatever bugs remain from that list (which presumably are the harder bugs to solve), could become topics for discussion *at* the class.
For instance, some time ago one guy offered a bounty of $100 for fixing a bug related to selecting clipped objects. I only managed to fix it because I refactored the entire rendering code and in the process understood how it could be fixed.
You know, this is a really interesting anecdote. The key take-away here is that it worked! A user was able to effectively prioritize a bug in a way that gave you a stimulating challenge or whatever, and it resulted in the issue being fixed. Yeah it woefully underpaid you for your time, but I think that's not the important bit.
Correct me, but I'll assume your motivation wasn't merely/purely to earn the cash. Did the $100 serve more of a symbolic purpose to you? Like, just as a marker of that user's desire for the fix? Like, that you knew the effort would be more appreciated than usual. Or did you feel a sense of principle that users should be able to pay for bugs, and did it to help further that ideal? Or some other reason?
If we can understand whatever that was, and replicate it at a larger scale, then *that* might be a more successful way to use Inkscape's funds to stimulate bug work.
When it comes to development funding, I have the following to share: One of the professors at my university is interested in funding the development of an open-source cross-platform chemical drawing package which could produce publication quality drawings and understand ChemDraw format files supplied by publishers. At present, there are no open source programs which can do this - their output is typically poor quality. He suggested that implementing this program as an extension for Inkscape might be the way to go, because implementing the chemical drawing functionality is comparably minor work when compared to implementing all the generic drawing functionality already present in Inkscape.
This indicates that we could probably gain significant funding from niche users who would use Inkscape as a platform upon which to build a specialty editor. The CAD / electronics work by Sebastian also shows that we could gain a lot by expanding the scope of our extension APIs.
Nice. I agree there's a lot of potential in Inkscape that could be tapped if it catered better to use cases beyond just art. What do you think would need to change in the extension API design to make these types of uses more feasible?
Bryce