$30 isn't much to you or I, but for a 13 year old in a rich world country who happens to have cheap/free access to a 'net connection and the game by some means, it might be a worthwhile investment of time otherwise spent doing nothing.

CCP doesn't invent the isk from nowhere and sell it, they only facilitate trade. So, in effect, they provide a method to get money INTO the system, but no way to get money OUT of the system. So the cheap labour doing the ISK farming shifts from being leeching, annoying, out-of-universe professionals, and moves to being young players who can earn enough to subsidise the regular play.

By making it harder to farm, the labour gets more scarce, the value of it goes up, and more young players can earn their way into the game.

> FOSS has no way to deal with a project's sole maintainer dieing

Perl does.

As usual CPAN has a long-established and regularly used method for dealing with issues like this. There's a process of handing off namespace control to new maintainers when previous maintainers go silent or die. With 7000 developers in the system, our experience is that a few dozen are going to die every year (although I imagine this will slowly increase as the median age creeps upwards).

In practice, we tend to see one significant case of death or death-like symptoms a year that requires a little more hand-holding to do proper module hand-off.

In the last few years, we've lost the maintainer of Perl's Tk bindings, a significant DateTime contributor, and a few years ago one of the largest CPAN authors quit programming to become a missionary in Japan and asked for new maintainers for all his work (that would be the "death-like symptoms" part).

The article quotes the requirement as being "contains no material hidden defects".

That idea would superficially (I am not a lawyer) appear to allow any open source off the hook as long as you have a public bug tracker.

First, technical reviewing.

There's tons of really bright people around. And the thing about these people is that they, like everyone else that's any good at what they do, have far too much to do and not enough time to do it in.

They are fully invested in the problems that they are involved with right now, and don't have time for doing anything outside their area.

So find the smartest people you know that seem reasonably trustworthy, and that are in a different area to your idea, but are close enough that they have the skills to critique your idea.

They should be able to find any clear technical failings in your idea.

As for the rest, a venture capital guy once gave me a great one minute summary of what you need to make it when you are thinking about doing a new startup.

1. A working product.
2. A confirmed market.
3. A sweetheart customer.

All three? You win. Two, you have a good chance. One, maybe but unlikely.

Notice that the IDEA for the product doesn't feature at all. Unless you get quickly and easily get that idea into a working saleable (first-generation) product, and find either a proven market or a big bootstrap customer, you're venture is dead regardless.

"I don't know, therefore God"

I keep meaning to get shirts done up in Latin for this...

I work with some front-line coders in their 40s and 50s.

I find them to be competent, responsible, diligent and consistent.

But the spark is gone... that ability to look a new, hard, problem right in the face and say "Right, lets go solve that" seems to be reduced.

That isn't necessarily a bad thing. These guys are happy where they are, and if you treat them well they stay with you forever.

But I wouldn't want more than about a third (maybe half if it's a low-creativity project) of the team like this.

So you have reduced the energy of your efforts (you write less code) and you are solving problems with an increased application of experience and wisdom (you write better code).

Which is entirely my point.

At some point, progressing in the direction you are, you hit a limit. You've solved the problems in your head and in the initial class layout correctly, and the actual overheads of implementation is what is ruining your productivity.

So to break past that barrier you need to start using minions to get that actual legwork done.

I for one write much less code than I used to, but I get much more solved because I can solve all the serious design problems in a way that will be straight forward to implement, then you get a minion working on finishing off and testing the implementation.

Then you move on to the next problem.

It's nearly impossible to maintain the energy and volume of coding that you do in your 20s.

As you get older, your energy and raw intelligence is going to fall, but your experience and wisdom is going to increase.

If you can, you need to find some way to channel and adapt to this change.

On the pure technical side, that is going to mean heading up from coding into higher level design and architecture, solving the conceptual level problems (with a reliably high level of correctness) of how a big system will work and then steering teams of people for the implementation. You'll still be coding semi-regularly, but if you're lucky you will only have to step in to solve the REALLY hard/interesting bits that the lower level people can't handle. Sometimes this means picking a specialisation and sticking with it, certainly.

If you aren't one of the technical elites in this way, management can be another way to utilise your experience and wisdom. This is especially the case if you've worked a lot with medium to large teams on projects, and you've gained an understanding of how to set up effective development teams. Management also carries with it a political/social/personality requirement. If you've got enough geek cred to know your field, but you can hang out with the sales and marketing people and be comfortable, then perhaps that is your direction.

If you read The Economist, you may have noticed a recent review of the book "Nudge".

I have more than a sneaking suspicion the original poster (and TFA) have been reading this as well.

Suffice it to say that the shallow commentary here pales in comparison to the jaunt through behavioural economics that the book provides. If you can get past it's focus on public policy and just absorb all the core information, the book provides good advice than you'd ever think existed on the art of defaults.

> By spending time now building the interfaces and
> tools that will enable them to use computers more
> easily, you will also be ensuring your own ability
> to use them in the future.

Nobody thinks they are going to be disabled.

It's as simple as that I'm afraid.

In the Perl world I know one major hacker that has done a ton of accessibility work. In his case, it's his daughter that has the the disability, so he has a direct and immediate interest in helping her.

FYI, the new Padre Perl IDE is itself written in Perl.

http://padre.perlide.org/wiki/Screenshots

wxWidgets is mainly just a wrapper around GTK.

You use Wx when you specifically want your program to "look native" (without having to emulate it) across all three Win32/GTK/Mac platforms.

Yes, that means it has the idiosyncrasies of all three platform. And if your open source application doesn't have a development team large enough to deal with three separate applications sharing backend components, then it's a fairly cheap way to achieve both platform support and native look and feel.

I've used it a couple of times for exactly that purpose.

But if you're Google, and you can afford the programmers to support three forks with common components, then you don't pick Wx. You go straight to lower layer source and use GTK.

> I suspect that has a lot to do with the character and nature of Australians in general.
> I may get criticised for stereotyping, but most Australians of my acquaintance take
> pride in the blunt honesty prevalent in their culture, so I don't think I'm out of line.

Speaking as an Australian, I'd say that it's not because the honourable minister is blunt and straight forward, it's just that he's a bloody idiot.

... for Perl the Padre IDE is getting pretty awesome.

Works identically on Windows, Mac and Linux and they even managed to get the entire IDE to install itself from the CPAN.

Setting the scene or the tone for something is easy.

You have a couple of shiny eye-candy "hero shots", maybe introduce the opening of the storyline.

That's the easy part. Tons of shitty movies are able to put together a pretty awesome looking trailer.

Putting together enough complexity, story telling and depth to carry an entire movie is a whole different kettle of fish.