Front page | perl.perl5.porters |
Postings from July 2010
Hi Gabor, Gabor Szabo wrote: > That does not sound good. What did I misunderstand? There is no central committee of perl 5 development. At its heart, the p5p is just a bunch of volunteers. We are weakly organized. The central element is probably that all those who can change the sources agree to not do things that the pumpking disallows. It doesn't work the other way around. The pumpking can't force anyone to do anything because we're all volunteers. TPF is entirely unrelated and as far as I know, it has no say at all about the development. TPF (or any other body) accepting money on the behalf of the p5p is a serious problem. It implies that those who give money (and by extension TPF) can steer p5p. That's conceptually not possible AT ALL. > Would it make any difference if you knew that the company paid TPF > for some generic idea of "ongoing perl development"? I'm not qualified to answer this. But I have a hunch that other people might say "not without a plan on how to spend it". > Not paid directly for the implementation of the thing but that it could > be later allocated either as bug bounty, as a larger grant like the one > of Dave Mitchell or even for some CPAN related grant? > > Would that make it more likely that someone will implement XYZ? Again, probably not without a plan how that's going to happen. The bounty thing might work but I as far as I know, it has not been attempted in this context. It may be difficult to implement, but I'd like to see it tried. I think we're blocking on a volunteer willing to give this a shot. Okay, let's take a step back: a) I claim that we can and must not allow any external body decide about what features/changes are added/applied to the code base. => Just because user 'a' thinks a certain feature would make her life much easier and is willing to spend money on it, it's not clear it's a good language design. Some people who've been involved for a long time are good at spotting things that don't fit in. We get these endless discussions from time to time. These discussions aren't very compatible with somebody willing to spend money and not time. Despite a lot of bikeshedding and time wasted, these discussions are not entirely without value: They help find the corner cases that nobody spotted at first. In case of pay-for-a-feature, the decision to have it was likely made MUCH earlier (before they decided to pay for it) and by the wrong people. => Just because user 'a' made the new feature happen in one way or another, it's not clear who will clean up the inevitable set of bugs that appear two years down the road. Unless we're willing to let the code base rot, we thus cannot let outsiders dictate the course of development. b) There aren't enough people willing AND capable to accept payment for work on the perl core. So just having money doesn't make things happen. I think Nicholas proved this quite nicely with his list of committers and their current employment status. => This could be a different matter if there was the offer of a longer term employment to work on core. But this must still be compatible with a). => Thus a donation of labour would be more helpful than money. Of course, barring compliance with a). In the end, it boils down to that we don't have anything to sell to companies or other organizations. We can only reach agreement on a course of action on a case-by-case basis. E.g. I believe there was some consensus that we do want function/method signatures and read-only aliases. The second step is figuring out how to make it happen: money to pay for a TPF(-alike)-employed hacker? bounties? donation of labour? etc. Accepting money with arbitrary strings attached would be a very bold move for anybody at this point. Regards, SteffenThread Previous | Thread Next