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?
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Oh, come now, not everyone ignores "Donate" menu item :)
Uhhh.. What "Donate" menu item? Oh, there it goes, hidden away there ;-)
That reminds me of something else I meant to say. If we're going to take the donations idea seriously, we need a Big Orange Button (eg http://micropledge.com/) on the homepage, because people won't do it if it's not easy to find.
On said button, if people like gespertino's idea of targets with included features, then the button should also list 2 or 3 of the most popular features (or maybe a bit of unintrusive javascript to fade new features in and out, to show the range of features being funded). This would definitely help attract funders.
- Bryan
On Thu, Mar 17, 2011 at 07:50, Bryan Hoyt | Brush Technology < bryan@...2310...> wrote:
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- PS. Check out the Brush newsletter: *Subscribe or read our previous newsletters* http://brush.co.nz/newsletters
Bryan Hoyt, *Web Development Manager* -- Brush Technology *Ph:* +64 3 741 1204 *Mobile:* +64 21 238 7955 *Web:* brush.co.nz
I absolutely love the idea of trying to use money to organize a sprint for certain well-defined targets, it might actually work. I do think it would be good to flesh out some of the details and work on how exactly this should be organized, but it's a very interesting idea.
Some of the things I definitely like about your proposal: - Money goes towards motivation and team spirit. - The "donatable" targets are defined by developers, not by users (helps prevent too much fragmentation), although users can of course still suggest things. - It's clear what someone's money is going to be spent on (and more or less when it's going to be spent).
I do have a few questions though. I love the idea to bring developers together, as I think this could indeed help increase and maintain motivation, as well as providing a moment to simply "get things done". However, what kind of numbers and funding are we talking about? If we want to meet physically the costs could be quite high. (And if we don't meet physically, then what is the funding for?) Also, what you describe still requires quite a bit of organization, how would you propose to deal with that? (Are you proposing to head up the operation?) And how do we deal with disgruntled donors? If we define groups of features/fixes as targets, that's cool for helping focus donations and such, but afterward I am sure that some things won't have been addressed and people won't like that if they donated because of that specific item. This is of course not "fair", in the sense that we would be (and should be) clear about how this process works, but human psychology is hardly ever fair.
BTW, if we want to get this moving fast we could consider doing a kind of trial around LGM.
On 2011-03-16 19:19, 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (3)
-
Bryan Hoyt | Brush Technology -
gespertino＠...400... -
Jasper van de Gronde