Re: Perl 6 fundraising and related topics.
I've repeatedly encountered remarks about how much Perl 6 development is constrained by the fairly severe time and energy constraints of its overwhelmingly volunteer development team. I think that is a valid point. On the other hand the language has to become mature gradually, and that process can't be sped up easily. But I think in many areas we have reached that maturity now. So over the next few months, I'm planning to learn about fundraising, and see what I can accomplish on behalf of Perl 6 development. Very nice. To that end, I'm soliciting: (1) your suggestions for preparation, (2) your ideas for proposals, and (3) your reasons why the Perl 6 ecosystem (including Parrot and CPAN6) is one of the world's greatest and and most extremely leveraged causes (technically, economically, and socially). I'll also put whatever fundraising-oriented material I come up with on the Perl 6 wiki, to help and encourage others along similar lines. I'd like to raise the question what to do with the money, assuming that you can acquire some. I see two possible route: 1) Let The Perl Foundation decide what to do with the money advantage: they already have a comitee (is that really an advantage? ;-) disadvantage: they seem to think that Perl 6 on Parrot is _the_ and the only way to go. (There's nothing wrong with rakudo and parrot, but Perl 6 is, by definition, a language. And it should have multiple implementations) 2) Decide it in some other way, without involvement from TPF. advantage: presumably no bias towards one implementation disadvantage: we have to think of a way to decide who gets the money. (And hackers tend to not wanting to decide such things, and invest time into them). As for your third point, why Perl 6 (+parrot) is the all empowering technology: * it unites many programming paradigms * simple but powerful parsing facilities * modern concurrency (think STM, autothreading) * mechanisms to easily interoperate with other languages * it's easy to use libraries from other dynamic languages * backwards compatibility to perl 5 (not on the language level though) Cheers, Moritz
Re: Perl 6 fundraising and related topics.
[...] To that end, I'm soliciting: (1) your suggestions for preparation, (2) your ideas for proposals, and (3) your reasons why the Perl 6 ecosystem (including Parrot and CPAN6) is one of the world's greatest and and most extremely leveraged causes (technically, economically, and socially). I'll also put whatever fundraising-oriented material I come up with on the Perl 6 wiki, to help and encourage others along similar lines. I'd like to raise the question what to do with the money, assuming that you can acquire some. I see two possible route: 1) Let The Perl Foundation decide what to do with the money advantage: they already have a comitee (is that really an advantage? ;-) disadvantage: they seem to think that Perl 6 on Parrot is _the_ and the only way to go. (There's nothing wrong with rakudo and parrot, but Perl 6 is, by definition, a language. And it should have multiple implementations) Should it really? I mean: is the time right for that now? It's really hard to define what the community wants: noone can speak on behalf of the whole community (and the community has many ideas about things :)) However, and strongly IMHO, what most Perl users want is very simple: to have a not-too-slow Perl6 implementation that runs most of the current Perl6 specification - without too much bugs. Maybe the Perl Foundation got some people who can decide what we need to achieve that - someone must make a decision where the money should go anyway. Surely it is very nice to have many implementations (we have seen how much helpful the Pugs project was to help Perl6, for example), but could that happen (or: be sponsored) *after* we have *one* that is fairly complete?? After some time, one imlementations will emerge and become *the* implementations anyway. What I would like to add is that IMHO this time implementators should be sponsored. That is: those who hack and those who answer their questions on how to hack. :) I also think that different Perl groups all around the world could be responsive. Let's contact the gazillion perl lists and say: ...if you like Perl, please give $10 to the \Let's have Perl6 now!\ foundation! I would, and I will personally send anyone to /dev/null who would not! :) - Fagzal
Re: Perl 6 fundraising and related topics.
[...] Should it really? I mean: is the time right for that now? Let's ask the other way round: Is this the time for only one implementation? And who decides that it's the one based on parrot? What happens if parrot turns out to be a dead end? (very unlikely, but possible). Let's give some $$$ to say 3 implementations, see what they come up in a month. Lets mupltiply their 1/CPU-time with #of tests passed :), and the winner gets the rest of the money. It's really hard to define what the community wants: noone can speak on behalf of the whole community (and the community has many ideas about things :)) However, and strongly IMHO, what most Perl users want is very simple: to have a not-too-slow Perl6 implementation that runs most of the current Perl6 specification - without too much bugs. I also think that many perl people also want a good Perl 6 specification. I agree. On the other hand, I would be very happy if current implementations could pass 25% of the current specification. And different implementations help to explore different part of the specs. That also helps rakudo, if the specs are well covered by other implementations and are therfore much stable and really implementable. How about sponsoring some implementations, but give special attention to the most promising one? If you argue that most people want an implemenation that covers large parts of the specs, the most logical step would be to boost pugs development. It's the most advanced implementation by far. And I do believe that it can be sped up if you really want that. I don't know Haskell and the structure of Pugs so I cannot comment on that - however, I have some doubts. And speed *is* important: I don't think we can expect people to start using Perl6 if it runs even 2x slower than Perl5. If Pugs was really up-to-date (I mean: feature complete), only slow, I would probably use it to learn Perl6, because Perl6 is just lovely. I would not build something on it, though. So where's that pro parrot bias coming from? IMHO people like the idea of Parrot. It just.. makes sense. It's been around for quite a while. There are releases every month or so. There is a mod_parrot. These things. Surely it is very nice to have many implementations (we have seen how much helpful the Pugs project was to help Perl6, for example), but could that happen (or: be sponsored) *after* we have *one* that is fairly complete?? After some time, one imlementations will emerge and become *the* implementations anyway. Oh will it? Just like we have one C implementation? Or one Forth implementation? Or one Lisp implementation? Can we add PHP and Perl5 to the list? ;) What I would like to add is that IMHO this time implementators should be sponsored. That is: those who hack and those who answer their questions on how to hack. :) Aye. And perhaps the ones who write the specs, if they want/need it. I meant that, too. I also think that different Perl groups all around the world could be responsive. Let's contact the gazillion perl lists and say: ...if you like Perl, please give $10 to the \Let's have Perl6 now!\ foundation! I would, and I will personally send anyone to /dev/null who would not! :) I don't know if that's a good idea - sadly many of them have the perception that Perl 6 is vapour ware. I guess I have more trust in people than you do. :) I know that the company I work for would never give a dime to any foundations, but I would. And I *own* that company :) That's because a company is always a business, but a person can be an enthusiast. Anyway: I don't know anything about fundraising, so maybe I shouldn't say a thing... I just say it might worth a try. People would help to convince other people. Once again: I would. My idea would be to ask big companies that use perl (for example amazon) if they would sponsor some of the development. Are there other organisations that routinely sponsor open source software? Can't we just go to Google and say we will use Yahoo if they don't give us some money? :) And if they don't, we tell everyone! ;) How about just looking at the sponsor logo-s on the webpages of different OS conferences? There should be plenty, and could give some ideas. (But there really should be something you can *show* to them. I mean at least *one* webpage on Perl6 which is not outdated :) ) YAPC organizers should have some ideas, too. - Fagzal
Re: Perl 6 fundraising and related topics.
[...] To that end, I'm soliciting: (1) your suggestions for preparation, (2) your ideas for proposals, and (3) your reasons why the Perl 6 ecosystem (including Parrot and CPAN6) is one of the world's greatest and and most extremely leveraged causes (technically, economically, and socially). I'll also put whatever fundraising-oriented material I come up with on the Perl 6 wiki, to help and encourage others along similar lines. I'd like to raise the question what to do with the money, assuming that you can acquire some. I see two possible route: 1) Let The Perl Foundation decide what to do with the money advantage: they already have a comitee (is that really an advantage? ;-) disadvantage: they seem to think that Perl 6 on Parrot is _the_ and the only way to go. (There's nothing wrong with rakudo and parrot, but Perl 6 is, by definition, a language. And it should have multiple implementations) Should it really? I mean: is the time right for that now? Let's ask the other way round: Is this the time for only one implementation? And who decides that it's the one based on parrot? What happens if parrot turns out to be a dead end? (very unlikely, but possible). It's really hard to define what the community wants: noone can speak on behalf of the whole community (and the community has many ideas about things :)) However, and strongly IMHO, what most Perl users want is very simple: to have a not-too-slow Perl6 implementation that runs most of the current Perl6 specification - without too much bugs. I also think that many perl people also want a good Perl 6 specification. And different implementations help to explore different part of the specs. That also helps rakudo, if the specs are well covered by other implementations and are therfore much stable and really implementable. If you argue that most people want an implemenation that covers large parts of the specs, the most logical step would be to boost pugs development. It's the most advanced implementation by far. And I do believe that it can be sped up if you really want that. So where's that pro parrot bias coming from? Surely it is very nice to have many implementations (we have seen how much helpful the Pugs project was to help Perl6, for example), but could that happen (or: be sponsored) *after* we have *one* that is fairly complete?? After some time, one imlementations will emerge and become *the* implementations anyway. Oh will it? Just like we have one C implementation? Or one Forth implementation? Or one Lisp implementation? What I would like to add is that IMHO this time implementators should be sponsored. That is: those who hack and those who answer their questions on how to hack. :) Aye. And perhaps the ones who write the specs, if they want/need it. I also think that different Perl groups all around the world could be responsive. Let's contact the gazillion perl lists and say: ...if you like Perl, please give $10 to the \Let's have Perl6 now!\ foundation! I would, and I will personally send anyone to /dev/null who would not! :) I don't know if that's a good idea - sadly many of them have the perception that Perl 6 is vapour ware. My idea would be to ask big companies that use perl (for example amazon) if they would sponsor some of the development. Are there other organisations that routinely sponsor open source software? I know if Software in the Public Interest, but I think they only provide legal backing. Cheers, Moritz
Re: Perl 6 fundraising and related topics.
(Someone wrote:) And who decides that it's the one based on parrot? It is the original plan to implement Perl 6 on Parrot, and the project that gets most developer attention. What happens if parrot turns out to be a dead end? (very unlikely, but possible). Then backtracking would happen, or more likely: Perl 6 would die. If this community cannot come up with a virtual machine that can handle Perl 6, then many people will lose all hope. But as indicated, this scenario is very unlikely. Let's give some $$$ to say 3 implementations, see what they come up in a month. Lets mupltiply their 1/CPU-time with #of tests passed :), and the winner gets the rest of the money. I do not think a *contest* would be in the best interest of Perl 6. And different implementations help to explore different part of the specs. Yes, they help. But it's not necessary. That also helps rakudo, if the specs are well covered by other implementations and are therfore much stable and really implementable. If something turns out to be un-implementable, they will find out regardless of the existence of other implementations. However, I do have a lot of faith in Larry Wall's language design skills, and think that this is a very minor, even hypothetical issue. If you argue that most people want an implemenation that covers large parts of the specs, the most logical step would be to boost pugs development. It's the most advanced implementation by far. And I do believe that it can be sped up if you really want that. If sufficient people were fond of hacking on its Haskell guts, then probably we wouldn't be having this conversation. But it appears that most volunteers consider Pugs a very useful exploration project (that would have been used for bootstrapping if development hadn't stalled), but see Rakudo as the beginning of a feasible real world Perl 6 implementation. So where's that pro parrot bias coming from? It shows progress, and several well known, trusted and skilled hackers work on it. -- Met vriendelijke groet, Kind regards, Korajn salutojn, Juerd Waalboer: Perl hacker [EMAIL PROTECTED] http://juerd.nl/sig Convolution: ICT solutions and consultancy [EMAIL PROTECTED]
Re: Perl 6 fundraising and related topics.
Should it really? I mean: is the time right for that now? Let's ask the other way round: Is this the time for only one implementation? And who decides that it's the one based on parrot? What happens if parrot turns out to be a dead end? (very unlikely, but possible). Let's give some $$$ to say 3 implementations, see what they come up in a month. Lets mupltiply their 1/CPU-time with #of tests passed :), and the winner gets the rest of the money. It's a nice idea, although it ignores development speed nearly completely. And different implementations help to explore different part of the specs. That also helps rakudo, if the specs are well covered by other implementations and are therfore much stable and really implementable. How about sponsoring some implementations, but give special attention to the most promising one? Sounds good. If you argue that most people want an implemenation that covers large parts of the specs, the most logical step would be to boost pugs development. It's the most advanced implementation by far. And I do believe that it can be sped up if you really want that. I don't know Haskell and the structure of Pugs so I cannot comment on that - however, I have some doubts. Same here, but I know that pugs is compiler. Which means that the generated code can be optimized, but it's hard to decrease the compilation time. There is another reason why pugs won't make everyone happy: portability. Try to amke GHC run on anything but linux and windows (and perhaps a few *BSDs), and you'll see what I mean ;-) So where's that pro parrot bias coming from? IMHO people like the idea of Parrot. It just.. makes sense. It's been around for quite a while. There are releases every month or so. There is a mod_parrot. These things. You got a point there. Surely it is very nice to have many implementations (we have seen how much helpful the Pugs project was to help Perl6, for example), but could that happen (or: be sponsored) *after* we have *one* that is fairly complete?? After some time, one imlementations will emerge and become *the* implementations anyway. Oh will it? Just like we have one C implementation? Or one Forth implementation? Or one Lisp implementation? Can we add PHP and Perl5 to the list? ;) I hope you understood the irony;-) : There are many C compilers, many lisp compilers etc., but only one perl5. My idea would be to ask big companies that use perl (for example amazon) if they would sponsor some of the development. Are there other organisations that routinely sponsor open source software? Can't we just go to Google and say we will use Yahoo if they don't give us some money? :) And if they don't, we tell everyone! ;) ;-) How about just looking at the sponsor logo-s on the webpages of different OS conferences? There should be plenty, and could give some ideas. Good idea. (But there really should be something you can *show* to them. I mean at least *one* webpage on Perl6 which is not outdated :) ) I tried to update dev.perl6.org, and I got read access to the svn repository. So I sent patches by email - and that's it. No further response from the webmasters. And the patches haven't been applied. Anybody knows whom I have to poke? webmasterm at perl.org didn't prove very responsive :( Cheers, Moritz
Re: Perl 6 fundraising and related topics.
On Wed, Feb 20, 2008 at 11:55 PM, Conrad Schneiker [EMAIL PROTECTED] wrote: I've repeatedly encountered remarks about how much Perl 6 development is constrained by the fairly severe time and energy constraints of its overwhelmingly volunteer development team. Here is something to consider. Unless we can afford to fund an individual full time with enough money for them to pay for their own health coverage and other benefits, the amount of time they are volunteering is already as much as they can afford. In other words, they still have to work a regular job and make time for their family (or whatever substitutes for the real world) and giving them money isn't going to equate to them being able to devote to more time. That isn't to say that these volunteers don't deserve to get compensated but it is unrealistic to expect that money will equate to more time in many of the cases. The statement above does not apply to everyone and those who do freelance and consulting work could likely devote a great deal more time if they would be compensated in some way for their time. I myself, with a few others, made a failed attempt at funding Audrey to work on Pugs full time and her rate was ridiculously low - $100 USD/day. So over the next few months, I'm planning to learn about fundraising, and see what I can accomplish on behalf of Perl 6 development. To that end, I'm soliciting: (1) your suggestions for preparation, (2) your ideas for proposals, and (3) your reasons why the Perl 6 ecosystem (including Parrot and CPAN6) is one of the world's greatest and and most extremely leveraged causes (technically, economically, and socially). I am mostly ignoring the rest of what others have said in this thread because I think it is detracting from your intention of getting money to people to work more. Here is one thing that has frustrated me about TPF. They are a non-profit organization. Yeah, kind of suprising that would be the frustrating thing. The issue is that they can't take money from Bob to give to Sue to work on Bob's widget. This is an extreme oversimplification but in general, they have to abide by the rules that allow them to keep their non-profit status. Where am I going with this? Regardless if we use TPF or not, I think what will get more people to contribute is having some say as to where there money goes. To that end, I suggest having a list of projects currently being funded. A donator can choose which fund their money goes to or can choose a general fund if they don't care. I don't suggest these projects be generic and nebulous either (though they could be for the same reason a general fund is). In other words, there might be a Rakudo fund - generic. There might also be a fund to fix RT # 31415 which is a Rakudo bug. I am not suggesting this is the solution to all the problems. It likely will create more. What I can tell you is the number one thing that has prevented me from donating a lot more money is having little to no control over where it went. Actually, it has been years since I have contributed to TPF. Now, I just write a check to the individual(s) I want to help. I don't get the tax write off but I know where my money is going. In closing, what we don't need is something to fight over. Hopefully you will find the sweet spot - I sure hope you do. Cheers, Joshua Gatcomb a.k.a. Limbic~Region
Re: Perl 6 fundraising and related topics.
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I don't know if that's a good idea - sadly many of them have the perception that Perl 6 is vapour ware. I guess I have more trust in people than you do. :) ... and I just learned that my opions are biased. Last week I visited the German Perl Workshop, and heard many Perl 6 critical statements. Now I learned that in general the Germans are rather biased against Perl 6, while other parts of the community are much more open. I was there at the workshop too. You cannot count me in into being biased against Perl 6. Only biased that it takes so long :-). I know, and there were some others (like Herbert aka lichtkind, who writes and maintains the German Perl 6 wiki pages) with the same opinions. But the general atmosphere there was rather anti Perl 6, and the recent discussions on the wsinfo mailing lists show that all too clearly. Cheers, Moritz
Re: Perl 6 fundraising and related topics.
[...] I was there at the workshop too. You cannot count me in into being biased against Perl 6. Only biased that it takes so long :-). I know, and there were some others (like Herbert aka lichtkind, who writes and maintains the German Perl 6 wiki pages) with the same opinions. But the general atmosphere there was rather anti Perl 6, and the recent discussions on the wsinfo mailing lists show that all too clearly. It's really not a surprise. Perl5 is not broken: IMHO many Perl5 programmers just wanted some little (erm...) things like a less hacky OO implementation, better function parameters and types, things like that. Perl6 promised these and much-much more, so people were happy. There were news, ideas, Parrot hacking, etc... and people got bored. Basically nothing happend for *years*. That is: many things happened, there is a nice specification now, brilliant features, etc., you all know - but for Average Perl Joe, there is just nothing there. Average Perl Joe needs this: perl6 hello_world.pl That's why I am rooting for rakudo: there is progress, or so I figure, and I can ln -s rakudo perl6 anytime :) Once you can point people to some targzipped source or an RPM or something like that, and 10 minutes later they can indeed write the above line, they will not be anti-Perl6 anymore. (I mean if they will be anti-Perl6 after that, then we can just close this list and everyone can just go home.) - Fagzal
Re: Perl 6 fundraising and related topics.
On Thu, Feb 21, 2008 at 01:29:05PM +0100, Juerd Waalboer wrote: : Then backtracking would happen, or more likely: Perl 6 would die. If : this community cannot come up with a virtual machine that can handle : Perl 6, then many people will lose all hope. Except that the people working on alternatives to parrot are already doing that exploration in parallel, and therefore would have no change in attitude. When it comes to exploration, it doesn't really matter how many people lose hope--it only matters how many people keep hope. :) : But as indicated, this scenario is very unlikely. : : Let's give some $$$ to say 3 implementations, see what they come up in : a month. Lets mupltiply their 1/CPU-time with #of tests passed :), and : the winner gets the rest of the money. : : I do not think a *contest* would be in the best interest of Perl 6. It's already a friendly competition. To the extent that it is perceived as a zero-sum game, we'd lose the friendliness, I fear. : And different implementations help to explore different part of the : specs. : : Yes, they help. But it's not necessary. I respectfully disagree with your definition of necessary. :) : That also helps rakudo, if the specs are well covered by other : implementations and are therfore much stable and really : implementable. : : If something turns out to be un-implementable, they will find out : regardless of the existence of other implementations. However, I do have : a lot of faith in Larry Wall's language design skills, and think that : this is a very minor, even hypothetical issue. The trouble is, I have no visibility into the assumptions made in the parrot core that might cause problems later. And certainly the initial design of parrot was aimed more at a faster Perl 5 than at Perl 6 as we know it now. My knowledge of implementability is primarily at a more abstract level, and cannot easily be brought to bear on any particular implementation. I was already told at the beginning of Perl 6 that nobody wanted my implementation skills. :) : If you argue that most people want an implemenation that covers : large parts of the specs, the most logical step would be to boost : pugs development. It's the most advanced implementation by far. And : I do believe that it can be sped up if you really want that. : : If sufficient people were fond of hacking on its Haskell guts, then : probably we wouldn't be having this conversation. But it appears that : most volunteers consider Pugs a very useful exploration project (that : would have been used for bootstrapping if development hadn't stalled), : but see Rakudo as the beginning of a feasible real world Perl 6 : implementation. Yes, as Wim pointed out, pugs really wasn't fast enough to be a real implementation, and the hope that supersmart Haskell optimizers would fix everything didn't really pan out, nor the hope that Perl programmers would flock to learning Haskell in droves. As a case in point, I have two programs that translate STD.pm to versions of Perl that can run on pugs and on Perl 5. The pugs compiler takes about 2 minutes to compile the results, and flakes out half the time for no apparent reason. The Perl 5 compiler takes about half a second, and blows up reproducably. :) : So where's that pro parrot bias coming from? : : It shows progress, and several well known, trusted and skilled hackers : work on it. As do other efforts. They're just differently skilled, differently well known, and differently trusted. Larry
Re: Perl 6 fundraising and related topics.
Larry Wall skribis 2008-02-21 11:15 (-0800): On Thu, Feb 21, 2008 at 01:29:05PM +0100, Juerd Waalboer wrote: : Then backtracking would happen, or more likely: Perl 6 would die. If : this community cannot come up with a virtual machine that can handle : Perl 6, then many people will lose all hope. Except that the people working on alternatives to parrot are already doing that exploration in parallel, and therefore would have no change in attitude. Oh, but I would certainly not want to discourage them. For $$$-funding, however, I think it is not practical to pursue multiple approaches simultaneously. : I do not think a *contest* would be in the best interest of Perl 6. It's already a friendly competition. To the extent that it is perceived as a zero-sum game, we'd lose the friendliness, I fear. Friendly competition is good, but projects competing to win a grant might hurt all of the projects severely, as well as the social structure that joins the projects in the larger Perl 6 community. -- Met vriendelijke groet, Kind regards, Korajn salutojn, Juerd Waalboer: Perl hacker [EMAIL PROTECTED] http://juerd.nl/sig Convolution: ICT solutions and consultancy [EMAIL PROTECTED]
Re: Perl 6 fundraising and related topics.
On Thu, Feb 21, 2008 at 01:07:14PM +0100, Juerd Waalboer wrote: : I would very strongly prefer to see a focussed effort towards a single : full implementation. : : There are many important benefits to having several implementations, : including fun and education. But commercially and marketing-wise, it's : better to first assemble something that *works*, then to optimize its : performance. Hmm, indeed, you just named one of the things that pugs did better than parrot. : In terms of priority, the compatible alternative : implementation should come third, not first. It would be unwise to fund : multiple implementation projects, and raising those funds would be : unnecessarily hard. Well, given that we can't even raise funds for the first project very well, it's a bit premature to be playing zero-sum games. : Many people feel that Perl 6 is going nowhere. Best thing the community : can do, is to show them that Perl 6 is getting somewhere. Again, that was a really good argument for pugs, which among other things *renewed* excitement in parrot. But pugs also demonstrated some difficulties with that approach. The fact is that every approach has run into almost insurmountable difficulties from time to time, and it's only brute determination that keeps most of us going most of the time, regardless of which project we're working on. : Every destination is most quickly reached by travelling in a straight line. I suppose such a platitude is natural for a plat-lander, as long as you don't mind swimming a few canals from time to time. Certainly it seems to have been a good argument for the armies that regularly march through your neighborhood... :) But around where I live, just because you can see the top of a mountain doesn't mean you can get there easily. Most often, a straight-line march will leave you with a deadly amount of either air or water under you. You're lucky if you only end up with a sheer rock face in front of you. The West was explored primarily by mountain men who lived off the land trapping furs, not by the railroad companies. You're arguing for the railroad company to do the exploration, but I think we also desperately need to find somebody who is interested in buying furs from those people who do not like to go in straight lines. As they say, the map is not the territory. And the terrain is just a small part of the geography. Geography is a subtle destiny, when it's not being obvious. Not every design decision is as obvious as the Panama Canal, and even that took two tries. And it's still not a straight line...where's Paul Bunyan when you need him? Larry
Re: Perl 6 fundraising and related topics.
On Thu, Feb 21, 2008 at 4:23 PM, chromatic [EMAIL PROTECTED] wrote: On Thursday 21 February 2008 06:25:42 Joshua Gatcomb wrote: I could take a month's sabbatical from my day job for $5000 without losing insurance coverage or other benefits. That's slightly more than Audrey's $100/day, I know, but it's substantially less than my consulting rate and somewhat less than my salary too. I could probably make 100 - 150 high-quality commits to Parrot in that 30 day period. Perhaps more. I'm probably not the only Parrot/Perl 6 hacker in this situation. I was beginning to wonder if my post to the thread had gotten eaten. Thanks for replying. I probably didn't do a good job of tying the two portions of my reply together, but if I were to go to the donation page and I saw Project: Allow chromatic for 1 month to work exclusively on parrot Deliverables (if applicable): 100 - 150 high quality commits Required: $5000 Current: $0 I would be very inclined to make a donation. In fact, if you can find 9 other people willing to do so - I will cut a check for $500 any time you are ready. That's besides the point. I don't believe just getting more money is the solution. I think we need to do a number of things: 1. Identify people, like you, who are in a position to trade time for money and the projects they will work on 2. Allow people to choose where their money will go (if that's what they want to do) 3. Do it in a way that causes the least amount of fighting -- c Cheers, Joshua Gatcomb a.k.a. Limbic~Region
Re: Perl 6 fundraising and related topics.
On Thu, Feb 21, 2008 at 8:19 PM, Geoffrey Broadwell [EMAIL PROTECTED] wrote: Someone earlier in this thread mentioned that this can't be done directly because of rules surrounding TPF's non-profit status. That someone was me and that's not what I said. I said it isn't as simple as Bob saying I want to pay Sue to work on this widget and having TPF broker the deal. I won't pretend to understand all the intricacies. I said it is frustrating, as someone willing to donate money, that I can't just say give it to Sue please. case). But if that is really the way of things, can TPF go the Mozilla route to break the logjam? Tax incentives are great, but having piles of money sitting around not getting to hackers is clearly not working for us. There are grants that are being awarded. Those grants are getting things done (thanks for the progress on the PDDs Al). I am in no way suggesting that people not donate to TPF. I have in the past and I might in the future. I also help them out in other ways, by writing code for small projects that they need done. I am only suggesting that, for the specific purposes of this thread, going the TPF route may not be the most efficient way to accomplish that goal. Cheers, Joshua Gatcomb a.k.a. Limbic~Region
