It's also the reason why the Java enterprise platform is getting ever more bloated and unwieldy, while most real people write stuff in PHP.
The "Java enterprise" platform is ambiguous today, unless you're talking strictly of Sun J2EE components. If you find the J2EE components to be bloated and unwieldy, there are now plenty of lightweight alternatives. Fact is, Java has the best quality Open Source tools available today for developing business applications. If you think Ruby on Rails, Python, and PHP can do the same, you've never developed the type of software I'm talking about. The HTML web is not everything. A very large share of real-world business software does not align to single-threading and being tied synchronous to HTTP requests. Furthermore, rich-clients are absolutely essential in many cases. Of the three Java-alternative languages, Python is the only one with most of the core language features needed to compete in this arena. However, Python's development tools are still in their infancy, it is not as performant as Java, it's multi-platform client capabilities are limited, and the language specification itself is sloppy. (hence projects like PyPy which hope to remedy this)
The future of application software does not belong to lightweight scripted HTML-web software; it belongs to lightweight Semantic-web software that makes heavy use of XML web services, intelligent agents, and dynamic (repository-style) data stores, and smart/rich clients. Right now there are two platforms that can serve this need: Java and.NET. The longer that Open Source developers waste time on their "re-invent the wheel geek toys," the further behind Java will fall for lack of due mindshare. Java is the premiere Open Source language today and it is the rallying point behind the most successful commercial Open Source efforts. As any language, Java still has flaws but they are being fixed rapidly. Open Source developers need to collectively realize this and get with the program. The alternative is a world where.NET is the only relevant platform for anything beyond forums, blogs and CMS tools.
I think the fact that KDE even exists means that Gnome shouldn't try to be more "advanced" (bloated).
KDE and GNOME have a nearly identical memory footprint and overhead. Given the fact that KDE provides more real-world functionaity for that same "resource bloat" which one has the better features/bloat ratio?
So people like the advanced options, the glimmer and the numerous widgets. Those people pick KDE. Some people just a basic, day-to-day desktop environment. Those people pick Gnome. The availability of both seems ideal to me.
There is absolutely no reason why people can't have both. That is the ultimate fallacy of the GNOME HCI philosophy. Include options and features, but hide them intelligently so they don't get in the way until needed. Create rich widgets but allow the user to customize them. Have glimmer but let it be easily turned off. This is the direction KDE4 is going and GNOME needs to follow if it is to remain relevant. I certainly hope it will, because other non-UI elements of GNOME are very promising.
It should also be noted that if one is to err in either direction, most people prefer excess features to excess simplicity if those features help them get their work done faster. That's why most people prefer KDE today. Neither is ideal, but it gets the job done.
But so what? The client side is rapidly being taken over by JavaScript/HTML and to a lesser extent, Flash.
In some ways, I wish this prognosis was as true to reality as the current hype suggests. The lightweight web makes everything neat and tidy since you don't have to worry about complex client-side platforms. (beyond a modern browser.. which will eventually mean Mozilla or Safari if IE continues to ignore W3C) Unfortunately, there are many things you still cannot do with JS/DOM/XHTML/etc. How important those shortcomings are has yet to be determined. I believe there is still a future in the myriad of W3C standards (especially with upcoming SVG, Canvas, CSS3, etc.), but I'm not sure how far these will extend beyond the document-centric web we know today.
One thing that could significantly change the picture would be a first-class integration of Java by the Mozilla project. This would provide a managed extension beyond the browser itself and the inherent limitations of JavaScript. (local hardware access, data caching, offline support, standalone web-managed apps, more efficient libraries for working with the DOM, etc.) This can all be done today with applets, Java Web Start, and Eclipse Rich Client Platform, but these are not bundled and integrated with Mozilla by default. If they were, Java / Mozilla / modern W3C standards would become an easily targetable platform for next generation web apps, while providing a seamless integration with today's web. It wouldn't be the end of the story, but it'd be a major step forward for open standards.
So I can understand why Ellison is trying to do what he is. as he sees that.NET has much synergy. More I look.Net, more I've started to wonder why it has been so overlooked.
What is truly mind boggling is the apparent conclusion that Java's correct "answer" to.NET is anything but a heavy embrace of open source. (Apache/LGPL style) The only way to match the growing "synergy" of.NET is to work from the grassroots up and not look only at the "big iron" markets. While lucrative, they can not yield sufficient growth for the Java platform..NET is not just an enterprise datacenter solution -- it's a unified desktop/server/mobile/web platform and as such it is very much "embrace and extend." The areas where Java is weakest are on the client side and this is where.NET has / will have it beat hands down unless drastic changes are made. Java Desktop was a good initiative but it hasn't gone nearly far enough. At this point, I'd have to put my bets on open source Java projects as the true saviors of the language. (even as pioneers of fresh approaches not designed by committee.. think EJB2 -> Spring/Hibernate -> EJB3) This is not to say Sun and Oracle lack a significant market in the high-end, but theirs is also a niche compared to the whole landscape.NET is going after. If they don't expand their horizons and embrace open source in the low/mid-range markets, the high-end niche could shrink as.NET marches forward on both hype and shiny new technologies.
If anyone from Sun happens to be reading this, please don't overlook where.NET is going with UI technology. Swing/SWT/JSF came too late and are inadequate in comparison to upcoming.NET XAML/WPF. Nevertheless, XAML is not perfect and there is still an opportunity to leap-frog ahead of it before it gains too much traction post-Vista-launch. Now would be the perfect time to tear down the popular image that Java is good for the server but awful for client-side.
Sort of like marrying Java and.NET again, but making it easy to port from any major Unix toolkit: GTK, QT, Motif (uughgh), TCL, and especially web-friendly languages.
Well put. I'm glad somebody brought this up. I believe it is imperative that the Open Source world begin to refactor into managed languages -- whether through Mono/CLR, an enhanced JVM with multi-language support, or something completely original (PyPy, etc.). It's this simple: We need to create a more cohesive "platform" for our developers and the best way to start is a unified object model. Imagine if Python, PHP, Smalltalk, and Ruby developers could efficiently re-use the wealth of professional-quality Open Source Java software that now exists. Imagine if Mozilla XPCOM could safely hook into standard "desktop" components to access local hardware. Imagine if Qt and GTK apps were no longer separated by the DCOM vs. CORBA disparity. (and hey, maybe we can someday agree on a single DE project instead of having both KDE and GNOME)
Java is a single language that runs on any platform .NET is a single platform that runs any language
What OSS really needs is a meta-platform that standardizes support for any language on any platform.
Is open source just a substitute for the lack of innovation in closed source software?
That's an awful broad statement. There is constant innovation in both open and closed source software. In some cases, yes, stagnation of closed software has been a breeding ground for open alternatives.
All these applications that are open source are in fact stuff we all know how to implement, it's just a matter of time and effort. We have an operating system, a database, an office suite nothing really new, they were bound to get open sourced.
It begs this question: Why are we trying to compete in the areas where innovation has already dried up? Today, few people are excited about new office suites, regardless of the source. Furthermore, MS already has an unshakable monopoly in yesterday's desktop-centric computing paradigm. But who cares?! The proper catalyst for change is radical innovation away from the status quo. (ie. data-centric, web-enabled, platform-neutral architecture)
It's quite amazing that these type of applications are still making money in their closed source incarnation after all this years.
It's not that amazing -- they're simply more polished than the Free alternatives. In the absence of a remarkably better alternative, most people just stick with what they are comfortable with. (and have already paid for) Also, there's an enormous amount of 3rd party business software that relies upon Windows and Office. Like I said, the desktop battle was lost years ago.. you might even say as far back as the death of OS/2. But again, why worry? The desktop is not the future anyhow.
But what about new stuff? Will someone with a really innovative idea open source it from the beginning? And even worse: will we notice?
It's already happening! Right now, the largest and most important battle of innovation is between Java and the.NET platform. (In case you somehow haven't noticed,.NET is a replacement for the entire "legacy" Windows platform, from the ground up..) Both Java and.NET are vying for position in the post-desktop era. (data-centric/service-oriented architecture) Open Source from the beginning? Yes, on the Java side. The most relevant, most innovative Java technologies are all Open Source today. Unfortunately, many people have become distracted by alternative technologies that won't matter when the dust settles. The OSS community needs to get behind Java en-masse to stay on the cutting edge and compete effectively with.NET / Vista. Don't get me wrong.. Ruby and Python have their place, but they are accessories to the larger, dominant platforms that will drive the majority of future computing.
Star Trek is well behind the known state of the art *today*.
Well, I'm really not much of a trekkie, so that may be true. I'm only basing on the few movies and DS9 episodes I've watched.:)
* ubiquitous access is a function of the capabilities and costs of technology, not any design issues at all.
True, but design factors can influence the market demand for ubiquitous access. Also, "ubiquitous access" refers to your personal data, not just internet connectivity.
* people today already have seamless interoperability if they stick with Apple. So broken systems are broken, yawn.
Seamless interoperability, by my definition, means that it doesn't matter whether you stick to one vendor and that the true "platform" is the communication protocols and languages that everyone agrees to use. Seamless interoperability extends far beyond the software on your personal desktop or laptop. Though better than most, even Apple's desktop platform and associated software reaches nowhere near the level of interoperability possible.
* centralized data stores are evil, what we should aim for is a secure logical fabric on top of a highly distributed tech layer. Somewhat like Ameoba aimed for but much better.
By "evil" I presume you mean "bad for privacy," but this is a non-issue if you control your own personal data repository on your own server in your own basement. To fully reap the benefits of ubiquitous internet access, all your data must be somewhat centralized. (For a large business, this centralization may, of course, be logical not physical) So my take would be "centralize the data, distribute the processing."
* highly associative / semantically rich? You invented this. The only evidence Star Trek has of it is its AI functions. Star Trek doesn't provide it as a model separate from AI, although it's certainly desirable and feasible.
Yeah, it's a precursor to practical AI, but perhaps not a direct observance. Then again, I'd guess you could find an episode where Picard asks the computer if alien race A has any relations with alien race B. Minus the voice recognition, that wouldn't really require AI.
* diverse client hardware? You invented this too.
Well, "client hardware" in the sense of tricorders, bridge and engineering consoles, communicators, the holodeck, and those tablet devices that appeared in modern series.
* dynamic user interfaces? Again, something you invented, though there it's not even clear what you mean, nevermind whether it's a good idea.
Dynamic as in "what you see is what you want/need" rather than static GUIs that somebody designed with specific use cases in mind. (not that there isn't a place for both..)
Regarding XML, the flaw in your reasoning is your assumption that XML has valid uses. XML is a truly horrific way of marshalling and distributing even textual data, even so-called documents.
I'm always open to new ideas, but what currently exists to replace it? With the amount investment into XML family tools at this point and the amount of unity XML related projects are bringing, a successor would have to be something dramatically better to be worth throwing everything out and starting over.
But to see that you have to think of documents as they *could* be (eg, think Xanadu) and not the crap we're currently dealing with which HTML created and XML aims to perpetuate.
I fully agree that today's paper-centric documents and HTML are junk. What's especially cool to me about Xanadu is that, before discovering it, I had pretty much come up with the same ideas independently, out of frustration with the current state of the art of the web. However, some of the ideas I've had go beyond "documents" so I think the "Xanadu model," though perfectly valid, is only a subset of the future direction of the web and computing in general. With that in mind, however, I don't see any way that XML will limit the industry fr
The desktop metaphor aka the "GUI" aka the PUI aka the Xerox PARC User Interface invented for the Alto, is 25 years old, not 10.
I know that. I was referring to how long progress has been *held back* due to stagnation. The desktop metaphor was a reasonable compromise while hardware capabilities improved. Today, it has lived past its usefulness.
Also, the so-called Star Trek interface you paint is really full-fledged AI and so is stupid as a goal of serious interface design.
I wasn't proposing the "Star Trek interface." I was pointing to some very general concepts surrounding the computer technology in Star Trek. Indeed, AI-centric interfaces are probably a few decades off. Regardless, many of the other concepts we can begin to aim for today: ubiquitous access, seamless interoperability, centralized data stores which are highly-associative / semantically-rich, diverse client hardware, and dynamic user interfaces.
Finally, XML is a step backwards. A HUGE step backwards. What was good for typesetting documents is really horrific for arbitrary objects.
XML isn't perfect and isn't a panacea, but I don't call any tool with valid uses a step backwards. I furthermore do not agree with those who claim that XML is only good for typesetting. Who said anything about objects? The purpose of XML is to separate code from data, and the family of XML tools that exist within this problem domain are very useful. XML is not a language optimized for heavy data processing, but it is generally better than s-expressions for document processing, arbitrary textual data markup, and RPC. XML is intended for marshalling textual data, not storing or distributing objects or binary data. Maybe someday we'll invent a language that does both perfectly, but that language does not currently exist and I am aware of no effort underway to create it. The question becomes: do we really need to marry code with our data interchange? Perhaps, yes, within a closed system. However, what if we developed a rich enough standardized taxonomy of data markup that it was unnecessary to ever embed code and logic within our exchanged data. As example, look at MathML. Do we need to include code for calculating a square root within marked-up data that represents a square root? Of course not -- that is the responsibility of software that operates upon data defined in the MathML XML namespace. So, in the end, it really comes back to all data being semantically rich enough that machines can "understand" it and do useful things from there.
First off, I just want to affirm this overall train of thought. The traditional, clumsy desktop metaphors have stagnated progress in popular computing for at least the last 10 years. It's quite time we break cleanly away from them, not just add 3D gimmicks to the mix as if this will fix the underlying limitations! I was going to post a similar commentary last night but ran out of time. Too bad I don't have mod points and/. only goes up to +5...
Live with a program like Spotlight for a while, and you start to find yourself bypassing the Finder and Desktop and folders altogether. What's needed is a better way to communicate (voice), and a system smart enough to know who Bob is, who Dave is, what a claims letter is, understands "last week" as a variable period, and can put it all together.
The first step is making all data semantically rich and uniformly accessible. Absolutely everything else follows. Before we can build advanced user interfaces, whether voice or 3D enhanced or whatever else, we need all of our data to be in a form that software can reasonably be trained to "understand." This in itself will be a huge endeavor and may well take the next 10-20 years to accomplish, given the vast quantity of low-context data that now exists. The current move toward non-proprietary XML formats is a tiny step in the right direction, but at least it's a step.
Yeah, it's the Star Trek interface.
It sounds silly but that really is a good comparison. It also brings up another huge point. In Star Trek, data is stored and processed somewhat centrally but is accessible anywhere using a multitude of devices and user interfaces -- from tricorders to tablets to bridge consoles to the holodeck. You don't see anyone aboard the Enterprise using a Desktop PC do you?!:)
Data is data. A "document" is really just an abstraction and collection of multiple piece of data into some logical and typically linear form -- most often for printing, etc. The first step is making all data semantic and machine understandable. Beyond that, we can decide if we even still need "documents." I, for one, would prefer a world where data organization and UI design follows the "what you see is what you want" principle.
Service-oriented software is the future but basic HCI guidelines are still relevant.
I absolutely agree, but I think new HCI guidelines will be required for new UI approaches. As example, most users will eventually have little or no contact with files and directories. As data becomes more semantically rich and interconnected, these will quickly become outdated concepts. Even today, think of how people use iTunes/Amarok vs. how they used to use Winamp/XMMS. Type managers are only the beginning.
Besides, until everyone has access to a 2Mbit broadband and runs their office or spreadsheet off of Google's or Microsoft's server, the desktop is still here to stay.
That's certain an issue. However, what's to say that traditional word processors and spreadsheets themselves are here to stay and that their rich-web successors will require the same bandwidth? I don't propose to have an immediate solution, but it certainly can be noted that popular office suite software does not produce semantically rich data. Sure, you can index documents for fast searching, but the machine cannot truly understand the contents or provide derivative results. What if spreadsheets were replaced by super-flexible object-oriented databases where the user could define the data types and methods on the fly. Such tools would be highly usable both at home and in the workplace to complement rigid enterprise databases. (obviously you'd still do accounting software, etc. via the latter!) What if word processors and DTP tools were replaced by document production systems that very cleanly separated content, style, and formatting? After all, I care most about the content, not paper formats. If I want to write a letter on my PDA, I don't care about how it formats onto Letter-sized paper for the time being. (and hey, maybe I run a paperless office anyhow!) These sorts of concepts offer to replace todays ultra-complex software with elegant simplicity and yet more power all the while.
The number of companies deploying open source technologies in their production infrastructures, embedding Linux in their hardware and porting their software in order to save their customers' hardware budget, these are a better barometer of the movement's success than the attempts of the aforementioned companies to make money off of something which is intrinsically free.
I agree. Open Source is a production method (like the assembly line) not a business model. There are both successful and unsuccessful companies that use the assembly line, or Open Source, as one factor of implementing their business model. (And many who use Open Source successfully are not even software companies!) With any new means of production, it takes awhile to figure out how to use the it beneficially. When the assembly line concept first hit the mainstream at the beginning of the 19th century, there were many perceived drawbacks. Products were inferior to the quality of individually hand-crafted goods, workers were subjected to unpleasant and often dangerous conditions, and maintaining tight engineering tolerances was difficult (such that parts would fit together at the end!). Today, Open Source faces many of the same types of challenges -- proper code modularity for easy sharing and re-use, effective leadership structure within large projects, clear communication and equitable division of labor, license compatibility issues, etc.
I personally believe that we'll see Open Source truly take off once IT departments stop viewing it as a free lunch (where available) and start treating it as an efficient acquisition process. When you consider how much business software is still written in-house or via contract, it stands reason that there is far more wheel-reinventing going on than necessary.
BTW, regarding OSS success stories, don't forget Java.. If you go to any Java User Group or professional conference, you'll find almost everyone talking about using Open Source tools. It's not because they have a political agenda; they've just learned to harnessed a better/faster/easier way to do the same old job.
HCI guidelines for traditional file-centric desktop interfaces came far to late to be relevant in the mainstream, which is 90-95% Windows. The whole "desktop computing" paradigm is fully played out and the future now belongs to service-oriented software, which is largely platform and UI client agnostic. We're about to be faced by a completely new set of methods for HCI, such as "what you see is what you want" and "pervasive computing." This is where the Open Source community should be focusing it's efforts -- not fighting over who has the best implementation of yesterday's stale concepts of computing. Most people today seem to prefer KDE because it has the features they are used to, yet most people spend an increasing amount of time using software through the web. KDE 4 "Plasma" is shaping up to be the best of both worlds with respect to full functionality that is elegantly managed, yet this polish is hardly relevant to browser based applications. From a developer perspective, Qt is far more attractive than Gtk, but even that doesn't matter very much because most of tomorrow's software will be written in a combination of scripting and managed-code (ex. Java, C#) languages, rather than C or C++. We need to just call it a day and move on to better things. It has become my opinion that neither KDE nor GNOME is enormously important to the future of Linux or Open Source. Continuing to maintain both is a terrible waste of limited development resources.
Indeed, the lessons learnable from the present failure of OO.org also point toward what makes Open Source work.. and the direction Open Source projects need to head in the future.
What OpenOffice.org teaches us foremost (though we've really known this for years) is that Open Source does not work very well for "big software" -- software that is monolithic and difficult for new developers to wrangle. If we could somehow plot modularity vs. success for all Open Source software, there would little doubt be a very strong correlation. Everything about "big software" drives away community. (and by "community" I mean both commercial and freelance/hobby developers)
Enter tomorrow's web applications. (but first get "HTML" out of your mind!) Exit today's desktop/client-centric software and replace it with modular, loosely-coupled, lightweight web software. Forget about designing software around the UI. Instead, think in terms of services and even intellegent software "agents" that automatically work together to accomplish what the user desires. Best of all, most of this software will be Open Source, largely because it will be so easy for anyone to develop their own components to add to the mix. Each component developer can aim for perfection and elegance within their component's limited domain of functionality. Welcome to the end of "big software" and perhaps the beginning of a true Open Source revolution. Unix brought elegance to operating systems with simplifying concepts like "everything is a file" and philosophies like "do what you do well and nothing else." Likewise, the web, as a platform, will bring elegance to how we build large, complicated software systems.
Those working on OO.org would be wise to immediately start porting it to Java, discarding old, crufty code as they go. Immediate benefits would include proper operation on all platforms and renewed interest from outside developers. The long term benefit would be re-usable components for the coming age of true web applications. An excellent place to start would be the OO.org import/export filters, as these would be immensely useful to web developers today.
This was probably due to proficious wining and dining on the part of MS.
More likely it was due to the fact that OpenOffice.org, while young and promising, still sucks terribly for real-world daily usage. Your home city probably thought it could simply get a "free lunch" by using it, rather than recognizing that it is still a needy, infantile project. OpenOffice.org is at the stage where early adopters *MUST* become co-developers for it to succeed. (both on a grand scale and for the success of their own deployments)
Let this be a lesson to any of you advocates and political types out there. OpenOffice.org is Free Software, but it's not free quite yet, in the sense of "install and forget about." For the sake of effective advocacy, don't confuse people and don't stretch the facts! It's not yet the highly-polished, feature-rich, hastle-free software that Office is. If you're going to promote OpenOffice.org, make sure that people know that they will have to invest fairly heavily in making it work properly, including contributions to its development community. (read: paying developers to fix the many show-stopper problems you'll encounter with it)
Rather than spending money on legislators, spending money on development, fostering open source via an express government preference will probably provide all the help open source needs to break the MS network effect, and therefore the monopoly, restoring the market to a healthy state.
Indeed. The author's proposal in the original paper is far too complicated. The government is going to spend money on aquiring the software it needs regardless. All it needs to do is contract with Open Source developers / consulting firms / solution providers / etc. instead of buying proprietary licenses. Make this a required preference for all government IT and the problem will otherwise solve itself through true free market competition. Open Source enterprise operates as a free market for development and support labor. It doesn't need government corporations or creative vouchers or any other socialist production means / incentives. Why replace copyright/patent with something equally artificial and potentially almost as inefficient? Sure, let the government spend $2bil/year for a few years on better meeting its own software needs, but channel this money into private firms and make them compete for contracts like everyone else! Government organizations generally have an awful track record for efficient production and innovation.
Once there are competitors in a market, the government actors should step back.
All that is needed to help restore competition is a short boost in the form of re-directed spending. After that, the free market can continue without intervention. It'll happen regardless, even if the government doesn't get involved, but there's a good case for some minor policy tweaking in order to bring the benefits sooner.
There is certainly a case for standardizing upon a single DE for corporate workstations. In this environment, the most important apps are: Web browser, Office suite, Java/.NET business apps (which are probably through the web, but some may have client components). From this perspective, it doesn't matter so much which DE is used. Both are basically just a way to launch the 3-4 apps used daily and manage the open windows. Compared to KDE, GNOME is a barebones DE, so it makes sense to use it when you don't want to hastle with users playing around with settings and screwing up their workspace. (I've found it's also great for elementary school students because it's so incredibly simple and intuitive.) But simplicity is simultaneously GNOME's strength and weakness. What GNOME really needs is an "advanced mode" that gives the power users more control and more options. This is especially true of the Nautilus file manager, which is utilitarian enough to drive experienced users crazy!:) (not to mention the kioparts integration with Konqueror is downright useful.. fish:// anyone?)
Because their desktop goals are corporate-minded, it's no surprise that Novell is going with GNOME. But what about personal desktops and applications? This is where KDE really shines because of the apps available. K3b (CD/DVD writing), Kopete (IM), Digikam (digital camera and album manager), and Amarok (iTunes-style media) are so far ahead of their GNOME "competitors" that DE choice hardly requires thought. Yes, you can run all these apps under GNOME, but then you miss out on some of the desktop integration and you double-up on memory usage.
It will be interesting to see where KDE 4 goes, with its focus on simplification and HCI guidelines.. perhaps it'll finally gain more corporate desktop interest in the US.
I have been impressed with the LED lights over florescent or incandescent. The subdued lighting is fine with me and the energy consumption / bulb longevity is the best part.
White LEDs are twice as efficient as most incandescents. However, compact fluorescents (CFLs) are twice as efficient as white LEDs. LEDs last 10x longer than CFL's, but they also cost several times what an equivalent number of CFLs would cost over the same lifetime. As a result, White LEDs are simply not economical at this time. They need to double in efficiency and quarter in price before they will compete head-on with CFLs. Right now, white LEDs are mostly useful for small tasks, such as flashlights, reading lights, nightlights, etc.
Go look at PEAR and the PHP manual index and then tell people PHP doesn't have a platform offering all those.
I do both PHP and Java development. Neither PEAR nor built-in PHP functions are a valid comparison to the extensibility of Java. Java itself gives developers a stable (if utilitarian) base and a standard namespace upon which can be cleanly extended as far as needed. PHP has no namespace and its base is slightly re-defined with every major release. PHP has its roots as a procedural scripting language for CGI. Java has its roots as an Object Oriented managed-bytecode general purpose language. They were intended to serve completely different purposes and it is a disservice to the programming world to cast them as equals. PHP is great for the public web, where rapid development and low barrier to entry outweighs other factors. Java is the best tool for the job when more formality is needed, such as complex business applications. Java can also do things that PHP simply cannot, by limitations of PHP's architecture. Perhaps most importantly, Java can fork off threads to do background tasks which are not related to HTTP requests. While this capability is nearly useless on the public web, it is an absolute requirement for most types of business applications.
The realist will note that PHP and Java are both popular in the areas where they are currently the best tool for the job. PHP has a large selection of software and tools useful for working with the public web. Java has a large selection of software, tools and frameworks useful for creating business, scientific, and otherwise data-intensive software. Of course, there is an increasing amount of overlap, mostly on the Java side. Java is becoming simpler to develop for and is gaining more agility in the light-weight arenas. For PHP to overlap into traditional Java territory, it will need a significant overhaul of its architecture. I don't see any evidence of this happening in the near future, though I suppose it can't be ruled out.
No, a Unix admin truly does *not* want to migrate to windows.
This is all well and good for us Unix admins. But for Unix to continue growing, we need to make Windows admins want to migrate to Unix. Unless all the basic administrative tasks are possible through a GUI, there's no migration path. Scripting comes later, after new admins are familiar with the landscape and after know they have a GUI to fall back on if they get confused.
There has been significant progress in the last 5 years in this area, but it's still not enough to make a dent in Windows Server marketshare for SOHO and medium-size businesses, where MCSE's are a dime a dozen.
Of course the real solution is not Unix but rather intranet rich-web Java applications.. Unix is just the cheapest way to get there.
I'd be more concerned that if it were GPL'd that it couldn't use some or all of the above.
You're thinking about it backwards, bringing up a common misconception. A GPL program can link to non-GPL (or even proprietary) libraries. There's no requirement that everything be GPL. The case you're thinking of is the other way around. In the case of a GPL library, only code under a GPL-compatible license can link to it. This, of course, can be a major impediment to Open Source developers using other licenses, and is the reason why most Open Source libraries are rightly LGPL. LGPL'ed code allows software of any license, even proprietary, to link to it. But LGPL is different than BSD because it still prevents proprietary forks of the linked code. LGPL is the "best of both worlds" Open Source license in many cases.
And frankly the most important question this class should address is - WHY OSS?
Absolutely! If people can't answer this question properly, they won't be able to run successful Open Source projects or contribute most effectively to existing ones. Don't forget the biggies:
- Motivations for OSS. Make sure you provide plenty of business cases and not just the standard fare philosophical / idealist fluff. Open Source is like the invention of the assembly line; it's a new way of doing the same thing, only more efficiently. In the end, it still comes down to making a living, whether directly or indirectly, while doing what you love. We need more Open Source entrepreneurs and not just more hobbyists.
- What characteristics do successful Open Source projects share? ex.) respected and trustworthy leadership, flexibility / openness to change, easy extensibility, low barriers to outside contributions, friendly networking with existing or related projects, well documented and highly modular code, etc.
- The importance of open standards. Don't reinvent the wheel unless it really needs to be done. Aim for compatibility and seek out partner projects in embracing and enhancing standards used.
- The benefits of using existing Open Source licenses. ie.) Don't create an island! Incompatible licenses spoil purpose of Open Source and limit the possibilities of code-sharing both into and out of a project. GPL and LGPL are the most popular licenses for a good reason: they're the most popular licenses.:) GPL is also the best license from a business perspective because it prevents competitors from creating proprietary forks of end-user software. LGPL is the best license from a re-usability perspective, such as for libraries. LGPL code is linkable with code of all other licenses but still protects the covered code from proprietary forks.
While I love the GPL, it's not for everything. There are some cases where it's just not profitable to give away your main product. This appears to be one of them.
From what I can tell, the company was giving away Nessus and trying to make money by selling value-added proprietary security console software. Their competitors started doing the same thing, but without the overhead cost of developing Nessus -- and their final solutions were cheaper as far as I can tell. I think what this really highlights is not a weakness in Open Source licensing, but rather the danger of hybrid open/proprietary business models, sometimes known as "widget frosting" business models. If they had first built up a community around Nessus to do most of the development work, this cost would have been negligable. But that community never materialized. After all, there must be a reason for community to exist -- what are members going to get out of it? Nobody wants to just do somebody else's work for free.
Does this mean there are cases where Open Source simply doesn't work? Not necessarily. Lets suppose that instead of producing a free commodity widget and then adding proprietary icing, you make all the software Open Source from Day 1. This eliminates your proprietary licensing income but also eliminates the incentive for competitors to sell their own, cheaper proprietary widget frosting. How do you pay for development? First, you try not to have to. Communities tend to build much faster around complete solutions than they do around widget raw materials. (As example, look at how RedHat has split off Fedora as it's own self-sufficient community.. this is partly why the company is now profitable.) Second, you commercialize the community, as feasible. Every significant contributing member is a potential independent contractor or maybe even future employee -- why not throw in some extra profit motive to guide and accelerate development? Customers have needs; the community you shepherd can meet them. It's up to you to facilitate the transactions. Skim a reasonable percentage off the top and you have a new revenue stream. (Food for thought: your customers may be part of the community) Third, add value through any means possible. This could mean support services, warrantees, embedded hardware, turn-key solutions, training classes, developer seminars, books and documentation, etc. All smart businesses continually experiment with new ways to make money, so this is an ongoing process. (This part is no different from a proprietary software shop.) Fourth, diversify and embrace other communities. You want to create a network effect with related Open Source software and you want a very open, friendly public reputation. Reputation is the foundation of branding and the combination drives sales. You did register your trademarks right?
Fifth, Profit!! (sorry, this is Slashdot after all.. but at least I gave real ideas for 1-4!)
I guess the remaining question is: Can software companies still use the traditional model of hiring all the developers, but still operate completely Open Source? Can writing software be their only competency? In general, I think history has shown that there is somewhat of an "impedence mismatch" with this approach. Open Source is geared towards community development. But that doesn't mean there can't be full-time developers where there is a large enough market for contracted development, with or without an intermediary.
But in that case, a person would simply be in violation of a contract, not Copyright.
Hmm.. I guess this is a question of whether it is a term for use or re-distribution. Most Open Source licenses, including GPLv2, don't say anything about use, only terms of allowed re-distribution. Any "services" clause would definitely be an attempt to limit use rights and could be a bad thing overall. I don't think that "software as a service" is widespread enough to warrant a controversial change in GPL. Those using this business model today are either too small to significantly fork Open Source code or are large enough (Google, etc.) to develop their own custom software instead.
there is already a very strong case to suggest that things like EULA's which do not require any sort of verbal or written consent of both parties in a case-by-case basis may be legally unenforceable.
I'd certainly be interested if you've got references. EULA terms of use are a double-edged sword if they are actually valid. On one hand, they are a potential (but dubious) means to fight software patents; on the other, they can be used to prevent reverse engineering or benchmarking of proprietary software, which would both otherwise be legal. And, of course, if EULA use terms are valid on software, what is to prevent their use on books or media? Indeed, we're better off without them being enforceable. Nevertheless, I don't see any reason why re-distribution terms would not be enforceable as they are directly related to the copyright itself.
As I've remarked elsewhere, this is not legally enforceable. Copyright only governs COPIES, not the services provided by those copies.
GPL and other EULAs are legal contracts. As such they can impose terms on the distribution and use of a copyrighted work that copyright itself does not require. (In order to have a valid license, you must either agree to them or negotiate with the author otherwise) How / what parts are legally enforceable is another matter of discussion. For example, we can be quite certain that the term "Jews may not use this software" would not legally enforceable because it is race discriminatory.
Slashdot Mirror
It's also the reason why the Java enterprise platform is getting ever more bloated and unwieldy, while most real people write stuff in PHP. .NET. The longer that Open Source developers waste time on their "re-invent the wheel geek toys," the further behind Java will fall for lack of due mindshare. Java is the premiere Open Source language today and it is the rallying point behind the most successful commercial Open Source efforts. As any language, Java still has flaws but they are being fixed rapidly. Open Source developers need to collectively realize this and get with the program. The alternative is a world where .NET is the only relevant platform for anything beyond forums, blogs and CMS tools.
The "Java enterprise" platform is ambiguous today, unless you're talking strictly of Sun J2EE components. If you find the J2EE components to be bloated and unwieldy, there are now plenty of lightweight alternatives. Fact is, Java has the best quality Open Source tools available today for developing business applications. If you think Ruby on Rails, Python, and PHP can do the same, you've never developed the type of software I'm talking about. The HTML web is not everything. A very large share of real-world business software does not align to single-threading and being tied synchronous to HTTP requests. Furthermore, rich-clients are absolutely essential in many cases. Of the three Java-alternative languages, Python is the only one with most of the core language features needed to compete in this arena. However, Python's development tools are still in their infancy, it is not as performant as Java, it's multi-platform client capabilities are limited, and the language specification itself is sloppy. (hence projects like PyPy which hope to remedy this)
The future of application software does not belong to lightweight scripted HTML-web software; it belongs to lightweight Semantic-web software that makes heavy use of XML web services, intelligent agents, and dynamic (repository-style) data stores, and smart/rich clients. Right now there are two platforms that can serve this need: Java and
I think the fact that KDE even exists means that Gnome shouldn't try to be more "advanced" (bloated).
KDE and GNOME have a nearly identical memory footprint and overhead. Given the fact that KDE provides more real-world functionaity for that same "resource bloat" which one has the better features/bloat ratio?
So people like the advanced options, the glimmer and the numerous widgets. Those people pick KDE. Some people just a basic, day-to-day desktop environment. Those people pick Gnome. The availability of both seems ideal to me.
There is absolutely no reason why people can't have both. That is the ultimate fallacy of the GNOME HCI philosophy. Include options and features, but hide them intelligently so they don't get in the way until needed. Create rich widgets but allow the user to customize them. Have glimmer but let it be easily turned off. This is the direction KDE4 is going and GNOME needs to follow if it is to remain relevant. I certainly hope it will, because other non-UI elements of GNOME are very promising.
It should also be noted that if one is to err in either direction, most people prefer excess features to excess simplicity if those features help them get their work done faster. That's why most people prefer KDE today. Neither is ideal, but it gets the job done.
But so what? The client side is rapidly being taken over by JavaScript/HTML and to a lesser extent, Flash.
In some ways, I wish this prognosis was as true to reality as the current hype suggests. The lightweight web makes everything neat and tidy since you don't have to worry about complex client-side platforms. (beyond a modern browser.. which will eventually mean Mozilla or Safari if IE continues to ignore W3C) Unfortunately, there are many things you still cannot do with JS/DOM/XHTML/etc. How important those shortcomings are has yet to be determined. I believe there is still a future in the myriad of W3C standards (especially with upcoming SVG, Canvas, CSS3, etc.), but I'm not sure how far these will extend beyond the document-centric web we know today.
One thing that could significantly change the picture would be a first-class integration of Java by the Mozilla project. This would provide a managed extension beyond the browser itself and the inherent limitations of JavaScript. (local hardware access, data caching, offline support, standalone web-managed apps, more efficient libraries for working with the DOM, etc.) This can all be done today with applets, Java Web Start, and Eclipse Rich Client Platform, but these are not bundled and integrated with Mozilla by default. If they were, Java / Mozilla / modern W3C standards would become an easily targetable platform for next generation web apps, while providing a seamless integration with today's web. It wouldn't be the end of the story, but it'd be a major step forward for open standards.
So I can understand why Ellison is trying to do what he is. as he sees that .NET has much synergy. More I look .Net, more I've started to wonder why it has been so overlooked.
.NET is anything but a heavy embrace of open source. (Apache/LGPL style) The only way to match the growing "synergy" of .NET is to work from the grassroots up and not look only at the "big iron" markets. While lucrative, they can not yield sufficient growth for the Java platform. .NET is not just an enterprise datacenter solution -- it's a unified desktop/server/mobile/web platform and as such it is very much "embrace and extend." The areas where Java is weakest are on the client side and this is where .NET has / will have it beat hands down unless drastic changes are made. Java Desktop was a good initiative but it hasn't gone nearly far enough. At this point, I'd have to put my bets on open source Java projects as the true saviors of the language. (even as pioneers of fresh approaches not designed by committee.. think EJB2 -> Spring/Hibernate -> EJB3) This is not to say Sun and Oracle lack a significant market in the high-end, but theirs is also a niche compared to the whole landscape .NET is going after. If they don't expand their horizons and embrace open source in the low/mid-range markets, the high-end niche could shrink as .NET marches forward on both hype and shiny new technologies.
.NET is going with UI technology. Swing/SWT/JSF came too late and are inadequate in comparison to upcoming .NET XAML/WPF. Nevertheless, XAML is not perfect and there is still an opportunity to leap-frog ahead of it before it gains too much traction post-Vista-launch. Now would be the perfect time to tear down the popular image that Java is good for the server but awful for client-side.
What is truly mind boggling is the apparent conclusion that Java's correct "answer" to
If anyone from Sun happens to be reading this, please don't overlook where
Sort of like marrying Java and .NET again, but making it easy to port from any major Unix toolkit: GTK, QT, Motif (uughgh), TCL, and especially web-friendly languages.
.NET is a single platform that runs any language
Well put. I'm glad somebody brought this up. I believe it is imperative that the Open Source world begin to refactor into managed languages -- whether through Mono/CLR, an enhanced JVM with multi-language support, or something completely original (PyPy, etc.). It's this simple: We need to create a more cohesive "platform" for our developers and the best way to start is a unified object model. Imagine if Python, PHP, Smalltalk, and Ruby developers could efficiently re-use the wealth of professional-quality Open Source Java software that now exists. Imagine if Mozilla XPCOM could safely hook into standard "desktop" components to access local hardware. Imagine if Qt and GTK apps were no longer separated by the DCOM vs. CORBA disparity. (and hey, maybe we can someday agree on a single DE project instead of having both KDE and GNOME)
Java is a single language that runs on any platform
What OSS really needs is a meta-platform that standardizes support for any language on any platform.
Is open source just a substitute for the lack of innovation in closed source software?
.NET platform. (In case you somehow haven't noticed, .NET is a replacement for the entire "legacy" Windows platform, from the ground up..) Both Java and .NET are vying for position in the post-desktop era. (data-centric/service-oriented architecture) Open Source from the beginning? Yes, on the Java side. The most relevant, most innovative Java technologies are all Open Source today. Unfortunately, many people have become distracted by alternative technologies that won't matter when the dust settles. The OSS community needs to get behind Java en-masse to stay on the cutting edge and compete effectively with .NET / Vista. Don't get me wrong.. Ruby and Python have their place, but they are accessories to the larger, dominant platforms that will drive the majority of future computing.
That's an awful broad statement. There is constant innovation in both open and closed source software. In some cases, yes, stagnation of closed software has been a breeding ground for open alternatives.
All these applications that are open source are in fact stuff we all know how to implement, it's just a matter of time and effort. We have an operating system, a database, an office suite nothing really new, they were bound to get open sourced.
It begs this question: Why are we trying to compete in the areas where innovation has already dried up? Today, few people are excited about new office suites, regardless of the source. Furthermore, MS already has an unshakable monopoly in yesterday's desktop-centric computing paradigm. But who cares?! The proper catalyst for change is radical innovation away from the status quo. (ie. data-centric, web-enabled, platform-neutral architecture)
It's quite amazing that these type of applications are still making money in their closed source incarnation after all this years.
It's not that amazing -- they're simply more polished than the Free alternatives. In the absence of a remarkably better alternative, most people just stick with what they are comfortable with. (and have already paid for) Also, there's an enormous amount of 3rd party business software that relies upon Windows and Office. Like I said, the desktop battle was lost years ago.. you might even say as far back as the death of OS/2. But again, why worry? The desktop is not the future anyhow.
But what about new stuff? Will someone with a really innovative idea open source it from the beginning? And even worse: will we notice?
It's already happening! Right now, the largest and most important battle of innovation is between Java and the
Star Trek is well behind the known state of the art *today*.
:)
Well, I'm really not much of a trekkie, so that may be true. I'm only basing on the few movies and DS9 episodes I've watched.
* ubiquitous access is a function of the capabilities and costs of technology, not any design issues at all.
True, but design factors can influence the market demand for ubiquitous access. Also, "ubiquitous access" refers to your personal data, not just internet connectivity.
* people today already have seamless interoperability if they stick with Apple. So broken systems are broken, yawn.
Seamless interoperability, by my definition, means that it doesn't matter whether you stick to one vendor and that the true "platform" is the communication protocols and languages that everyone agrees to use. Seamless interoperability extends far beyond the software on your personal desktop or laptop. Though better than most, even Apple's desktop platform and associated software reaches nowhere near the level of interoperability possible.
* centralized data stores are evil, what we should aim for is a secure logical fabric on top of a highly distributed tech layer. Somewhat like Ameoba aimed for but much better.
By "evil" I presume you mean "bad for privacy," but this is a non-issue if you control your own personal data repository on your own server in your own basement. To fully reap the benefits of ubiquitous internet access, all your data must be somewhat centralized. (For a large business, this centralization may, of course, be logical not physical) So my take would be "centralize the data, distribute the processing."
* highly associative / semantically rich? You invented this. The only evidence Star Trek has of it is its AI functions. Star Trek doesn't provide it as a model separate from AI, although it's certainly desirable and feasible.
Yeah, it's a precursor to practical AI, but perhaps not a direct observance. Then again, I'd guess you could find an episode where Picard asks the computer if alien race A has any relations with alien race B. Minus the voice recognition, that wouldn't really require AI.
* diverse client hardware? You invented this too.
Well, "client hardware" in the sense of tricorders, bridge and engineering consoles, communicators, the holodeck, and those tablet devices that appeared in modern series.
* dynamic user interfaces? Again, something you invented, though there it's not even clear what you mean, nevermind whether it's a good idea.
Dynamic as in "what you see is what you want/need" rather than static GUIs that somebody designed with specific use cases in mind. (not that there isn't a place for both..)
Regarding XML, the flaw in your reasoning is your assumption that XML has valid uses. XML is a truly horrific way of marshalling and distributing even textual data, even so-called documents.
I'm always open to new ideas, but what currently exists to replace it? With the amount investment into XML family tools at this point and the amount of unity XML related projects are bringing, a successor would have to be something dramatically better to be worth throwing everything out and starting over.
But to see that you have to think of documents as they *could* be (eg, think Xanadu) and not the crap we're currently dealing with which HTML created and XML aims to perpetuate.
I fully agree that today's paper-centric documents and HTML are junk. What's especially cool to me about Xanadu is that, before discovering it, I had pretty much come up with the same ideas independently, out of frustration with the current state of the art of the web. However, some of the ideas I've had go beyond "documents" so I think the "Xanadu model," though perfectly valid, is only a subset of the future direction of the web and computing in general. With that in mind, however, I don't see any way that XML will limit the industry fr
The desktop metaphor aka the "GUI" aka the PUI aka the Xerox PARC User Interface invented for the Alto, is 25 years old, not 10.
I know that. I was referring to how long progress has been *held back* due to stagnation. The desktop metaphor was a reasonable compromise while hardware capabilities improved. Today, it has lived past its usefulness.
Also, the so-called Star Trek interface you paint is really full-fledged AI and so is stupid as a goal of serious interface design.
I wasn't proposing the "Star Trek interface." I was pointing to some very general concepts surrounding the computer technology in Star Trek. Indeed, AI-centric interfaces are probably a few decades off. Regardless, many of the other concepts we can begin to aim for today: ubiquitous access, seamless interoperability, centralized data stores which are highly-associative / semantically-rich, diverse client hardware, and dynamic user interfaces.
Finally, XML is a step backwards. A HUGE step backwards. What was good for typesetting documents is really horrific for arbitrary objects.
XML isn't perfect and isn't a panacea, but I don't call any tool with valid uses a step backwards. I furthermore do not agree with those who claim that XML is only good for typesetting. Who said anything about objects? The purpose of XML is to separate code from data, and the family of XML tools that exist within this problem domain are very useful. XML is not a language optimized for heavy data processing, but it is generally better than s-expressions for document processing, arbitrary textual data markup, and RPC. XML is intended for marshalling textual data, not storing or distributing objects or binary data. Maybe someday we'll invent a language that does both perfectly, but that language does not currently exist and I am aware of no effort underway to create it. The question becomes: do we really need to marry code with our data interchange? Perhaps, yes, within a closed system. However, what if we developed a rich enough standardized taxonomy of data markup that it was unnecessary to ever embed code and logic within our exchanged data. As example, look at MathML. Do we need to include code for calculating a square root within marked-up data that represents a square root? Of course not -- that is the responsibility of software that operates upon data defined in the MathML XML namespace. So, in the end, it really comes back to all data being semantically rich enough that machines can "understand" it and do useful things from there.
First off, I just want to affirm this overall train of thought. The traditional, clumsy desktop metaphors have stagnated progress in popular computing for at least the last 10 years. It's quite time we break cleanly away from them, not just add 3D gimmicks to the mix as if this will fix the underlying limitations! I was going to post a similar commentary last night but ran out of time. Too bad I don't have mod points and /. only goes up to +5...
:)
Live with a program like Spotlight for a while, and you start to find yourself bypassing the Finder and Desktop and folders altogether. What's needed is a better way to communicate (voice), and a system smart enough to know who Bob is, who Dave is, what a claims letter is, understands "last week" as a variable period, and can put it all together.
The first step is making all data semantically rich and uniformly accessible. Absolutely everything else follows. Before we can build advanced user interfaces, whether voice or 3D enhanced or whatever else, we need all of our data to be in a form that software can reasonably be trained to "understand." This in itself will be a huge endeavor and may well take the next 10-20 years to accomplish, given the vast quantity of low-context data that now exists. The current move toward non-proprietary XML formats is a tiny step in the right direction, but at least it's a step.
Yeah, it's the Star Trek interface.
It sounds silly but that really is a good comparison. It also brings up another huge point. In Star Trek, data is stored and processed somewhat centrally but is accessible anywhere using a multitude of devices and user interfaces -- from tricorders to tablets to bridge consoles to the holodeck. You don't see anyone aboard the Enterprise using a Desktop PC do you?!
Data is data. A "document" is really just an abstraction and collection of multiple piece of data into some logical and typically linear form -- most often for printing, etc. The first step is making all data semantic and machine understandable. Beyond that, we can decide if we even still need "documents." I, for one, would prefer a world where data organization and UI design follows the "what you see is what you want" principle.
Service-oriented software is the future but basic HCI guidelines are still relevant.
I absolutely agree, but I think new HCI guidelines will be required for new UI approaches. As example, most users will eventually have little or no contact with files and directories. As data becomes more semantically rich and interconnected, these will quickly become outdated concepts. Even today, think of how people use iTunes/Amarok vs. how they used to use Winamp/XMMS. Type managers are only the beginning.
Besides, until everyone has access to a 2Mbit broadband and runs their office or spreadsheet off of Google's or Microsoft's server, the desktop is still here to stay.
That's certain an issue. However, what's to say that traditional word processors and spreadsheets themselves are here to stay and that their rich-web successors will require the same bandwidth? I don't propose to have an immediate solution, but it certainly can be noted that popular office suite software does not produce semantically rich data. Sure, you can index documents for fast searching, but the machine cannot truly understand the contents or provide derivative results. What if spreadsheets were replaced by super-flexible object-oriented databases where the user could define the data types and methods on the fly. Such tools would be highly usable both at home and in the workplace to complement rigid enterprise databases. (obviously you'd still do accounting software, etc. via the latter!) What if word processors and DTP tools were replaced by document production systems that very cleanly separated content, style, and formatting? After all, I care most about the content, not paper formats. If I want to write a letter on my PDA, I don't care about how it formats onto Letter-sized paper for the time being. (and hey, maybe I run a paperless office anyhow!) These sorts of concepts offer to replace todays ultra-complex software with elegant simplicity and yet more power all the while.
The number of companies deploying open source technologies in their production infrastructures, embedding Linux in their hardware and porting their software in order to save their customers' hardware budget, these are a better barometer of the movement's success than the attempts of the aforementioned companies to make money off of something which is intrinsically free.
I agree. Open Source is a production method (like the assembly line) not a business model. There are both successful and unsuccessful companies that use the assembly line, or Open Source, as one factor of implementing their business model. (And many who use Open Source successfully are not even software companies!) With any new means of production, it takes awhile to figure out how to use the it beneficially. When the assembly line concept first hit the mainstream at the beginning of the 19th century, there were many perceived drawbacks. Products were inferior to the quality of individually hand-crafted goods, workers were subjected to unpleasant and often dangerous conditions, and maintaining tight engineering tolerances was difficult (such that parts would fit together at the end!). Today, Open Source faces many of the same types of challenges -- proper code modularity for easy sharing and re-use, effective leadership structure within large projects, clear communication and equitable division of labor, license compatibility issues, etc.
I personally believe that we'll see Open Source truly take off once IT departments stop viewing it as a free lunch (where available) and start treating it as an efficient acquisition process. When you consider how much business software is still written in-house or via contract, it stands reason that there is far more wheel-reinventing going on than necessary.
BTW, regarding OSS success stories, don't forget Java.. If you go to any Java User Group or professional conference, you'll find almost everyone talking about using Open Source tools. It's not because they have a political agenda; they've just learned to harnessed a better/faster/easier way to do the same old job.
HCI guidelines for traditional file-centric desktop interfaces came far to late to be relevant in the mainstream, which is 90-95% Windows. The whole "desktop computing" paradigm is fully played out and the future now belongs to service-oriented software, which is largely platform and UI client agnostic. We're about to be faced by a completely new set of methods for HCI, such as "what you see is what you want" and "pervasive computing." This is where the Open Source community should be focusing it's efforts -- not fighting over who has the best implementation of yesterday's stale concepts of computing. Most people today seem to prefer KDE because it has the features they are used to, yet most people spend an increasing amount of time using software through the web. KDE 4 "Plasma" is shaping up to be the best of both worlds with respect to full functionality that is elegantly managed, yet this polish is hardly relevant to browser based applications. From a developer perspective, Qt is far more attractive than Gtk, but even that doesn't matter very much because most of tomorrow's software will be written in a combination of scripting and managed-code (ex. Java, C#) languages, rather than C or C++. We need to just call it a day and move on to better things. It has become my opinion that neither KDE nor GNOME is enormously important to the future of Linux or Open Source. Continuing to maintain both is a terrible waste of limited development resources.
Indeed, the lessons learnable from the present failure of OO.org also point toward what makes Open Source work.. and the direction Open Source projects need to head in the future.
What OpenOffice.org teaches us foremost (though we've really known this for years) is that Open Source does not work very well for "big software" -- software that is monolithic and difficult for new developers to wrangle. If we could somehow plot modularity vs. success for all Open Source software, there would little doubt be a very strong correlation. Everything about "big software" drives away community. (and by "community" I mean both commercial and freelance/hobby developers)
Enter tomorrow's web applications. (but first get "HTML" out of your mind!) Exit today's desktop/client-centric software and replace it with modular, loosely-coupled, lightweight web software. Forget about designing software around the UI. Instead, think in terms of services and even intellegent software "agents" that automatically work together to accomplish what the user desires. Best of all, most of this software will be Open Source, largely because it will be so easy for anyone to develop their own components to add to the mix. Each component developer can aim for perfection and elegance within their component's limited domain of functionality. Welcome to the end of "big software" and perhaps the beginning of a true Open Source revolution. Unix brought elegance to operating systems with simplifying concepts like "everything is a file" and philosophies like "do what you do well and nothing else." Likewise, the web, as a platform, will bring elegance to how we build large, complicated software systems.
Those working on OO.org would be wise to immediately start porting it to Java, discarding old, crufty code as they go. Immediate benefits would include proper operation on all platforms and renewed interest from outside developers. The long term benefit would be re-usable components for the coming age of true web applications. An excellent place to start would be the OO.org import/export filters, as these would be immensely useful to web developers today.
This was probably due to proficious wining and dining on the part of MS.
More likely it was due to the fact that OpenOffice.org, while young and promising, still sucks terribly for real-world daily usage. Your home city probably thought it could simply get a "free lunch" by using it, rather than recognizing that it is still a needy, infantile project. OpenOffice.org is at the stage where early adopters *MUST* become co-developers for it to succeed. (both on a grand scale and for the success of their own deployments)
Let this be a lesson to any of you advocates and political types out there. OpenOffice.org is Free Software, but it's not free quite yet, in the sense of "install and forget about." For the sake of effective advocacy, don't confuse people and don't stretch the facts! It's not yet the highly-polished, feature-rich, hastle-free software that Office is. If you're going to promote OpenOffice.org, make sure that people know that they will have to invest fairly heavily in making it work properly, including contributions to its development community. (read: paying developers to fix the many show-stopper problems you'll encounter with it)
Rather than spending money on legislators, spending money on development, fostering open source via an express government preference will probably provide all the help open source needs to break the MS network effect, and therefore the monopoly, restoring the market to a healthy state.
Indeed. The author's proposal in the original paper is far too complicated. The government is going to spend money on aquiring the software it needs regardless. All it needs to do is contract with Open Source developers / consulting firms / solution providers / etc. instead of buying proprietary licenses. Make this a required preference for all government IT and the problem will otherwise solve itself through true free market competition. Open Source enterprise operates as a free market for development and support labor. It doesn't need government corporations or creative vouchers or any other socialist production means / incentives. Why replace copyright/patent with something equally artificial and potentially almost as inefficient? Sure, let the government spend $2bil/year for a few years on better meeting its own software needs, but channel this money into private firms and make them compete for contracts like everyone else! Government organizations generally have an awful track record for efficient production and innovation.
Once there are competitors in a market, the government actors should step back.
All that is needed to help restore competition is a short boost in the form of re-directed spending. After that, the free market can continue without intervention. It'll happen regardless, even if the government doesn't get involved, but there's a good case for some minor policy tweaking in order to bring the benefits sooner.
There is certainly a case for standardizing upon a single DE for corporate workstations. In this environment, the most important apps are: Web browser, Office suite, Java/.NET business apps (which are probably through the web, but some may have client components). From this perspective, it doesn't matter so much which DE is used. Both are basically just a way to launch the 3-4 apps used daily and manage the open windows. Compared to KDE, GNOME is a barebones DE, so it makes sense to use it when you don't want to hastle with users playing around with settings and screwing up their workspace. (I've found it's also great for elementary school students because it's so incredibly simple and intuitive.) But simplicity is simultaneously GNOME's strength and weakness. What GNOME really needs is an "advanced mode" that gives the power users more control and more options. This is especially true of the Nautilus file manager, which is utilitarian enough to drive experienced users crazy! :) (not to mention the kioparts integration with Konqueror is downright useful.. fish:// anyone?)
Because their desktop goals are corporate-minded, it's no surprise that Novell is going with GNOME. But what about personal desktops and applications? This is where KDE really shines because of the apps available. K3b (CD/DVD writing), Kopete (IM), Digikam (digital camera and album manager), and Amarok (iTunes-style media) are so far ahead of their GNOME "competitors" that DE choice hardly requires thought. Yes, you can run all these apps under GNOME, but then you miss out on some of the desktop integration and you double-up on memory usage.
It will be interesting to see where KDE 4 goes, with its focus on simplification and HCI guidelines.. perhaps it'll finally gain more corporate desktop interest in the US.
I have been impressed with the LED lights over florescent or incandescent. The subdued lighting is fine with me and the energy consumption / bulb longevity is the best part.
White LEDs are twice as efficient as most incandescents. However, compact fluorescents (CFLs) are twice as efficient as white LEDs. LEDs last 10x longer than CFL's, but they also cost several times what an equivalent number of CFLs would cost over the same lifetime. As a result, White LEDs are simply not economical at this time. They need to double in efficiency and quarter in price before they will compete head-on with CFLs. Right now, white LEDs are mostly useful for small tasks, such as flashlights, reading lights, nightlights, etc.
Go look at PEAR and the PHP manual index and then tell people PHP doesn't have a platform offering all those.
I do both PHP and Java development. Neither PEAR nor built-in PHP functions are a valid comparison to the extensibility of Java. Java itself gives developers a stable (if utilitarian) base and a standard namespace upon which can be cleanly extended as far as needed. PHP has no namespace and its base is slightly re-defined with every major release. PHP has its roots as a procedural scripting language for CGI. Java has its roots as an Object Oriented managed-bytecode general purpose language. They were intended to serve completely different purposes and it is a disservice to the programming world to cast them as equals. PHP is great for the public web, where rapid development and low barrier to entry outweighs other factors. Java is the best tool for the job when more formality is needed, such as complex business applications. Java can also do things that PHP simply cannot, by limitations of PHP's architecture. Perhaps most importantly, Java can fork off threads to do background tasks which are not related to HTTP requests. While this capability is nearly useless on the public web, it is an absolute requirement for most types of business applications.
The realist will note that PHP and Java are both popular in the areas where they are currently the best tool for the job. PHP has a large selection of software and tools useful for working with the public web. Java has a large selection of software, tools and frameworks useful for creating business, scientific, and otherwise data-intensive software. Of course, there is an increasing amount of overlap, mostly on the Java side. Java is becoming simpler to develop for and is gaining more agility in the light-weight arenas. For PHP to overlap into traditional Java territory, it will need a significant overhaul of its architecture. I don't see any evidence of this happening in the near future, though I suppose it can't be ruled out.
No, a Unix admin truly does *not* want to migrate to windows.
This is all well and good for us Unix admins. But for Unix to continue growing, we need to make Windows admins want to migrate to Unix. Unless all the basic administrative tasks are possible through a GUI, there's no migration path. Scripting comes later, after new admins are familiar with the landscape and after know they have a GUI to fall back on if they get confused.
There has been significant progress in the last 5 years in this area, but it's still not enough to make a dent in Windows Server marketshare for SOHO and medium-size businesses, where MCSE's are a dime a dozen.
Of course the real solution is not Unix but rather intranet rich-web Java applications.. Unix is just the cheapest way to get there.
I'd be more concerned that if it were GPL'd that it couldn't use some or all of the above.
You're thinking about it backwards, bringing up a common misconception. A GPL program can link to non-GPL (or even proprietary) libraries. There's no requirement that everything be GPL. The case you're thinking of is the other way around. In the case of a GPL library, only code under a GPL-compatible license can link to it. This, of course, can be a major impediment to Open Source developers using other licenses, and is the reason why most Open Source libraries are rightly LGPL. LGPL'ed code allows software of any license, even proprietary, to link to it. But LGPL is different than BSD because it still prevents proprietary forks of the linked code. LGPL is the "best of both worlds" Open Source license in many cases.
And frankly the most important question this class should address is - WHY OSS?
:) GPL is also the best license from a business perspective because it prevents competitors from creating proprietary forks of end-user software. LGPL is the best license from a re-usability perspective, such as for libraries. LGPL code is linkable with code of all other licenses but still protects the covered code from proprietary forks.
Absolutely! If people can't answer this question properly, they won't be able to run successful Open Source projects or contribute most effectively to existing ones. Don't forget the biggies:
- Motivations for OSS. Make sure you provide plenty of business cases and not just the standard fare philosophical / idealist fluff. Open Source is like the invention of the assembly line; it's a new way of doing the same thing, only more efficiently. In the end, it still comes down to making a living, whether directly or indirectly, while doing what you love. We need more Open Source entrepreneurs and not just more hobbyists.
- What characteristics do successful Open Source projects share? ex.) respected and trustworthy leadership, flexibility / openness to change, easy extensibility, low barriers to outside contributions, friendly networking with existing or related projects, well documented and highly modular code, etc.
- The importance of open standards. Don't reinvent the wheel unless it really needs to be done. Aim for compatibility and seek out partner projects in embracing and enhancing standards used.
- The benefits of using existing Open Source licenses. ie.) Don't create an island! Incompatible licenses spoil purpose of Open Source and limit the possibilities of code-sharing both into and out of a project. GPL and LGPL are the most popular licenses for a good reason: they're the most popular licenses.
While I love the GPL, it's not for everything. There are some cases where it's just not profitable to give away your main product. This appears to be one of them.
From what I can tell, the company was giving away Nessus and trying to make money by selling value-added proprietary security console software. Their competitors started doing the same thing, but without the overhead cost of developing Nessus -- and their final solutions were cheaper as far as I can tell. I think what this really highlights is not a weakness in Open Source licensing, but rather the danger of hybrid open/proprietary business models, sometimes known as "widget frosting" business models. If they had first built up a community around Nessus to do most of the development work, this cost would have been negligable. But that community never materialized. After all, there must be a reason for community to exist -- what are members going to get out of it? Nobody wants to just do somebody else's work for free.
Does this mean there are cases where Open Source simply doesn't work? Not necessarily. Lets suppose that instead of producing a free commodity widget and then adding proprietary icing, you make all the software Open Source from Day 1. This eliminates your proprietary licensing income but also eliminates the incentive for competitors to sell their own, cheaper proprietary widget frosting. How do you pay for development? First, you try not to have to. Communities tend to build much faster around complete solutions than they do around widget raw materials. (As example, look at how RedHat has split off Fedora as it's own self-sufficient community.. this is partly why the company is now profitable.) Second, you commercialize the community, as feasible. Every significant contributing member is a potential independent contractor or maybe even future employee -- why not throw in some extra profit motive to guide and accelerate development? Customers have needs; the community you shepherd can meet them. It's up to you to facilitate the transactions. Skim a reasonable percentage off the top and you have a new revenue stream. (Food for thought: your customers may be part of the community) Third, add value through any means possible. This could mean support services, warrantees, embedded hardware, turn-key solutions, training classes, developer seminars, books and documentation, etc. All smart businesses continually experiment with new ways to make money, so this is an ongoing process. (This part is no different from a proprietary software shop.) Fourth, diversify and embrace other communities. You want to create a network effect with related Open Source software and you want a very open, friendly public reputation. Reputation is the foundation of branding and the combination drives sales. You did register your trademarks right?
Fifth, Profit!! (sorry, this is Slashdot after all.. but at least I gave real ideas for 1-4!)
I guess the remaining question is: Can software companies still use the traditional model of hiring all the developers, but still operate completely Open Source? Can writing software be their only competency? In general, I think history has shown that there is somewhat of an "impedence mismatch" with this approach. Open Source is geared towards community development. But that doesn't mean there can't be full-time developers where there is a large enough market for contracted development, with or without an intermediary.
But in that case, a person would simply be in violation of a contract, not Copyright.
Hmm.. I guess this is a question of whether it is a term for use or re-distribution. Most Open Source licenses, including GPLv2, don't say anything about use, only terms of allowed re-distribution. Any "services" clause would definitely be an attempt to limit use rights and could be a bad thing overall. I don't think that "software as a service" is widespread enough to warrant a controversial change in GPL. Those using this business model today are either too small to significantly fork Open Source code or are large enough (Google, etc.) to develop their own custom software instead.
there is already a very strong case to suggest that things like EULA's which do not require any sort of verbal or written consent of both parties in a case-by-case basis may be legally unenforceable.
I'd certainly be interested if you've got references. EULA terms of use are a double-edged sword if they are actually valid. On one hand, they are a potential (but dubious) means to fight software patents; on the other, they can be used to prevent reverse engineering or benchmarking of proprietary software, which would both otherwise be legal. And, of course, if EULA use terms are valid on software, what is to prevent their use on books or media? Indeed, we're better off without them being enforceable. Nevertheless, I don't see any reason why re-distribution terms would not be enforceable as they are directly related to the copyright itself.
As I've remarked elsewhere, this is not legally enforceable. Copyright only governs COPIES, not the services provided by those copies.
GPL and other EULAs are legal contracts. As such they can impose terms on the distribution and use of a copyrighted work that copyright itself does not require. (In order to have a valid license, you must either agree to them or negotiate with the author otherwise) How / what parts are legally enforceable is another matter of discussion. For example, we can be quite certain that the term "Jews may not use this software" would not legally enforceable because it is race discriminatory.