The uneven history of collaboration

20_Options_for_Real-Time_Collaboration_ToolsThose of you who have been loyal readers of my work over the years will recognize a consistent theme where I talk about how we use computers to collaborate on projects. I came to work this morning to hear several complaints via IM from a friend who has an evil co-worker that was berating her about her ideas. “What a way to say good morning,” said my friend to me. That got me thinking.

We have come a long way on the route towards better collaboration, with fancier tools, higher-speed networks, and near ubiquitous Internet access, but the people part of the equation is still somewhat lacking. Let’s take a trip down memory lane and I’ll point out some of the things that I have seen over the years.

My most recent column on collaboration describes the British crypto program Colossus and how thousands of people worked over several years to decode German dispatches during World War II. That was collaboration with a capital C. The equipment was barely functional, and the workflows to get the job done were brutally complex. But it worked, because everyone pulled together and did their part and respected the individual roles that each had to play. So this is noteworthy because of the time period and the level of actual collaboration that took place.

But Colossus happened with everyone working in very close quarters, dictated by the wartime requirements and how the machine was constructed. In the modern era, we are more concerned about incorporating collaboration when we have distributed work teams. I had to deal with this early on, when in 1990 I founded Network Computing magazine and we hired the best editors from all around the country. Back then it was a challenge, especially as we had to build trust and help foster a sense of purpose with people that had never met face-to-face.

This is still an issue today. In this recent post for WPCurve, Don Virgillito talks about what he has seen from the best collaborative teams that were distributed geographically. He suggests that you should “consider existing remote work experience as an essential skill.” And you’ll also “have to grow as a team to continue being a team, which would involve meetings, team training, retreats to boost morale, and real-life meetings when possible to build long lasting relationships.” That is exactly what we did back in the early 1990s, and it worked so well that the magazine continued using some of these practices long after I left its helm.

As far back as 2008, I was writing about this people side of collaboration:

So, as PC processors get faster, disks get bigger, and our social networks get larger, we still don’t have the perfect collaboration solution. We still think of the data on our hard disks as our own, not our employer’s. Sharing is still for sissies. Until that attitude changes, the headphones will stay firmly stuck in our ears, blocking out the rest of the world around us.

How many of us are still stuck in a similar situation? And as more “bullpen” style office configurations are created, this only worsens the scenario.

If we look closer at the people relationships than the technology, we’ll see a lot more insights into how collaboration happens. That was the subject of this post from 2009 where a survey of collaboration habits found a key staffer way down the food chain was the glue that held things together. He worked closely with all the different stakeholders and pushed for better collaboration between departments, because the bosses of each department didn’t know how to talk to each other. Another part of this survey found that companies should focus on their least communicative employees: if they can bring them up even just slightly at being better communicators they will greatly improve productivity.

Let’s turn to the tools used for collaboration.

In 1990, we didn’t have the Internet, and setting up email meant running our own system that dialed into each of our remote offices to route messages around. IM and cell phones didn’t exist yet, so remote editors had to find payphones and RJ11 jacks for their modems. We spent a lot of time sending large graphics files around on our network because there wasn’t any other way to share them. In many ways, it was the dark ages of collaboration tools.

But as email became successful, it also brought overuse, something that we still wrestle with today. By 2009 we were focused more on cutting down on back-and-forth emails and improving remote access. In an article that I wrote for an IT publication then I talked about the various tools that were available, some of which are still being used today. (A chart that I prepared for my website is woefully outdated, but will give you a picture of what things I was looking at.)

And in this story that I wrote for Baseline magazine in 2011, I looked at other ways that collaboration happens, using screen sharing, document management and workflow management tools. For example at one after-market auto parts chain, installers can get the schematics of the car they are working on at the moment they need them, thanks to a collaboration tool that integrates into their workflow.

Since then, we have all sorts of fancy stuff to use. A recent review last year for Computerworld looks at three of them: Glip, Slingshot, and Flow. While none of the three are perfect, we have come a long way since the early days pre-Web. And if you click on that link above for the WPCurve article, you will see dozens of other suggestions of what the latest startups use for their collaboration technologies.

So yes, the history of collaboration has been one of fits and starts, making some of the same mistakes over again and not really considering the historical context. I hope you find the journey as interesting as I have.

Avoiding the IT rust belt

