Online Groups Blog

OnlineGroups.Net has released the source code of GroupServer, the software that powers our web and email collaboration service. This means that, if you are technically savvy and have access to a server, you can download, install and run GroupServer sites for free. You can inspect the inner workings of GroupServer and even make changes to it, if you like. Why would we do this, when we charge money for premium online groups sites here? Here are the reasons we do this.

Transparency Builds Trust

People who use our online groups trust us with their data. Like other service providers, we have a privacy policy, but think words should be backed up with actions. We want our customers to know what’s under the hood of the system they trust with their data. Of course, not everyone has the technical skills to understand the workings of the systems, but the option is there for those who do.

GroupServer is a fairly sophisticated system to administer, so we make it easy to start sites and online groups, here at OnlineGroups.Net. Sites with only public groups are free, but we charge a subscription for sites with private groups. Even though that’s how we make money (there are no ads on our sites), we want our customers to use that service by choice, not because it’s their only option.

We want people to feel good about us, so that our customers spread the word about our service.

GroupServer will Get Better Faster

One of the main things that makes open source software successful is that people who like the software help to make it better. People who use OnlineGroups.Net already do that, by providing feedback in the OnlineGroups.Net Administrators online group, by only people who adminster GroupServer behind-the-scenes can give us technical feedback about it.

As organisations use and benefit from GroupServer, they are likely to want improvements to it. Some of our customers engage us to improve GroupServer now. There is no penalty to them if we give those improvements to all our customers, and they benefit because other customers do the same. In many open source projects, organisations who use the software engage their own developers to make the improvements, and contribute those back to the core of the system.

GroupServer is built in a modular way, so that it can easily support a large community of developers working on it at the same time.

We Like Interesting Gigs

Believe it or not, we like doing real work that makes a real difference. By giving away GroupServer, we know that we’ll get asked to do consulting and development on interesting projects: we already are. We also provide custom hosting for GroupServer sites, and software maintenance to keep sites running on the latest version of GroupServer.

Open Source Software Attracts Awesome Developers

One of the challenges in the software business is finding awesome developers, when you need them. One of our goals in building a developer community is to get to know people who are experienced with our product, whom we can call on to work with us on projects.

Collaboration Software Should be Built by Collaboration

Releasing the source is consistent with our philosophy of collaboration, where it makes sense. After all, collaboration is what our software is for. We believe that software that is built by collaboration is better at supporting collaboration. We’re building it for something that we do, not something that only other people do.

Of course the tools that we use, Linux, Zope, Python, PostgreSQL, Apache, Postfix and others are all open source. Because we benefit from those tools, it makes sense to contribute back.

Giving Software Away Just Feels Right

We want to make significant, widely-installed software. It doesn’t cost us to give away software. We figure that the more we can give away, the more good things will come back to us.

Protect IP by Giving it Away

The fact that there is no licence fee for GroupServer doesn’t mean there is no licence. GroupServer uses the GPL, which strictly specifies that anyone releaing modified versions of GroupServer, must apply the same open licence to their code. This does not guarantee that everyone will play nicely and keep GroupServer open, but the bigger the community that uses GroupServer, the less the impact of breaches will be.

It is even possible that a competitor could start offering a service providing sites and online groups like we do. That competitor, however, would be just as exposed as we are to a second competitor and a third entering the scene. Actually, if you’d like to get involved with GroupServer, come and talk to us. Maybe there’s some way we can work together. Or just go ahead and install it. We are creating an ecosystem here, not an empire.

We’re Not The Only Ones Doing This

Finally, we didn’t think this up for ourselves. Automattic have built a successful business based on the open source blogging tool WordPress. SugarCRM give away their software, as well as providing hosted access to it. Read/Write Web recently described how you can Build Your Own Reddit With Reddit, discussed how niche software service companies can benefit from open sourcing their code.

Collaboration platform provider Grou.ps (who, like, us are not advertising-based, and do email lists with a forum interface) have just raised $1.1 million, and open sourced a version of their software, as discussued on Read/Write Web and TechCrunch.

Update: Scott Dietzen of Zimbralog writes about The Merge of SaaS and Open Source echoes our views about customer like-in, vs lock-in. Zimbra has blended SaaS and OSS from the outset.

“The cynic would argue why give up proprietary intellectual property and lock-in unless your customers or competitive pressures are forcing you to do so? Indeed, the lock-in with SaaS may prove to be more onerous than it has been with proprietary software—not only is an organization tied to a proprietary software service, but its data is now resident in someone else’s data center.”

