Jabber Asks the Tough Question
Jabber is hot, but it's still not quite setting the world on fire. When will it happen? And how will open source developers make it happen?
What made the Net such a big hit--so big that it has become the universal infrastructure for both computing and communications--is its means, not its ends. Its how you serve, not what.
The Web and mail are just two of the Internet's built-in services. If we go back and look at what we expected from a UNIX system or a Novell LAN fifteen years ago, there were other services we don't yet associate with the Net, like file, management, print, security and directory. Some of those don't exactly map to the Net (or are too problematic on political or technical grounds), but it's interesting to bring them up because they help us understand some of the other stuff that should be fundamental Internet services, but aren't. Take instant messaging (IM), for example, or presence, which makes instant messaging a heck of a lot more useful.
Today most people understand instant messaging almost entirely in terms provided by AOL, Microsoft and Yahoo. As with on-line services and operating systems, closed IM systems became familiar to the general public long before the open ones. In terms of architecture and control, AOL's, Microsoft's and Yahoo's instant messaging systems are as closed and non-interoperable as Prodigy, Compuserve and AOL were back in the nineties.
In other words, AOL, Microsoft and Yahoo all want to keep private something that should be no less public than mail and web services. All of those companies' IM systems use the Internet and offer free clients, but they offer no internet service anybody can build on.
It's an interesting irony. Microsoft will gladly sell you web and mail servers, but they offer nothing of the sort for IM. By insisting on owning the only IM servers that make sense to their clients, they are doing nothing to move the world any closer to real internet-based IM. Neither is AOL, which works exactly the same way.
So what choice do we have if we want to make IM a standard internet service? And what about presence, which adds enormous value to IM?
In a word, Jabber. I've written about Jabber before (see here and here), and there are at least 220,000 documents that mention Jabber on the Web. That's a lot, but not enough to make Jabber a household word, even for geeks.
I'm also not working strictly as an editor when I write about Jabber because I'm on Jabber Inc.'s open board, along with Eric Raymond, Tim O'Reilly and James Barry. So, in the spirit of that board's title and Jabber's open-source nature, I want to bring up the challenge of ubiquitizing something that clearly we all need.
How does that happen? What are the best relationships between open-source movements and commercial software and service companies? In the past we've mostly talked about licensing. That's important, but it bears about the same relationship to software development and adoption as marriage licenses do to happy and growing families. Economics are involved too. Who makes money with what and gets rewarded for what?
Andre Durand is the founder of Jabber Inc. and a member of the company's management team. Recently he vetted his thoughts about compensating open source developers, among other issues, in a piece called Commercially OPEN for business. In that piece he reviews some of the early decisions made in forming the company, and suggests this:
In the never ending pursuit to perfect a replicable formula for success, I believe there exists a roadmap for commercial software companies to spawn open source projects from the onset and attract the same voluntary and self-selected contributions that exist in open source projects today, but with a system of monetary remuneration which is considered neither mercenary nor evil, but a required component of a well greased machine.
That map doesn't really exist, or we could point to it. What Andre is suggesting, however, is something that was dropped from consideration at the company's beginnings (which are so recent that they're still going on)--which is rewarding open source contributors financially.
There's a larger context here. Traditional open-source companies like VA Linux, Caldera and CollabNet are starting to sell closed-source products as a matter of business strategy. They are all also survivors of a dot-com boom and crash that invites us to rethink the overfunded assumptions we had about making money with Linux while the sun shined. "How do you make money with open source?" is still a wide-open question.
The question here isn't just about companies. It's about individual programmers who contribute to helping open-source projects like Jabber make it. Should they get rewarded financially for their otherwise voluntary efforts, above and beyond the systems (such as they are) that we have today? How?
Here's another way of asking the question. What are the ways open-source developers can scratch a customer's itch? And in doing so, what can open-source developers bring to the larger bazaar we call a marketplace? I think it's a lot, and we've barely started.
Doc Searls is Senior Editor at Linux Journal.
Doc Searls is Senior Editor of Linux Journal
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide