we got company!

hi everyone,

i just visited an open source social networking platform , which is just like elgg. they have the most features that elgg has and also some features that elgg don't.

it's name is Oxwall.org , it has the same things like forum , users can upload the plugins. etc etc, it just looks like some modified version of elgg.looks like someone copied the same things from elgg. i don't know about security coding etc etc.

whatever i'm happy with elgg :)

  • Looks like a ripoff to me...

  • I don't think it hurts to broaden your horizon and see what's outside there apart from Elgg. I finally got Oxwall installed (actually a simple RewriteBase issue and as a matter of fact Elgg's .htaccess file gave me the idea). And it doesn't look THAT bad anymore. Not at all. The obvious problem is the current lack of plugins. On the other hand the default features are okay. Actually, very okay. I think the capabilities of Oxwall regarding on-site theming are maybe even beyond the upcoming Elgg 1.8. So, why not take a look and get some inspiration. It can only help Elgg to see what others do.

  • The only annoying thing about this software is that it requires Cron Job and when you put Cron Job in, it doesn't work.

  • The topic came out recently here http://community.elgg.org/discussion/view/1131389/thoughts-on-adding-xoxco-style-tag-input-by-default

    As Evgeniy mentioned Elgg was placed after 3 other social networking solutions (http://www.cmscritic.com/peoples-choice-winner-for-best-social-networking-solution-is/)

    1. Oxwall
    2. Wall.fm
    3. phpFox
    4. Elgg
    5. SocialEngine

    I'd like to discuiss what's possible reasons for that and what we could possibly want to improve in Elgg to be the best again ;-)

    I briefly looked at Oxwall and there are some of my observations:

    Installation process required copying and pasting configuration... I don't really understand frameworks that still require this.

    Main difference in out of the box version is in my opinion, focus on making it user-friendly and customizable without touching the code. Most of the stuff is made with drag and drop interface. Nice thing is marking elements access with color (might be nice for widgets in elgg). They treat themes as separate suff from the plugins.

    In general I don't see anything totally new from the content point of view. The difference is mostly the interface.

    Worth noting is built in mechanism of AJAX polling for notifications (mechanism itself looks content-agnostic and passes data with JSON).

    .htaccess rules suggest integration with XMPP over BOSH (http-bind)

    Cron configuration is only one rule called minutely - i like it as it's easier to maintain more installations.

    Amount of plugins seem to be ~200 + 20-30 themes.

    So in general I would say it's system following motto: make your own social network only by clicking.

    To sum up what I think we might want to have in Elgg:

    • Plugins marked as "themes" - possibly giving some additional info in manigfest.xml, in general sth like "provides theme" as we have "provides plugin". One theme at a time + separate admin section to expose it more explicitly to the users.
    • Themes configurable from admin panel (some basic colors etc.) - probably some of them have sth like that, but maybe some standarization would help? Not sure if that's actually necessary, more like encouragement for theme devs
    • Simplified cron configuration from server side
    • More focus on making Elgg simple, usable and configurable for "non technical people"?
    • I like very much standarized, content-agnostic AJAX communication channel provided by the core. This helps to keep complex systems simple when it comes to communication realization (no more mass ajax endpoints registering, ability to combine multiple messages into one request etc.). We use such solution in our company and it really makes JS code simple and helps to focus on actual logic instead of how to encode/decode the data, handle communication errors etc. (we have /ajax/ PH but it lacks flexibility)

    Actually I like last thing most. The rest is probably also worth discuission.

  • I tried too not too long ago - the thing that hit me was their default theme is quite nice and polished.  Although I don't know a lot about their back end, it is a matter of first impressions and they definitely win on that.  Of course that all changes the minute you install a theme on either system, but you know, first impressions are important too - especially for someone who is not going to be coding.

  • Other major differences are Oxwall has one central market for plugins (paid and free) and has partnered with Odesk so users can post a job. We actually have a plugin which does exactly that (the jobs stuff). Would people be interested in having it on elgg.org? Demo is at www.jobs.webintelligence.ie

  • how about a social network for social networks? less competitive, more sharing, more community. lol

    1. Oxwall
    2. Wall.fm
    3. phpFox
    4. Elgg
    5. SocialEngine

    Wall.fm is hosted solution for oxwall like wordpress.com for wordpress, and there was a call for voting on both communities, and also on the phpfox blog. We were just not informed :)





    Google trends for most popular social networking scripts in 2012.


  • It's extremely difficult to compare "social networking" software and I'm never much convinced by polls and search metrics--if Elgg were to far surpass every other similar product in search trends and polls, what would that mean to the average Elgg site owner? The value that each software product brings is highly dependent on the needs and resources of the site creator. PhpFox can give you a FB-like community on your site tomorrow, and if that's your only desire, it's the best choice for you.

    Two areas where I think Elgg shines above others:

    Being a framework. The plugin APIs, access, views, and hooks systems are engineered to allow up-to-speed developers to dramatically shape Elgg sites and add features very quickly. And the fact that the bundled plugins use these APIs aides the process of discovery and eases the learning curve considerably. 

    Backwards Compatibility. The Elgg core devs really do put a lot of effort (considering BC when designing new features/API, reviewing code submissions, etc) into not breaking plugins. 1.8 was an extreme case, but many 1.7 plugins still operate.

    This also means some features come slowly. Ajaxification is a must-have where Elgg is sorely lacking, but we're trying to do this carefully to not break BC and to allow building onto developers current skillsets while keeping client-side views extensible as they are on the server. As you can tell by 3rd party plugins, Elgg doesn't make it difficult to forge your own path here, but we want to get this right so Ajax development isn't super hard nor do plugins end up clobbering each other.

    (Where more prominence would help is to get more developers seeing Elgg as a useful project to contribute to. We have a lot of easy-ish tickets that could add a lot of value, but core dev time is limited and a lot of patches are scratch-your-own-itch. We need to be better at prioritizing/solving tickets that have a high ROI.)