Thanks. If you think this is cool, remember - this is only the first step. Ultimately, there will be a complete class hierarchy in parallel to the regular java class hierarchy, but without the constraints that the Java class system has (and without the OvrlyLongNamesForClasses.andStupidlyNamedMethods().

For example, yesterday I re-implemented the TPoint, TDim (dimension) and TRect classes for a future release that will not use the standard java classes.... there are no separate getter/setter methods named getX and setX, just an overloaded x() operator that allows you to optionally set the value of x. Also very handy for chaining ... so you can do stuff like rect2.x(rect1.x(42)) to set both rectangles x coordinate in one line, or rect2.x(rect1.x()) to set rectangle 2 left to whatever rectange 1 left is.

I've been using this style for ... gee, since before the web or java were invented ... and I don't understand why nobody else has come up with anything similar. I guess people just like to make things more complex than they should be.

BTW - you can do the same thing in languages that don't support operator overloading, just check the number of parameters to determine if you need to set a value before returning a value.

Be great if you could have it show a live preview as a thumbnail every time you load it - though with 3000 bookmarks, you'll hose your network connection for a while ...

Go for it - my original idea was for something that would unify all resources - web pages, local documents, music and videos, etc ... and it's just not possible in a browser without some really lame work-arounds (like requiring people to run an instance of a server locally)

Browsers really do suck for lots of things.

Thanks for the positive feedback. However, it doesn't address the real issue directly - that most open source doesn't have a valid financial model.

It's one reason why Linus did his "you should do everyone a favour and just kill yourselves" rant against opensuse - the resources that *could* be used to develop something that works properly are spread among far to many distros and projects, and none of them is in a position to spend what it takes to fix the problems, because they won't get a ROI on it - everyone else will just appropriate it.

It's funny how Apple was able to create their original box - hardware and software - for less than has been wasted so far, despite hardware now being cheaper, and we have far better software tools now than we did 30 years ago.

Or how they were able to shift to x86 and improve things, and here I am stuck with a linux desktop that can't talk to my camcorder, scanner (though the linux-compatible printer now *finally* works), etc. and that even after adding the fusion repos, still some formats re not supported ....

I'm beginning to think I'm sticking with linux out of sheer stubbornness ... :-p

I'll try to explain it a bit better.

Right now, there's this terrible tendency to fork, fork, fork - and every fork is competing for eyeballs, mindshare in the noosphere, or whatevr you call it. And they're all mostly starving for revenue, because there are just too many choices, and the quality is pretty much the same among all of them.

So, you created a game as open surce, someone else forks it, now you're both competing for code contributions (after all, there's no guarantee the fork will stay code-compatible as time goes on), so the fork eventually results in the pool of contribs you can use going down, nt up.

Also, your user base goes down, since it's now split with the fork(s).

So, you take and make a closed version, fix all the bugs in the closed version while improving the code, and release it as closed-source. You weren't getting the relevant code contributions anyway, so you don't really care. You'll continue to benefit from artwork and plugins (you've maintained binary compatibility), so now you can compete again.

More importantly, you can now sell the program on a per-copy basis, generating the revenues to continue development if the game is any good.

Both your old code base and the open forks can continue to exist, and you can even maintain the open version of your code if you so choose - that's your choice.

The problem is that open source isn't competitive for most projects when it comes to the financial side. Which is why there are so many bugs out there - nobody is being paid to do the dirty work of fixing them. In terms of percentages, open source is actually losing ground - compare the explosive growth in paid closed-source apps in the mobile field. Why? Follow the money ...

It's either adapt or die. I don't see any other way if improving the quality of the stuff out there, or of reducing the insane number of forks (how many linux distros are there out there now? Over 1,000?)

I'm hoping it does too ... but it's still a pain in the eye ... which might or might not be part of the frustration. I have a few ideas I'm going to test, see if it makes a diff.

That many bookmarks? That's a LOT. How do you find time to do anything else?

No, the list of all side effects is not generally available, and certainly not in the product monograph made available to physicians (I checked). Others have complained about similar side effects, but the doctors tend to not be very receptive because ... wait for it ... the side effects aren't listed in the physician's product monograph.

And they're certainly not listed in the drug insert that accompanies the medication.

No - this is a 2 billion a year drug that has now had two studies that, for example, show a 3x to 5x higher incidence of stroke leading to death than a placebo ... and yet that's brushed off as "random chance." Once might be random, two out of two is a warning flag.

You don't have to claim it when in many cases it's not all that hard to do. One of the side benefits is that you can clean it up, make it run faster, and have fewer bugs - all selling points.

I think it's time for projects that are GPL to consider doing this themselves - create a for-profit derivative (not all derivative works infringe copyright) and use that to subsidize the open version.

It would reduce the insane number of forks we have, as well as improve quality overall.