Living in the Midwest, I consider what life is like in the Rust Belt, where aging manufacturing companies have come and gone. When I first moved to St. Louis, all three of the domestic car makers had plants here: now we are down to just one of them. I was talking to a friend of mine who mentioned that she is seeing something similar: some enterprises are still stuck with their “rust belt” version of IT services and have yet to make their move. Whether their businesses will suffer the same fate as some of the manufacturing industry is hard to say.

So I thought I would talk to another friend of mine, who is the IT director at a Midwest steel mill and get his perspective. He has a small IT shop of six people but they are doing some interesting things to keep their plant competitive. “We can’t really innovate on our product line, but we have to do things from an IT perspective to serve our customers better and become more productive and cost effective,” he told me. Here is how he does it:

Get rid of aging equipment. While he still has a few Windows XP machines around, most of his IT gear is the latest and greatest. He is in the process of upgrading his Cisco network infrastructure, for example. Some of his most ancient computers that run his plant are connected to logic controllers, just because they don’t require much horsepower and they are on the plant floor where the environment is brutal. “Eventually, we will replace these when they break or migrate one of our older office PCs to there.”

Beware of legacy systems. “We were able to leapfrog other steel companies with our technology, because when we started the company we didn’t nave many legacy systems.” Now he has three developers who build custom apps that are used for handling their steel inventory and steel operations, along with a customer portal. For example, his team built a custom automated scheduling system when one of the two people in that department retired. Now it takes the remaining staffer just part of the day to do the scheduling, and they have cut wasted product and improved their steel yields tremendously, saving them money too.

Make use of the cloud and virtualization where it makes sense. “When I started with the company, we had a single PC server that was running everything. Now we have virtual servers and are looking at converged storage infrastructure too.” One of his first decisions was to employ Google Apps for their enterprise email. “That was a slam-dunk and one of the best decisions I ever made.”  He is looking at acquiring other cloud-based apps as well,

Vendor flexibility. Part of moving to the cloud means making use of services that don’t require vendor lock-in “I want to have options to migrate away from them if things don’t work out. That is why I haven’t gotten involved in SAP or Salesforce yet, there isn’t any easy way to walk away from them.”

Segregate production and office networks. As the stories from the German steel mill in December can testify, having totally separated networks between the office and the mill are critical. Hackers used an infected email to literally trash one of the mills. “We have different networks and vLANs so this won’t happen to us.”

Your own rust belt conditions might differ, for example, you might still be using Systems Network Architecture on your mainframes, or connecting via Frame Relay networks. So it might be a good time to reconsider these and other technologies, and start investing in your future. (The building pictured above is from an old automotive plant that has been renovated into condos, by the way.)

Computerworld: Peak vs. Tibbr, two communication tools reviewed

peak activity graphs1If you are trying to have more effective team communications, you are probably looking at products or services that go by names like “social CRMs” or “team engagement tracking apps.” Regardless of what they are called, these apps can connect to a variety of social networks and email accounts and make it easier to manage your communications, track what your team has posted, understand what other team members are working on and improve workflows and productivity by avoiding interruptions or massive amounts of email.

I tried out two of these tools, Peak (shown above) and Tibbr. Both are browser-based: Tibbr also has mobile and desktop clients. You can read my review in Computerworld here.

How Your Customers Can Collaborate Using Open Xchange App Suite

A flexible unified communications service for collaborative workgroups that can share files, import and export contacts and calendars from a wide variety of data sources and Web services, including Facebook, LinkedIn, Twitter and Google’s Gmail. Entirely open-source based.

Price: Varies depending on market and number of user accounts
Requirements: Works on a wide variety of browsers and operating systems. We tested it in May 2013.

OpenXchange Inc.
2033 Gateway Place
San Jose, CA 95110
408 500 0768
http://ox.io

ReadWrite (2012): Was Windows 8 the OS/2 of its era?

I wrote this back in April 2012 for ReadWrite.com.

After watching Microsoft lurch towards completion of Windows 8 and trying out a few of its early versions, I am struck by a tremendous sense of déjà vu. It took me some time to figure out why I was feeling this way, and then it hit me: Win 8 is on track to become the OS/2 of its era, and suffer a similar and ignominious fate.