Data portability is a topic that I will cover in a future post to this blog (we can provide it, but it is not yet standard on OnlineGroups.Net). Scott also writes about the choice between hosted and in-house provision.

“While SaaS allows organizations to ramp up new software with minimal investment, open source means they could always bring it in house later or move to an alternative provider (or at least have the negotiating leverage for doing the same).”

If I had to sum up software development in one word, it would be “don’t”. When you know a bit about what’s possible, it is easy to be seduced by the notion that custom software could solve all your problems. Your business is unique of course, and so your requirements are unique. It seemed so easy for the geeks to code up that prototype. It is easy to forget “Soon, cheap, good — choose two”. The cost of making software robust, scalable and flexible seems to surprise us every time. It is easy to forget the nightmare projects where, with budgets and deadlines long blown, still more resources are poured in before the plug is eventually, painfully pulled. A pretty good fit with an existing system is a pretty attractive alternative. So most of the time, when custom software development is suggested, mechanical repetition of the word “don’t” is the most valuable consultancy you can offer.

Why, then did we build custom software?

In 2002, my company GroupSense provided an online learning platform for post-graduate business school Advanced Business Education Ltd (ABEL), for the third year in a row. ABEL’s programme involves self-study and small group collaboration in between a series of block-courses. In 1998, when we first met to discuss elearning, the managers at ABEL showed me their course material. It was two large ringbinders that they sent out to their students in courier bags. They asked me what I thought they should do with it. I said “send it out in courier bags” and “let’s do something online that you can’t do with courier bags”. We agreed that displacing the course material printing cost to the students would benefit no-one. What they wanted was to make it easier for their students to collaborate in between face to face meetings.

At that stage, I provided online collaboration consulting, using platforms that were already available. Most corporates had a mail system with shared folders. Where they didn’t, or where participants spanned organizational boundaries, many options were already available on the Internet. There were several mature web forum tools, although none of them supported email participation very well. I favoured email lists as they enabled participants to use the client they were already using for collaboration. The best list servers also had online archives, that supported posting and file-sharing: the best of both worlds. I’d been recommending a service called MakeList.com, until it became eGroups.

In 1999, ABEL launched 30 online groups for students using eGroups. It was a small step, that extended the services ABEL provided, and enabled ABEL to begin to learn about how it could use the new medium. By 2000, eGroups had been acquired by Yahoo!, and ABEL provided the same 30 groups plus another 150 groups, in each of two semesters, for small group collaboration. In another small step, the web interface was de-emphasised in favour of simply getting the students to use the email interface. The usage and feedback were good, so we offered Yahoo! Groups in 2001 and 2002, by now teaching the students how to get a Yahoo! ID and use the web interface of their online groups. We also provided a website for ABEL, with static content, feedback surveys, some assessment results and links to the students’ Yahoo! Groups.

There were various problems with using Yahoo! Groups, however. Because Yahoo! had integrated Yahoo! Groups with various other properties, their registration system was complicated. It was difficult to point students to their Yahoo! Groups, because they all had different urls. The groups were located amongst arbitrary other Yahoo! Groups, as well as advertising that was often not appropriate for a business school. ABEL wanted their elearning initiative to provide more of a sense of place, and to reflect their brand. Finally, administration of 330 Yahoo! Groups was manual and tedious, and there was a risk that losing access to the single administration account would shut down the whole show.

Despite the problems with Yahoo! Groups, ABEL was sold on the benefits to their students of being able to interact with their online groups using email, the web or both. They asked us to find an elearning platform that provided the functionality of Yahoo! Groups within a website that they could control. Though we looked, we could not find software that provided that. We evaluated various elearning platforms, but they were all oriented towards content and had basic web forums, at best. There were still no list servers with a good web interface. What we did find was some open source components that went most of the way to what ABEL wanted. We also found some developers who could integrate the components quickly. ABEL agreed to the open source development approach, and GroupServer was developed and in production within a couple of months.

In the years that followed, the ABEL site was expanded to support online content, as well as surveys, workshop admission forms and photo sheets, notifications of assessment results, and sophisticated reporting of results and survey responses.

