Elgg is a commercially sponsored (Curverider) open source social networking and collaboration framework (PHP5+/mySQL 5+) that started and remains involved in building online academic communities. (Unfortunately, I'm not aware of any vanilla Elgg demo sites, so you may have to install it to try it.) 

When Elgg 1.0 was released in late 2008 after 4-5 months of delays, I was disappointed with it. This was a much-awaited complete rewrite of the "classic" Elgg 0.9x codebase, which goes back to 2004 or so. There was (and still is) no migration path from 0.9x to 1.x. The 1.0 installation system was bound to fail on many common hosting arrangements, and lacking good documentation, instructions, stock templates, as well as a good community home (with quality discussion forum software), I felt the uptake of Elgg 1.x with novice to intermediate users of PHP/mySQL applications would be slow, with many people stymied and frustrated from go. I think those are really the main people you need to attract to make a FOSS project take off.

While it's not heavy in code, Elgg 1.0-1.1 did prove to be excruciatingly inefficient in its database performance and highly consumingof server resources. So I tuned out for a few months and gladly missed some kind of fracas on the Elgg community site that resulted in Curverider taking a somewhat more closed stance toward users, insulating the core and serious developers from interloping critics. While reasonable, this seems to have ruffled feathers and sown some distrust which is bound to exist given the commercial backing for the Elgg project. The heat and paranoia was undoubtedly due in part to the Elgg software's lack of moderator roles and Curverider's lack of staff/time for handling flamers upset with Elgg or suspicious of Curverider's commitment to open source code.

Most of the serious, real performance problems with Elgg 1.0-1.1 seem to have been resolved or significantly improved as of version 1.2, at least to the point that load speed on simple Elgg sites with little traffic have come into a more acceptable range. Version 1.5 is expected at the end of this month with further performance improvements, among other things. (There is a 6 month development cycle for major releases.) Now at almost 200,000 lines of markup and code (estimated value by Ohloh is $2.6M), I am relatively pleased with Elgg 1.2's functionality and the rate of plugin development for it. There is a good core package of plugins and themes with others available at the Elgg.org community site. Plugin quality varies widely, but as usual the cream rises to the top if you wait for it. Some pro developers, like Kevin Jardine, have turned out some very useful, quality code for Elgg. (Unsurprisingly, plugins like Jardine's event calendar were the result of funded projects.)

The best recommendation of Elgg, even with its inevitable PITA aspects, is that there is no no-strings-attached open source alternative to Elgg. In a day or two you can have a highly customized, themed social network running on Elgg that could (possibly) be matched only by far more labor intensive work with Drupal. (A few years ago there was talk of Drupal integration, but this appears to have gone nowhere. For some reason Curverider deleted that discussion and much else some time ago. This is unfortunate, since simple user authentication integration with a major open source CMS could really help Elgg.)

Elgg will not seem entirely foreign to Drupal users who have gotten under the hood with Drupal. The average (spoiled) Joomla user of slim coding competence will find Elgg harder to deal with, especially if they haven't come around to using or working with the MVC architecture introduced in Joomla 1.5. Sometimes it seems easier to hack the core in Elgg to get things done, but just about anything can be done with overrides through plugins. Learning how to do this is a good experience and the right way to do templating/theming and plugins/extensions.

Before I bring out the hammer and tongs, keep in mind that Elgg 1.5 is slated to fix or improve upon some of the failings and flaws discussed below, among other things. Third-party plugins continue to emerge that address some of the problems I've noted as well. This review concerns Elgg 1.2 and plugins available as of late January-early February 2009. If you are reading this after February 2009, keep in mind the information is dated and Elgg has moved on, surely for the better.

Elgg's biggest problems:

