Re: [Inkscape-devel] Release and Website
On Tue, Sep 10, 2013 at 01:32:41PM -0700, Josh Andler wrote:
If we want to go the donation to fix bugs route there will need to be a majority consensus from the developers (translators and other community members don't get included in this vote as they fall into different categories). The short version of this is we really wouldn't want to upset anyone or have ill-will or tensions arise because others get compensated while their efforts do not.
If the developers did want to pursue this, we could then bring this to the attention of the board. My guess is that if we really had a large portion of the developers wanting to see this happen, the board would not likely oppose it. After that we could then discuss with Bradley Kuhn from Software Freedom Conservancy how to go about implementing this. If someone wants to try and organize a vote, feel free.
I happened to meet Bradley here at LinuxCon and he raised this topic with me. He said that they analyzed all of their projects and Inkscape was at the top of the list for likely success for fundraising. It sounded like they would love to partner with us to raise moneys to help improve the project, be it feature work or stabilization.
Maybe a stupid idea, but here I go :) Have you ever considered to crowd-fund bugfixing? (i.e.: getting money to pay somebody to do the work nobody else wants to do)
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.
If money can be obtained from a crowdfunding campaign... is there any qualified person willing to do the job?
I know it's unfair to developers who already contributed for free, but as far as I know money is not the main motivation for hackers who persue the fun aspect of development (new features, challenges).
Maybe getting somebody paid to take care of the ugly stuff nobody wants to do is a fair balance and takes the stress out so regular contributors can focus on the fun stuff.
These questions have been on my mind as well. And I am of a similar opinion that if money is being paid for development, let's try targeting it to the stuff we need the most that volunteers don't want to bother with. That sounds very logical.
If you would indulge me to blather on a bit more on this topic...
I think one problem with the bug bounty programs was that they paid on a per-bug basis. But like I think someone else pointed out, often 90% of the work is just learning the codebase; then the developer could swat a dozen bugs all at once. So, we might want to organize the work as not to fix a specific bug for $, but to fix a collection of closely related bugs for $$$.
As to whom to find to do the work, there are a number of options. Hiring an existing Inkscape developer seems least-risk; they will have already climbed at least part of the learning curve and demonstrated their ability and dedication. But finding one who is available and interested could be tricky.
Alternatively, we could find a cheap external developer. I think this would increase the administrative workload, and likely wouldn't result in an ongoing developer. But for particularly unenjoyable work, maybe that's acceptable.
And there's probably half a dozen other ideas. We've had good success with GSoC, and so something that builds on that (Winter of Bugs?) might be worth thinking about.
There are also possibilities beyond just direct paying for development. For example, if we increased our presence at conventions that might pull in more ordinary volunteer developers. Training is another avenue I think could be good. Either arranging some development tutorials ourselves, to help users graduate into developers, or even sending existing active developers to developer training classes (to learn new tricks for performance optimization, debugging, etc.)
I am also a big believer in the power of bug triagers to help make bugs easier to fix, such as by helping gather stack traces or document steps to reproduce. This is another tedious job (as I know from experience), but doesn't need to be thankless, and there could be some low-cost ways of stimulating these efforts.
Of course, it's not as easy as it sounds: A qualified developer who knows the code enough and can meet the technical requirements is needed. And probably also a person willing to take care of the paperwork and administrative tasks. And people willing to review the patches...
I'm glad you brought up the administrative side. This may seem minor, but it's a prerequisite to finding a developer and is tedious work so could be hard to find a volunteer. We would need this person to be reliable and responsive, able to talk with the lawyers, and prepared to make tough decisions.
In fact this was my main counterargument to Brad's suggestion; he indicated the conservancy would love to help on the financing/legal end, but part of the management of this would have to come from us.
This has been essentially the same problem the board has run into with other proposed activities - someone needs to take the coordinator role to get it organized.
So that's my thinking. Before we start really talking about a paid bug fixer, we need someone to volunteer to do coordination and administration. Or lacking a volunteer, it's an important enough role we could consider making it a part-time paid role, particularly if we could raise enough money for multiple efforts.
Bryce
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.
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.
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.
Regards, Krzysztof
On Fri, 2013-09-20 at 18:41 +0200, Krzysztof Kosiński wrote:
offered a bounty of $100
Did you collect the $100?
Knowing how big a problem is, is work too. $100 was probably way too small a price for the amount of work you did.
I think enhancing our ability to deal with some of these things in a structured environment will allow us to follow procedures where bugs are closer (although never perfect) to their cost and more users can be brought to bare on an item.
5,000 people can raise $100k pretty easily with $25 each and that's the sort of money that can move mountains of bugs. We have way more than 5k users, but we get nothing because we ask for nothing, or rather we extend no invite, no channel and no opportunity.
Improving our reach with users beyond the edge of the mailing list and launchpad project will help there.
The other point which I did agree with from our previous discussion was that leadership is probably more important at this time. I very much agree. Our positive attitude for this release is awesome to see and our commit and comment rate is way up. That's going to help us make the environment fertile for whatever we end up doing with regards to funding.
Martin,
2013/9/20 Martin Owens <doctormo@...400...>:
On Fri, 2013-09-20 at 18:41 +0200, Krzysztof Kosiński wrote:
offered a bounty of $100
Did you collect the $100?
Knowing how big a problem is, is work too. $100 was probably way too small a price for the amount of work you did.
Yes, it was in the form of an Amazon gift code.
5,000 people can raise $100k pretty easily with $25 each and that's the sort of money that can move mountains of bugs. We have way more than 5k users, but we get nothing because we ask for nothing, or rather we extend no invite, no channel and no opportunity.
That's true. That $100 bounty was offered in a Launchpad comment in a very ad hoc way.
Improving our reach with users beyond the edge of the mailing list and launchpad project will help there.
I think inkscapeforum.com would be the place to start. We could also request some SVGs to use as test cases.
Regards, Krzysztof
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
2013/9/20 Bryce Harrington <bryce@...961...>:
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?
I rewrote the rendering code as part of the GSoC 2011 project. It occured to me that this bug could be fixed fairly easily while doing that. The fact that there was a reward did not influence me all that much, though of course it did cause me to pay a little more attention and put in some extra effort to backport the fix to the stable branch.
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?
1. More comprehensive extension model. Currently it is not possible to implement a new object type or a tool in an extension; we are limited to a simple filter model. There is no access to Inkscape's API, and everything has to be reimplemented on the filter side.
2. Real script bindings, designed using the "worse is better" principle of Unix. We currently have a DBus binding, which has some nice features (e.g. language neutrality), but is not very practical or used a lot. We also can't use it for anything even remotely performance-sensitive due to the IPC overhead. Scripting could become a lot more practical if we provided a conventional binding to Python, used it internally to implement high-level features, and provided a scripting console where you can execute commands in the same way as in the interactive Python interpreter. gedit has something similar. In the extreme case, all non-UI functionality of Inkscape could eventually become a library with a Python binding.
Regards, Krzysztof
On Sat, 2013-09-21 at 01:00 +0200, Krzysztof Kosiński wrote:
- Real script bindings, designed using the "worse is better"
principle of Unix. We currently have a DBus binding, which has some nice features (e.g. language neutrality), but is not very practical or used a lot. We also can't use it for anything even remotely performance-sensitive due to the IPC overhead. Scripting could become a lot more practical if we provided a conventional binding to Python, used it internally to implement high-level features, and provided a scripting console where you can execute commands in the same way as in the interactive Python interpreter. gedit has something similar. In the extreme case, all non-UI functionality of Inkscape could eventually become a library with a Python binding.
I agree +1, I like the idea of keeping the dbus binding, just because with the latest commits we should be able to run more headless than before. But I also like the idea of having python built right in, such that writing a new plugin would be made much easier. Feedback and ownership is critical and I think a group mechanism would be ideal.
An example from my own work. The barcodes plugin doesn't take ownership over the objects it makes afterwards. that means you can't edit it on canvas and you can't script it with say an mail-merge type extension.
Martin,
On Fri, Sep 20, 2013 at 6:22 PM, Martin Owens <doctormo@...400...> wrote:
An example from my own work. The barcodes plugin doesn't take ownership over the objects it makes afterwards. that means you can't edit it on canvas and you can't script it with say an mail-merge type extension.
And you just nailed why I HATE using extensions in Inkscape.
Cheers, Josh
On Sat, Sep 21, 2013 at 01:00:01AM +0200, Krzysztof Kosiński wrote:
2013/9/20 Bryce Harrington <bryce@...961...>:
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?
I rewrote the rendering code as part of the GSoC 2011 project. It occured to me that this bug could be fixed fairly easily while doing that. The fact that there was a reward did not influence me all that much, though of course it did cause me to pay a little more attention and put in some extra effort to backport the fix to the stable branch.
Mm, so it was sort of problem-of-opportunity because you were already engaged with the general area in question.
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?
- More comprehensive extension model. Currently it is not possible to
implement a new object type or a tool in an extension; we are limited to a simple filter model. There is no access to Inkscape's API, and everything has to be reimplemented on the filter side.
*Nod*
I recall the filter extension design concept was done extremely early in the project (like literally the second or third Inkscape release if I remember right). I'm impressed it's served duty so long, but it was always our intent to replace it with a proper extension API some day.
I've thought that there really should be at least two levels for the extension API. The first would be low level document model type stuff, like what the current filter system does relatively well. The other one would be a higher level one that encapsulates GUI functionality and provides a richer access to Inkscape's internal API.
- Real script bindings, designed using the "worse is better"
principle of Unix. We currently have a DBus binding, which has some nice features (e.g. language neutrality), but is not very practical or used a lot. We also can't use it for anything even remotely performance-sensitive due to the IPC overhead. Scripting could become a lot more practical if we provided a conventional binding to Python, used it internally to implement high-level features, and provided a scripting console where you can execute commands in the same way as in the interactive Python interpreter. gedit has something similar. In the extreme case, all non-UI functionality of Inkscape could eventually become a library with a Python binding.
Way back in the day when we first did the original extension system, python was popular but we were mindful that so was perl and other scripting languages. So we felt that keeping things language-neutral would give some future-proofing. Indeed, Inkscape may have benefitted a lot from that decision in various ways, but clearly python has been the dominant language in practice.
DBus is really awesome, but agree it's not the right medium for designing an extension system around due to fundamental performance issues when using IPC.
Ultimately, what I'm imagining would be an extension system that would be document-specific in some fashion, so if you load an artistic-oriented document, you'll get one style of functionality/buttons, and if you're loading some 2D drafting-oriented document, you'd get some other style of GUI functionality.
Bryce
participants (4)
-
Bryce Harrington -
Josh Andler -
Krzysztof Kosiński -
Martin Owens