I think it's a really good idea to *organize* the items being funded, into a set of manageable chunks. It's an alternative to A) having hundreds of individual features, suggested and funded individually (i.e. funder 1 wants support for his Whizz Tablet so he gives $100 for that feature, funder 2 wants smoother curves, so she gives $50 to that cause) or B) having nothing specific to direct the money towards -- i.e. just a  "donate to Inkscape" button.

Neither A or B adds up to real money very fast!

However, I do think it'll be essential how it's presented & promoted. Get into the minds of the people who want to fund Inkscape. Very few (though some) will want to give $100++ of their hard-earned cash just for the love of it. Most people (myself included) will be naturally inclined to fund the parts of Inkscape they *don't* love, or the parts they want to be better/different. That's where the real drive to give comes in.

For example, I badly want Inkscape to export multi-page PDF without all the hassle it currently involves. I'd give money to that cause, but I don't, because I don't think it'll help get it implemented (judging by the current discussion, I'm right). So I simply don't give money to Inkscape, period.

However, if it was present very clearly to me that multi-page PDF export was part of the next target, and that giving money would help get it done, I'd donate.  I think this says a few things about how to handle & present donations:

 => Make it very clear that their favorite feature is part of target X, and that giving money will help it be implemented
 => A "subscribe to feature" option (a bit like you can with Google Code's issue tracker) would be great. You could keep subscribers informed, and you could ask for more money -- people who've given money before are far more likely to again. Remember, they're invested now, and they want to see it happen. There's nothing wrong with asking for more money.
 => Make it easy for people to suggest features on the website, along with an amount they'd donate towards that feature, but the devs get the final say in what features end up being implemented, and in which targets.
 => If the feature is included, then the original suggester is notified and asked for the donation, if any.

 -  Bryan

On Thu, Mar 17, 2011 at 07:19, gespertino@...400... <gespertino@...400...> wrote:
A couple of days ago I mentioned to Prokoudine an idea that probably
is worth to discuss.
It's a known fact that bounties never worked for Inkscape and GIMP,
but that doesn't mean necessarily that money wouldn't help. What is
needed is to find a different way to use the money that comes from
donations and could come from companies (like linux vendors, for
instance).
This isn't a new idea. It's just a mix of some ideas that already work
(crowd funding, GSoC, hacking sprints, etc).

Instead of picking individual feature requests, developers could make
a list of targets, following project's roadmap. In that point
community (and companies interested) could express their needs and
wishes, and project active developers could decide if some of those
requests fit with the existing plans.
Once a targets lists is created and cleaned up, developers should make
an estimation of time and people needed to reach those targets. The
idea is to group those targets in small "packs" so it's not too
ambitious to expect their completion in a limited period of time.
Also in that stage would be good to define if more people than the
available is needed, and what upstream projects are connected to the
planned goals in order to contact their mantainers and communicate
what would be needed and in what timeframe.
Once that information is ready and available publicly, then money
comes into play. People can start to donate and companies could be
contacted to get sponsoring.
That money wouldn't be used to pay for features. The idea is to
organize a hacking sprint, giving developers a chance to meet and more
importantly, companies could lend developers who could benefit from
having core and active developers in a common physical space to ask
them about project particularities. This would be also a good
opportunity to document code and details that could be useful for
other developers in the future.
I think this could refresh the motivation of existing developers and
attract new people, while at the same time it could make companies
commit to the development of graphic applications. After all, having
quality applications is what free operative systems need to reach more
people and be more interesting to users, so this could be a good
opportunity for linux vendors.

I know this is just an idea and it making it work it won't be as easy
as talking, but at least I'm interested to know what developers and
the rest of the community thinks about it.
Is it possible? Could it work for projects like Inkscape, GIMP or Scribus?

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...1794...s.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel



--
PS. Check out the Brush newsletter: Subscribe or read our previous newsletters

Bryan Hoyt, Web Development Manager  --  Brush Technology
Ph: +64 3 741 1204     Mobile: +64 21 238 7955
Web: brush.co.nz