Installation Process: On the downside, Elgg is still no picnic to install, and there seems to be no sense of urgency in dealing with that from Curevrider. Instead, the development team has upped the official minimum requirements for Elgg, which include running PHP as a module only--which makes for a less efficient and less secure system than alternative methods. Elgg is now distributed with an .htaccess file that stops the installation process if it seems all is not as Elgg thinks it should be (and it can be wrong) even though Elgg will run (so it seems) perfectly well on PHP4, mySQL4, CGIed PHP, and virtualized hosting. There is a very important set of crontabs Elgg requires as well, and strangely this is not emphasized enough in the packaged instructions or mentioned at all in the installer screens. Most low-cost hosting will not allow crontabs, so workarounds are required. The simplest alternative is a poor man's cron plugin. None of this is mentioned in the installation instructions as prominently as it should be. I consider these things to be of high importance because they impede rapid dissemination and popularization of software, despite that meaning lots of cheap host installs by people who don't really know what they are doing and are easy targets for crackers. That is the way it goes--lots of suckers make a market full of buzz, wants, and needs. 

Performance,  Scalability, Security, and Server Needs: If you read deep into Elgg's installation config files and dig into Elgg's community site and Google groups, you will find that pages like Elgg's dashboard can issue hundreds of database queries, and to run Elgg in an optimal fashion, you will want to use memcache, split your mySQL reads and writes, and do some rather complicated things to be able to scale your database up as your community sitte grows. These are fundamental issues for any deployment of Elgg that expects high use, and there are a few people talking about them. It is literally a topic of how big Elgg can get.

At the same time Elgg can now be autoinstalled at GoDaddy, and the average Elgg user is probably running Elgg there or on some other kind of low-end shared hosting. Self-help idiocy among these users of the usual kind abounds--dealing with permission problems by making all files and folders read/write accessible to the world, or hacking Elgg to admit all HTML tags in text entry fields so users can post YouTube embed code--or malware! There is probably a lot of dry brush collecting among those users, so fires are virtually inevitable--which will invariably be blamed (wrongly) on Elgg. It seems to me that some pre-emptive action might be taken against fires and frustrations by making it clear to common and power users what the best (and worst) practices are for sites based on the scope of their ambition, their owners' wallets, and their operators' technical expertise. 

Community Contributions and Support Site: Elgg itself has proved a poor basis for a community site to support Elgg's own growing base of users, unless you like the challenge of navigating chunky chowder: multiple groups anyone can start if restrictions are not established early and endless numbers of long and sometimes redundant discussion or comment threads. Several Google Groups for regular users and developers intensify the normal mayhem of a FOSS platform community forum.

Things get downright stupid at Elgg.org with new plugin version releases or variations by different authors, each with their own page and references to earlier and later versions only if the author takes the time to create the requisite notes and links. People paste code (for complete files) and even patch files in comment threads. This makes for far, far worse anarchy than even drupal.org of yore. But, since most amateur users' Elgg sites look like either absolute hell or "Look, I just installed Elgg," Elgg.org has at least the salutary benefit of being a C- design concept you can learn from as a moderately horrid example to improve upon. (I came a cross a comment once suggesting that Elgg.org uses Wordpress for its main pages and developer blogs.)

The only really good example of a well-done Elgg site I've seen is budokin.com which is extensively customized and augmented with jQuery tools, Google site search, and other external resources. It also ditches Apache and runs on a unique server configuration to overcome Elgg's performance and scalability problems. Other Elgg sites, including some possibly built by Curverider, are far less attractive, and the closer they are to Elgg's default condition, the harder they are for users to navigate and use. Hopefully some of the innovations at sites like budokin.com can be brought back into Elgg or documented with sufficient detail to be of use to Elgg users. (Budokin.com's developer has shared his server details and an explanation of how to setup jQuery tabs in an Elgg theme.)

Elgg.org illustrates Elgg's main interface design failings: At Elgg.org they've killed Elgg's "dashboard" (a good move), which is like a more publicly concerned user profile page that throws out a tone of database queries. Using both the dashboard and profile pages seems redundant and navigationally confusing. Users can assign widgets (plugin features) to different parts of their profiles and/or dashboards, but most will ignore this functionality whose usefulness is not clear and rather questionable. (Widgets are like blocks in Drupal or modules in Joomla. Most display or track your content and activity, as well as the content and activity of others.)