In 2004, GroupServer was spotted by Steven Clift of E-Democracy.Org. E-Democracy.Org had been running online public issues forums in Minnesota and other places, since the mid-nineties often using Yahoo! Groups themselves. They were looking for an alternative that they could have more control over, and recognised GroupServer as exactly what they were looking for. They provided some resources to develop features that would make GroupServer more useful for public sites. By May 2005, they had begun to migrate all of the E-Democracy.Org forums to a GroupServer site.

The approach of incrementally developing GroupServer has worked well for OnlineGroups.Net and our customers. We have managed to keep budgets and timeframes in check. It has taken five years, but GroupServer is now scalable to hundreds of thousands of users, and it has been in production all this time.

By 2006, organizations including Landcare Research, Local Government Online, and Steven Clift’s Democracies Online were using GroupServer. Other organizations began to ask for online groups sites, so the OnlineGroups.Net beta service was launched. Now that OnlineGroups.Net is now out of beta, and GroupServer 1.0 is available to download, there is a viable alternative to Yahoo! Groups, and Google Groups, for organizations that want email groups with a web forum interface, on a dedicated customizable website, with no advertising.

Finally this week (well, last week, this post and the release announcement have only just caught up) OnlineGroups.Net produced a new alpha release of GroupServer 1.0 entitled “Cream Freeze at the Beach”. Why did we do it? Or rather, why are we continuing to do it?

Was it our love for Open Source Software (OSS), like Linux (ok, you caught me, that was Ubuntu), Python, Apache, Zope or one of thousands of other OSS projects? Well, yes we love them, but that wasn’t the reason.

Was it because we wanted to jump on the bandwagon with major vendors who are slowly discovering that OSS is something that the market is demanding (well I had to throw something controversial in there didn’t I)? Well, no, we’ve been releasing OSS for several years now and using it in the most critical parts of our business for many years before that.

One of the big reasons is the community, and community is something our software is all about. Whether it’s a community of developers learning about the software, a community of accountants learning best practice, or an actual community interacting with one another about local politics, online communities are something we know something about. It seems somewhat natural that we should have a community surrounding the software that powers our communities (does that make it a meta-community?)

It’s also for the word-of-mouth advertising, something we really do love (because Advertising leads to Revenue, and Revenue leads to Beer). We know that people enjoy the software, they’ve told us. We know that people tell other people to check out GroupServer, because they’ve told us that too. We also know that not everyone will want to run their own installation of GroupServer, and that’s why we built OnlineGroups.Net. Hell, even if you do want to run your own installation of GroupServer, we’d still encourage you to try OnlineGroups.Net — we do all the hard work of managing the servers, and keeping things working.

Finally, it’s for the contributions. When OnlineGroups.Net improves GroupServer, we improve the software for you to use yourself, and for us to use with OnlineGroups.Net. When a developer outside of OnlineGroups.Net improves GroupServer (or a non-developer contributes documentation, or ideas, or a new skin, or …) all our customers benefit from the improvements (and thus, love us even more), and the community of people using GroupServer also benefit.

For more information about the new release of GroupServer, see the announcement. Or if you’re really impatient, just download it.

In Why Fight Email?, I explained how OnlineGroups.Net makes email useful for group collaboration. Unfortunately, however, even though OnlineGroups.Net inherently adds useful metadata to email, it does not provide immunity from the GIGO (garbage in, garbage out) effect. If people send bad email, people receive bad email. Receiving bad email causes email overload.

Inbox-management tools such as ClearContext and Xobni, and the more drastic email free days, and email bankruptcy tactics are admissions of powerlessness in the face of bad email. They are ambulances (or body bags) at the bottom of the cliff.

I can’t hear anyone complaining that they receive too much clear, concise and useful email. I do, however, hear increasing calls for consideration before clicking the “send” button. The latest of these is Seth Godin’s checklist of 36 things to think about before sending an email. Although, I agree with every one of Seth’s suggestions, 36 is just too many things for me to think about for every email.

Our own exhortation to write clear and thoughtful posts (part of the User Guide that is on every OnlineGroups.Net site) lists seven things to think about. Actually, for emphasis, two of these are more or less the same: consider your audience.

I have renamed my “send” button, the “zen” button. Each occasion to click this button is a zen moment, a moment for mindfulness of myself, what I am here for, the addressees of the email, what they are here for, and how this email creates what we all seek. This practice is not specific to email, although with email there is more time to write and to read carefully, than in face to face moments. In Psychodrama, this is described as role reversal: imagine yourself as the recipient of the email. Does this email make your day better?