Don’t get me wrong: I was a big OS/2 fanboy. I even wrote a book about OS/2 in the enterprise, which was never published. But I think it is useful to recall the mistakes of computing yesteryear and see if we can try to avoid them in present-day 2012.

Back in the late 1980s, Microsoft worked with operating systems designers at IBM to produce a successor to the venerable DOS. OS/2 attempted to solve a real problem: having only 640 kB of RAM for running your programs. This meant that DOS made it hard to do more than one thing with your PC at any given time. That’s right: we are talking kilobytes, which is about the amount of RAM in your average coffeepot these days.

Back then we had various tricks to run other things in memory, or to extend that meager memory space, but they weren’t easy. But this was all to get around what was the underlying real issue: being able to run multiple programs concurrently and switch easily among them. We take that for granted today, and indeed with the average multiple-monitor desktop rig that looks like it belongs on the desk of an air traffic controller we run dozens of programs and have all sorts of things open at any one time.

By the time OS/2 was finished, which was a long slog as hundreds of coders worked in dozens of cities around the world, it was basically irrelevant. Windows did a much better job of doing multi-tasking anyway. Intel had come out with better chipsets too, and the world had moved on.

All this meant that IBM and Microsoft were serving different masters when they worked on OS/2. No wonder that they had trouble reaching common ground and ending up splitting up, with Microsoft developing Windows and IBM trying to continue to improve OS/2.

Now look at what is going on with Windows 8. It also began its life trying to solve one problem (having the same OS on desktops, tablets, and phones) but really trying to solve something else: how to beat Apple with a better tablet OS. That doesn’t bode well. We have already had the misfire of Vista behind us, an OS that no one could love or care about. All that Vista accomplished was to put XP more firmly in our minds and keep longer on our desktops. Could an OS really serve two masters equally well? Wait a minute, didn’t I just answer that question?

One of OS/2’s problems is that its protected mode was very bad at running legacy apps. Almost none of the DOS apps ran on the first several OS/2 versions. Sound familiar? Win 8 is also having its problems running legacy Windows XP apps too.

When OS/2 was being built, most people were using 8-bit apps and didn’t really care much (unlike the tech writers) about the move towards 16-bit computing. Because of the upgrade, it was hard to find OS/2 drivers for peripherals such as printers. In my book from 1988, I had written, “UNIX has been able to offer just about everything OS/2 intends to offer for more than a year.” Little did I know how Unix would find its way inside the Mac OS and how Linux would take off in subsequent years. Now we are used to the world of 32-bit and having trouble caring about 64-bit apps, and we have issues still finding drivers for 64-bit Windows. Hmm.

Win 8 also has two different personalities, the old style “Start” that it inherited from XP and the new “Metrosexual” button display that seems to have inherited from Windows Mobile. OS/2 started out with a simple text-only task switcher and quickly got a graphical UI that was crude and something that looked like something from a mainframe terminal designer.

As Nokia and Microsoft work on Win 8, they might end up going their separate ways too, with one doing an OS optimized for phones and the other for PCs and tablets.

OS/2 came with communications and database servers built-in, at leas tin the IBM version. But these were ahead of their time. Now most OS’s have full comms and database capabilities. Ironically, one of the hardest challenges that many business app developers have with the iPad is the lack of a built-in database and the APIs to access the same.

So will Win 8 be more like OS/2 or XP in terms of success? The similarities are somewhat chilling. In the perspective of 2020, I’d say yes.

How Nimble.com Can Manage Your Social Networks

Nimble offers a way to unify and better engage your social network contacts and track your customers and prospects. We tested version 2.0 in February and found lots of great enhancements, including support for Google Plus and Facebook business pages and integrations with leading SMB marketing tools.

There is a free plan and a paid corporate one for $15 per user per month.

Home Page

Using OpenXchange to manage your communications

A flexible unified communications service for collaborative workgroups that can share files, import and export contacts and calendars from a wide variety of data sources and Web services, including Facebook, LinkedIn, and Google’s Gmail. Entirely open-source based.


Price: Begins at $5/user/month for hosted version; $1095/yr for 25 users for server-based software version
Requirements: Works on a wide variety of browsers and operating systems. We tested it on IE 7, Firefox 3 and Mac Safari 4 in October 2009.

OpenXchange Inc.
303 South Broadway
Tarrytown, New York 10591
914 332-5720
http://ox.io