Something else that should be removed (or supplemented) at Elgg.org and most Elgg sites is the toolbar's "Tools" dropdown menu. It is essentially the major navigation menu listing applications, which are like "components" in Joomla. The Elgg "tools" you have installed only appear as a single dropdown submenu list (in small text) under the unobtrusive "tools" heading when you are logged in. This makes little sense, since public/non-logged-in users often may need (and be allowed to access) these "tools."

Because the Elgg tools menu is really a misnamed collection of the major mini-applications in an Elgg installation (which you can't easily manipulate/rename/reorder in the tools menu), the better templates compensate by copying the toolbar items (or some of them) into a standard, horizontal, master navigation menu at the top of the page. Oddly the standard place for this menu in stock Elgg templates so far is the footer, in small text, in the hope that everything will fit. If you add a lot of plugins, everything won't fit.

But for all its interface design, naming, and organizational/navigational mistakes, Elgg is not narrowly constructed as a MySpace/Facebook clone like Joomla's much newer and more superficially engineered social network extensions. For those not interested in such narrow, generic uses of Elgg, this is a good thing.

Small but potential deal-killers, for now:

If you aren't prepared to do a bunch of programming development for Elgg and expect all the basics covered out of the box, these are likely to be the top three things that put you off:

1. Elgg lacks email subscription options for discussion/comment threads and other new content. Email remains the original and best interface for "social networking." Not being able to push new content to users by email is a huge gap in Elgg's core feature set. A partial workaround can be had by pushing Elgg's RSS feeds (there is one for nearly everything) to email with services like Feedburner, or Twitter, etc. Still there is no substitute for opt-in email notices about replies to your content, new content in a certain area you're watching or responsible for, changes and replies to things you've bookmarked, etc. Combined with the poor navigation system and limited stock template designs, lack of email (or any internal) notifications means content and activity gets buried fast. The various activity monitoring widgets do not have robust filters, good pagination, or multiple views to easily allow creation of pages where you can quickly assess what's new and happening on your Elgg site. (The 1.5 release will have a new "notification" feature of some kind, and a plugin was recently introduced on the community site for internal notifications. I don't know if these are related.)
   
2. Elgg has a weak search facility. Worse even than Drupal's and Joomla's, Elgg's core search plugin is barely useful; it searches only for tags assigned to content/objects by users. (Elgg.org uses Google site search which also randomly adds in content from the Elgg Google Groups.) A third-party improved search plugin is available but buggy as yet and a little non-intuitive. On top of the limitations already noted, lack of strong search features adds to the buried content problem. 
   
3. Elgg has no SEO functionality. Out of the box all that your pages will have in the way of metadata is a title. Tags do not become keywords. So it's not just users who will have trouble finding your Elgg content, search engines will have trouble too. 
   

A suspicious mind might think these three "limitations" in Elgg so effectively cripple it, the crippling might be an intentional incentive to push customers toward the services of Elgg.com, but the sites showcased there (as well as Elgg.org) all appear to suffer the same limitations. These are not terribly complicated feature gaps to fill, so they are probably not top priorities. They are however clear "surface" areas Elgg needs time and assistance to improve to reach a point where it covers all the essentials as a solid framework for developing online collaborative and networking sites. It looks like third-party contributors to Elgg's plugins have initially concentrated on interface conveniences and additional content types, like photo albums, rather than these more basic functionality needs.

The list of lesser grievances:

• No easily accessed default global settings. Within the Elgg interface you can't set default permissions on newly created content or whether to identify users by username or real name without hacking the core files or creating some kind of plugin to override the right core processes. It makes no sense to me why the default naming identifier for users is their login ID. Handles are not cute; they are 50% of what someone needs to take over someone else's account. 
  