There are problems with email as a collaboration tool. The worst is email overload. A lot of email takes a lot of management. Triaging and curating email are especially difficult when the email lacks metadata that enables it to be assessed without opening the email. Even the best email management approaches take effort, and still result in an email archive of zero value to a group. For many of us, the email management problem is exacerbated by the need to limit mailbox size. The worst contributor to mailbox bloat is file attachments, but even without that, email is a poor tool for storing and finding documents.

People in organisations want to hold conversations, and collaborate on documents. Work is often done in persistent groups like teams, communities of practice, and customer engagement forums. Most people collaborate in multiple groups concurrently, often spanning multiple organisations.

Common tasks include keeping track of conversations, closely following conversations, and contributing to conversations. We want to participate at our preferred time and place, using our preferred operating system and applications. Finally, we want secure, searchable archives so we can access old conversations, and so that organisations can manage knowledge retention, records and accountability. Email supports ad hoc collaboration using “reply-to-all”, but this creates disorganised conversations that can only address one topic at a time. Reluctance to increase email load causes reply-to-all conversations to decay quickly, leaving records that are difficult to retrieve. For persistent group email, everyone in the group must maintain their own list of email addresses, and watch for changes to the “cc” list.

In a persistent group, the overhead of managing email is multiplied by the number of members in the group, but still does not result in an authoritative archive of the group’s activity. Email’s very strength is that it privileges the user over the group. It is inherently distributed. The penalty for this is that email provides no entity, and no repository, for a group. While email is a fantastic tool for one-to-one and one-to-many communication, it sucks for many-to-many communication.

Salvation in Web Collaboration Tools

Promises of salvation from the evils of email abound. All that’s required is migration away from email to a web-based collaboration platform. We are told that wiki collaboration leads to happiness, and that Enterprise 2.0 is about building a collaboration platform that is better than e-mail. Not only is an array of web-based alternatives to email available, but there are phalanxes of implementation experts ready to wrench users away from the most successful software ever invented.

You Can’t Beat Email

Email is the most successful message and file-sharing tool that has ever existed. Consider the criteria for the ideal collaboration client.

• High Functionality. Supports asynchronous conversations, and file-sharing, archiving, can be searched using metadata or full-text retrieval. Email: check! Sure, use of email for collaboration is problematic, but it does actually do the job, and most people manage around its deficiencies.
• Low Cost, for licence fees and hardware requirements. Email: check! It’s already running on almost every computer there is, and it’s available for free on the web.
• High Usability. Email: check! Almost every computer user already knows how to use it, and uses it more than any other tool. The switching cost is zero.
• High Interoperability. Email: check! All flavours talk to all flavours (if only browsers had the compatibility that email clients do!), and email is blind to organisational boundaries.

What other collaboration client that meets those criteria so well? Email is tantalisingly close to the ideal collaboration client. Why are we throwing it out?

Throwing the Baby Out with the Bathwater

Once the licence fees, hardware requirements and deployment of the new collaboration platform are taken care of, people will have to stop what they’re doing now, and learn to use a new system for collaboration. Each user faces the cost of abandoning the system they know, and climbing the learning curve to the new system, amidst the pressure of daily priorities. If any user baulks at this cost, you have n-1 uptake of your new system. Unless that one person is superfluous to the team, the other team members must accommodate them by duplicating communications in the new medium, and email, or reverting to just using email.

Even with 100% internal adoption, the system may not work well across organisational boundaries. Even if it does, you now to get users outside the organisation to use your new system. Hopefully, they are not being marshalled into a different collaboration platform at the same time.

In their zeal, the crusaders for change scoff at these barriers, and declare that the benefits offered by the new system makes it worth taking the pain. Not only that, but they decide that, along with the migration, there will be a purge of old bad habits that have crept across the organisation. Everyone will now start thinking about the greater good, and apply metadata to their documents and communications.

In a final blow, because the new collaboration system is web-based, it is inherently a pull medium, not a push one. It therefore uses email to notify participants of new activity. Your users can keep using email to follow conversations if they want to, but they have to leave email for the new system to contribute.

It’s Not All About Implementation

What if the cost of teaching people to use the new system was invested in teaching people to use email better?

The problems with email can be mitigated to a large extent, by adopting improved practices. Writing good subject lines is a great place to start. Using search, rather than folders, to organise email works for many people, and if you do use folders, message rules make a big difference. But improved practices alone will not overcome the limitations of email for collaborating in persistent groups.

