Slashdot Mirror
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."
There's a new enyojs.com website, where you can read about Enyo and try out some example apps, as well as downloading the current version.
What a strange sig, considering you not only replied to but agreed with an AC.
Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
HP announced they were open sourcing it last month, which it says in the summary. It doesn't explain well that HP today laid out their plans, with release dates, for a complete open source webOS. As well as released the Enyo framework, across multiple platforms. Already seeing apps running in browsers and on Android based on it. Today is the actual start of them opening up the source on things. http://precentral.net/ - Multiple articles up today detailing everything that was released today.
Sometimes when I'm working on projects things disappear, I suspect gremlins.
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
Check out my sci-fi/humor trilogy at PatriotsBooks.