• No global defaults on what widgets will appear on user profiles or the dashboard. Some new third-party plugins offer some rudimentary ways to do this that require some custom coding. A simple switch to kill the dashboard and/or toolbar for some or all users would be nice at some point.
• An unclear "email notification" setting for users that defaults to "off." They won't know what this does and doesn't control because I sure don't.
• Weak "friending" system. You can make anyone your "friend," and they may or may not return the favor. All this really does is let you "follow" other users' activity (a la Twitter) in the various activity tracking widgets. (For this reason users wrote language override plugins that change all "friend" references to a "following"/"follower" nomenclature.) "Friending" people also allows you to send private messages to them or invite them to a group--things you can't do to users who are not "friends," even if you are the root admin. This limitation is not intuitively obvious nor is it explained within the interface or any documentation I have come across. A plugin exists to implement friending that requires reciprocity, as in Facebook.
• Unclear terminology. "Friend collections" sounds perverse, but for fear of creating confusion with user-created groups, your personal friends groups or categories are called "collections." Other under-explained terms (such as read/write access and group membership rule settings) make navigation and content creation less intuitive.
• No comment feeds. Hence no comment "widget" or "tool" where multiple comments are aggregated. New comments are easy to miss as a result.
• No registration moderation. Elgg's core has weak and problematic user banning and deletion functions. To get what ought to be considered basic administrator controls over user registration, validation, and banning, you must add third-party plugins which are not all perfect. This is the one area that must be perfect otherwise users get locked out and generally pissed off. 
  
• No good, stable video sharing tools or widgets. Nothing useful that works reliably, yet. (Likely to change soon, I think--optimistically.)
• Dirty widgets. Deactivated widgets don't remove themselves from the dashboard or profile but leave behind their empty shells to crap up the screen and confuse users. If you deactivate a plugin as an admin and users have widgets enabled that require it, you can't do anything to spare them the appearance of wreckage. 
  
• Files and other content/objects can't be shared or moved across groups. Exception: Jardine's event calendar.
  
• Can only delete, not edit, comments in groups. Aargh!
• No content item display ordering. The most recent material is always on top.
• Plugin entrapment. If you delete an active plugin without first disabling it in the tools administration screen, you will not be able to fully remove it since Elgg is constant interacting with enabled plugins and adding a dbstore file in their folders. Consequently, deleting a plugin folder makes Elgg crash. This is a too-easy setup for noob goofuses to break and lock themselves out of Elgg.
• Sub pages aren’t shown in root page indexes. You can make pages that are sub or child pages of other pages, but only the root/parent pages will be listed on the main pages page. The first time I encountered this, I thought I had lost some sub-pages. More content burying!
• New users in limbo. Users that have registered but are not yet validated appear in the user lists but can't be messaged or added to groups. Since there is no indication of the registered-but-unvalidated status--and no option to validate them administratively except through a third-party plugin--this can be confusing.
• New users easily locked out. Elgg lacks idiot-proof user registration/validation and idiot-handling mechanisms for admins. The standard user registration process involves new users being sent an email after they register which contains a link they need to click to validate their account, otherwise they will be locked out of it. The link includes a unique code that will activate their account, and there is no way to resend this link if it is lost or not delivered. If a user does not get the email or doesn't click the validation link, they will be locked out of the site. A large part of the problem is that users are very likely to ignore the validation link because 1) the default language file for the email notification text is not very engaging and does not stress the importance of the link, 2) new users are admitted into the site after registering before they have clicked the validation link. They are likely to enter the site and assume they can log in later, but they will actually find themselves locked out until they click the validation link. If they deleted that email, there is no way to resend them the validation link or to validate them manually, althought the latter can be done with a third party plugin.

All things considered: Elgg runs, plugin development seems to be quickening, and it is the only unfettered, fully free, open source social networking platform that was built from the ground up to do social networking--with an eye to collaborative thinking and writing, not just bullshitting about Britney Spears. Dries Buytaert once wrote something about no CMS being worse than the one you're currently using. That goes double for Elgg and other FOSS creations in early development phases. The point is not that they're bad, so don't use them--they're a pain but usable and will get better with use, abuse, tinkering, and collaborating--which includes critical candor about their primary failings. What doesn't kill FOSS makes it stronger.