HP To Open Source WebOS

First time accepted submitter pscottdv writes "This year the artists formerly known as Palm had quite a rough few months with HP dumping the hardware side of their own webOS mobile computing platform – their most recent move, having been announced just last month, is live today: open sourced webOS for all. While the actual main product which will be known as Open webOS 1.0 will not be released until September, they've already got the Enyo piece of the pie available today."

Comments

Well, that's nice .. but

[ackthpt]

Yet another large open source project to further tax the talent pool? I wonder how much attention it will get.

Re:Well, that's nice .. but

[tomhudson]

Yet another large open source project to further tax the talent pool? I wonder how much attention it will get.

From devs? None - HP is open-sourcing it because it's DEAD.

From everyone else? We need a good laugh (or cry) now and then ...

If HP could make a nickel out of it, or find a buyer for it, they would.

Re:Well, that's nice .. but

[hey!]

And exactly how is the talent pool ever supposed to expand without a few blue water projects where a ambitious young developer can go out win himself some glory, instead of having his patches being sneered at by the old boys club?

Re:Well, that's nice .. but

[dgatwood]

Good thing some of us like to actually do things for fun every now and then. The Open Source philosophy isn't about making money, it's about sharing knowledge.

No disagreement. That's certainly why I write open source. That and because I need to get things done anyway, so I might as well make it available in case it can help somebody else.

That said (and I'm probably going to get modded down for this), this is also one of the reasons why there is so much open source software out there that is of lesser quality than similar commercial software. Make no mistake, there are plenty of great open source apps and drivers and kernels and daemons out there, but for every one that's a gem, there are a hundred more that are so-so, and a thousand more that are complete crap. The reason for this is, to a large extent, because most of the folks working on it are creating things for fun, for themselves, whatever, and when they get things working well enough to do the job, they do no further work on the project. The result is a whole truckload of abandonware.

More importantly, because the developers often just need to get something working well enough to get something done, maintainability is often the last thing on their minds, resulting in some incredibly bad code. I've seen copious amounts of code in fairly significant open source projects over the years that was so bad, it made me want to cry.

I actually had such an experience just a couple of days ago (on a project that will remain nameless), with code that pre-defined macros for things like SIZEOF_LONG instead of just doing sizeof(long), resulting in the absolute inability to do single-pass compilation of multi-architecture (fat) binaries until I ripped all that crap out. I would have understood that sort of thing ten years ago, but this was top-of-tree in their git repo. Apparently nobody told these developers that there is exactly zero runtime penalty to using sizeof(), and thus absolutely no good reason to predefine macros with hard-coded sizes.... *sigh*

Of course, these sorts of problems occur in the commercial world as well, but the abandonware is more common in the open source world, largely because the barriers to entry are so much lower. You don't have to hire a team of ten people to develop an open source tool—you just write it in your spare time—so there's no real financial incentive not to abandon it when you no longer need to use it yourself, and there's no real financial incentive to ensure that the software is portable, maintainable, or extensible.

Admittedly, the abandonware is less catastrophic in the open source world because you can ostensibly fix it yourself, at least up to the point where code rot makes this impractical, but combined with the open source community's apparent disdain for API contracts and backwards compatibility guarantees, code rot hits open source a lot faster than closed source, which counteracts much of that benefit after only a few years. Just last week, I encountered some fairly fundamental API breakage while updating software written only about a year or two ago, to the point that it required some serious backporting to make things even compile—the function name was the same, but with a very different list of parameters, data types, etc. That's just unacceptable, and leads to serious long-term maintainability problems for anyone who isn't willing to constantly live on the bleeding edge of everything.

And then, there's the general sloppiness of data types. Good code doesn't use types like int or long most of the time, because you can't rely on their sizes. That's why we have inttypes.h. No code that has been touched in the past five years should be using those data types, period, because the results are simply not portable. Yet as recently as a few days ago, I ran into "assert(sizeof(long) == sizeof(uint32_t));". Not even a compile-time failure. A runtime failure. Like I said, some of th

Where's the beef?

[jpwilliams]

Why would a developer work on this when there are other, more widely adopted platforms to develop on?

Re:Where's the beef?

[oodaloop]

Listen buddy, the egg came first. That's where the chicken came from, OK?

Late

[amiga3D]

If they had done this from the start I believe they would have fared much better.

Re:Comments in every topic now.

[Anonymous Coward]

They do ot so the mods will waste their points. Then they come back later to lay down the anti-open source 'turf with impunity. Oldest waggener edstrom trick in the book.