Front page | perl.perl5.porters |
Postings from July 2010
On Fri, Jul 9, 2010 at 9:09 AM, Nicholas Clark <nick@ccl4.org> wrote: >> As I recall there were lots of discussions on the question what companies >> really need in regards of perl. Especially when the backward compatibility >> and deprecation issues were discussed. It seemed that not many companies >> were involved. Even if people employed by companies were involved that >> was not obvious (to me). > > It's not obvious to me either, but most people mailing the list are employed, > and I suspect that most either don't use their work address, or are clear that > they aren't officially speaking for work. This I think is what is really needed first before a marketing push to get money for development. Nobody is sure that companies want specific features and bug fixes. I know what *my* experiences were working for a large Perl shop (50-60 developers in my office, 500K lines of code, 10+ year code base, earning of millions in revenue annually). In the three years I worked at that shop we only submitted one official bug report via perlbug, and one I couldn't resolve well enough I felt it was worth submitting via perlbug.[1] The second bug there was directly a result of upgrading the entire codebase from 5.6.1 to 5.8.8 in a single swoop. That is the kind of stability I know exists at a lot of larger shops. The larger you are the more cautious you are with upgrades etc. At least that is the trend I've seen. Getting a conversation started with actual development managers who have the power to change their product's perl to find out what they want/need with this kind of an environment is I think more important than offering to solve perceived problems in exchange for money. I'm not sure "feature XYZ" is gonna be the answer. I'm not a close follower of p5p, are there a lot of features and fixes flowing out of ActiveState into core? This would be another sign of the size of the market for access to perl core development. >> So it seems p5p wants to get feedback from companies but then >> says we won't actually do anything with that feedback. > > Roughly yes. Because it's a mailing list of volunteers. No-one can promise > the time or effort of anyone else. > >> That does not sound good. What did I misunderstand? > > That it's a mailing list of volunteers, not an organisation able to make a > formal collective decision, and formally allocate resources. There is a difference between feedback and direct feature/bug requests. Enough development managers saying "no you're doing fine" would be enough to kill this thread I think. > I (personally) *would* welcome you talking to companies about what they might > want, and how they might contribute to get this. But I think it's key to get > the expectation management right. In particular, on the assumption that > companies would be prepared to offer cash rather than developer time, then > I think that it's key for those companies to be aware up front that > > a: Whilst they are welcome to donate to TPF, how TPF implements its grants > programme, and the non-organisational volunteer nature of the perl 5 > developers, means that such money may not be spent any time soon. > > b: If they are looking for a specific return from their donation, such as > "fix bugs that bug us", then likely a better course of action is to buy > a commercial support contract (ActiveState being the obvious candidate), > and then get value for money from it by getting ActiveState to fix those > bugs, and thus the fixes into the core perl distribution. Exactly. Years of ennui about the DARKPAN menace, and backcompat police, and how to expand core contributors to Perl 5 suggest that the *problems* need to be researched further before solutions are suggested. > My concern is that it would be too easy to fall into what I see as a trap: > > a: A very generous company gives money to TPF "for the benefit of Perl 5" > b: TPF is unable to spend this money, because there is no-one available to pay > c: The company is disappointed, and wants its money back > d: TPF looks bad; Perl generally looks bad > > > with a result far more negative than not getting a donation in the first place. > > Getting companies more involved would be wonderful. But please, manage their > expectations appropriately. > b: is even more insidious because there is no well defined "benefit of Perl 5". Is moving to llvm a benefit worth paying for? Is adding delimited continuation support a benefit worth paying for? Better exception handling? Documentation? Extended / Enlightened core? better toolchain support on XYZ platform? Memory / Speed enhancement? More long term bug fixes? A paid triage person/group? These have all been suggested, they are all hard enough problems that throwing money at them *might* make them easier, many of them don't even require core hacking skills. But if the company that donated the money doesn't agree that set chosen to be funded is a "benefit" ... then some version of c is gonna happen regardless of the outcome of finding someone we can pay or not. Nicholas is spot on when he says that these expectations need to be managed. But, p5p isn't an organization that can manage these expectations. It's not an organization. -Chris [1]: I want to thank Nicholas who at the time helped sort out both issues even if he doesn't remember it, and I'm not sure either was actually resolved by anything other than "new hardware". Public thanks isn't something I do enough of, and I want to get better at it.Thread Previous | Thread Next