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
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Validate an E-Mail Address with PHP, the Right Way
- Technical Support Rep
- Senior Perl Developer
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?