What is required is some kind of technology that allows people to keep using email, more or less as they do now, but makes it easier to use email to collaborate in groups.

There is a Technological Solution

A system that supports group collaboration using email should allow users to contribute as well as access messages and files using email. It should also provide some shared repository that can be accessed over the web, regardless of location. The shared repository should archive all communications and be searchable, but it should also support day to day participation in conversations, and document-sharing. Ideally, the tool should provide equivalent functionality via both the its web and email interfaces.

Technology that provides this functionality is easily found: email groups. The best-known examples are Yahoo! Groups and Google Groups, and of course there is our own service at OnlineGroups.Net.

Email Groups Make Email a Collaboration Client

Email groups are a simple but flexible technology that supports semi-structured group communication, accessible via both email and the web.

The group has a name, an email address and an address on the web. Any group member can email the group, and the group sends that email out to all group members. All posts and files are accessible in a central repository on the web, where users can also add posts and files. Groups have persistent membership and discoverable privacy settings and joining criteria. Group members maintain their own email addresses and delivery settings.

Email groups overcome the primary weakness of email, by providing an entity, and an interactive repository for a group.

Email Groups Overcome the Problems with Email

Firstly, even if users do not write better subject lines, the message headers inherently contain more metadata. The group address and, if set, subject line prefix, instantly signal the context of the message, including the participants and purpose. Even if the subject line is broken, the sender, and senders of other messages with the same subject line provide further data about who is doing what in the group. If messages are not filtered, often they can be deleted or marked as read, without needing to be read, as a full transcript of the conversation is available on the web. This makes is easy to triage email, to keep track of conversations, to schedule detailed attention to conversations. Topic digests, and web feeds provide further ways to support these tasks.

The aggregation of group-related posts in a web archive supports the task of closely following conversations, and contributing to conversations. Posts are organised into separate threads or topics, and sorted by date, making it easy to follow one or more concurrent topics of conversation, whilst ignoring the others.

Files are stored in the central repository, associated with the messages that relate to them. Versioning is handled by the deceptively simple process of adding successive versions to the repository. This eliminates mailbox bloat, while providing an audit trail of all document edits.

Simple improvements to practices can increase these benefits considerably. Writing good subject lines means that even more emails can be triaged from the inbox. The text of previous messages is already in the archive, so it can be removed, increasing the signal-to-noise ratio.

With good subject lines, keeping track of who is discussing what is even easier. In the following example (from the OnlineGroups.Net Administrators group), it can be seen that Dan and Annelies are discussing Chat, and that Michael has responded to Kirsty about Adding Members.

Email Groups for Organisations

At OnlineGroups.Net, we used to use Yahoo! Groups extensively to facilitate collaboration for our clients. These were successful because of their killer feature of working as well via email and the web. Our clients, however, began to demand greater control over the context of their email groups. They wanted their branding, not that of Yahoo!, around their email groups, and they definitely didn’t want ads from arbitrary third parties. They wanted their groups at their own domain. They wanted more control over the administration and privacy of their email and document archives. They wanted their groups grouped in a single context, rather than appearing alongside unrelated groups. And they wanted to be able to associate web content with their groups.

GroupServer and OnlineGroups.Net

To meet these demands, in 2004, we built GroupServer, an open source collaboration server, providing email groups, in a web content and application framework. GroupServer has been in production since then, underpinning sites used by clients like Advanced Business Education Ltd, and E-Democracy.Org. GroupServer version 1.0? is available for free download at GroupServer.Org.

Because GroupServer sites can distribute millions of emails a day, they are not trivial to administer. OnlineGroups.Net therefore provides access to GroupServer sites and groups via its software service at http://onlinegroups.net.

One of the nice things about working in usability is that I do get thanked, in a way: people use what I create. Below is a screen-shot of the front-page topics listing on a GroupServer site — which I have edited to protect the users’ privacy. I was blown away by the sheer volume of messages and files posted to this site in such a short period of time.

• Each of the 9 fuzzy blocks is a topic.
• The newest topic is at the top. It was posted to one hour after the oldest topic.
• Each icon represents a file posted to the topic: there are 8–25 files in each topic.
• There are 13–78 messages in topic.
• Each topic is from a different group (by chance). There are 200 groups on this site.

Yea! The users used it!

No Comments