Elgg at a crossroads

I'm excited about the upcoming Hackathon (Sept 23, 24), but this temporary burst can't make up for the fact that core dev contributions are down and have been for a long time.

This isn't anyone's fault. To an extent, this is normal cyclic behavior as people get busy with other things, but I rather think it's that Elgg is no longer exciting or fun enough to maintain developer interest.

Sure, we've made huge improvements in DX and performance, and 2.x provides a lot of value, but the product remains highly tethered to trends, technologies, and architectural decisions made 8 years ago. We have some loud voices in our community telling us that Elgg should change even more slowly (or not at all), and I've personally over-romanticized the idea of extreme backwards compatibility, but if we continue this path I think developer interest will keep dropping off.

Personally I really enjoy working with Elgg's contributors and don't want to stop, but for my career's sake I can't focus on reworking 2008-era APIs much longer. I considered quitting in 2014 and didn't out of inertia and because family health problems made it comforting work to bury myself in.

What can we do?

We could do nothing. This is just my perspective and I could be wrong or it could really not matter. There's nothing wrong with stable software that nudges along slowly. My prediction is that high maintenance chores will start to go by the wayside. Elgg 3.0.x will get dozens of releases and plugins will thrive as they did on 1.8. It's not a bad outcome for lots of people, but I'd be bummed.

In the short term, Ismayil and I should stop stalling new development in order to wait for a 3 member consensus. If a PR on 2.x/master gets a thumbs up and no one expresses concern or a desire to review for weeks, it goes in. Those branches give plenty of opportunity to revert or fix concerns that come up later. When reviewing involvement goes up, we can scale the need for consensus accordingly.

Businesses relying on Elgg could offer developer time. That won't help if devs really don't want to work on it though. And IMO business owners are under no moral obligation to contribute, but it would of course help.

We could seek out and destroy any low-return hassles that make working on Elgg less fun:

  • Commit messages are a constant headache, but may be worth it for our awesome changelog.
  • LTS releases: if so many sites want to run 1.12, one of their developers should put in the work of backporting fixes to it; merging this stuff into 3 other branches is a headache. Maybe the foundation can pay someone to make these releases occasionally.
  • Community spam: Maybe you can't register until you to contribute some sort of content; then we can just delete several thousand spam profiles.
  • RST is still !@#$. I'm continuously looking up how to do basic things and even the docs about RST are bad. Markdown is inferior tech with miles ahead UX. Really I want to do like Drupal and build more docs from source code.
  • ??

We should identify roadblocks that make more radical changes seem impossible. It was really disheartening to turn away a good 3rd party effort at moving to UTF8MB4 columns. Schema changes in general are almost unimaginable due to the expectation that Elgg run its own upgrades.

Personally I would love to--at least temporarily--set aside the requirements of upgrade paths and BC and start over.

  • How can Elgg be many magnitudes faster, not a few ms.?
  • How can it have the real-time functionality users now expect?
  • Are we sacrificing anything by giving plugins too much power?
  • What Elgg-specific dev concepts are really cool or not worth the overhead for new devs to learn?

In general I want Elgg to take a great leap forward to become something I'd be proud to put my name on, not filled with things I have to apologize about.

  • my suggestion is to open a profile there and play with it a while to get a sense of what they are doing.. overall, it looks and feels like an evolved elgg to me :)

  • My thoughts on the questions and topic:

    - Change the data model (at least normalize it)

    - Consider a php MVC framework as base layer and built a fast scalable social network engine on top. (if you consider this, we want to help doing this and make resources available)

    - Leave the idea of content specific plugins. This is not very user friendly. Only pages and make pages cater for any content. All the rest can and should be done from the river.

    - Let core test plugin compatibility instead of manifest (this might be a bad idea if it takes to much time to maintain).

    - I would also recommend that BC should not be your main focus anymore.

    - More realtime options  in the UI.

  • I agree with most of the points that have been discussed here.  I'm guilty of not being around much lately, and am thankful for the work that Steve and Ismayil have been putting in.  I've always been a proponent of forging ahead, I think we've been overly concerned with BC.

    As far as a modern mobile theme goes - I'd like to see something based on a well tested css framework like bootstrap.  Most themes I do end up based on it, and the elgg native css is a pain to overwrite.  Would be nice to have a real grid system and all of the utility classes available out of the box and used consistently among plugins.

    I can't wait to get out of Wordpress hell and back to some real Elgg work :/

  • I'd be fine with Bootstrap UI in core. It would allow to restyle Elgg quite easily with existing themes.

  • My 1 cent. Please do not forget about (non-dev but also dev) site owners.

    How much time can they spend on continuously upgrading Elgg and 3rd party plugins? How much money can they spend on continuously upgrading Elgg and 3rd party plugins?

    There's not many of us willing to stay on 1.7/1.8/1.9->1.12 and I guess all of us would love to upgrade to Elgg 3 or 4 with all the above mentioned enhancements (some extremely needed, mostly UI/UX) but those constraints are real and unfortunately must be considered in any business.

    Therefore, not taking into the proper consideration LTS and/or BC could greatly damage Elgg itself as chosen framework.

    Of course I understand all of you guys bored to work on old technologies and, again, would like so much to offer my users the best outside there but often is so difficult/painful to even start upgrading...

    Always thank you all so much for what you're doing!

    Cheers

     

     

  • as far as i am aware, the UX enhancements that are most desired are along the lines of adding/removing 'things' to/from lists via AJAX and loading other page elements via AJAX. the other most desired feature is realtime notifications. i don't think these changes will require massive recoding of existing plugins - certainly no more than has occurred in previous major upgrades of elgg. the idea of switching to a 'minds' fork would be a major change, yes - but that is not a requirement for the features to be integrated. i think it should be possible to extract the mechanisms from minds, into elgg - without necessarily also extracting the extra technology layers/frameworks too. at the very least minds provides a working design to refer to on the source code level.

  • Elgg is not in a healthy position right now. Elgg usage has been declining since 2014, and there is no sign it will rise up. What can be done? Do we need to worry about elgg? I am going to share with you some thoughts about what can be done to improve elgg and hopefully increase usage.

     

    Roadmap For Elgg  

    The people in charge of developing elgg should go back to the drawing board. Sometimes you need to take a break. What is the strategy for elgg? Which features you want to add? Which features need to be removed? What needs to be rewritten? Each one of you would have to sit together and draw a road map, for the sake of the script. Elgg is a robust engine, but it takes more than being robust to be popular. 

    There has to be a sort of "Elgg Core Council" that will review and decide changes for the engine and also discuss release dates. From the outside, it seems like only core developers call the shots. There has to be some sort of consensus on what it has to be done before a new release.

     

    Roadmap for the Elgg Community 

    Let's be real, there has to be a clear strategy for the elgg community. You can also take the Post-2013 Kubuntu approach. We can form a sort of "Elgg Community Council" that could be in charge of reviewing developers that want to sell plugins here. 

    Yes, I said sell. It is 2016, and we need a commercial plugins section. I know how some are strongly opposed for a commercial section, but there has been several voices wanting to have a place inside the elgg community where you can sell themes and plugins. This could increase interest in developers, which is in heavy decline as of now.

    Besides that, an "Elgg Community Council" could decide and develop the design and layout of the elgg community site. I know it looks better now, but it doesn't look modern nor appealing. So yeah, someone has to work on that, but the "Core Developers" cannot do everything. They need help.

     

    Roadmap for a Commercial Section

    If (a big "If") a commercial section is created, someone has to decide how to implement it and what you want to accomplish in few months. There has to be a clear strategy built around this, so that we could all benefit from it. It is not just having a plain page for "paid plugins". This is something that both the Core Council and the Elgg Community Council can decide and develop.

  • About 10 people responding resulting in about 20 (partly totally contradicting) opinions. Sorry, if this sounds cynical.

    I don't want to add yet another opinion but just make a suggestion.

    Maybe it's necessary to organize a "strategy" meeting or meetings (maybe a weekend online chat session?) not to deal with coding or short-term more specific issues (as for the Hackathon) but to get a bigger picture about the current state and a possible future direction of Elgg. The outcome of such meetings could be kind of a roadmap (not in the sense of a timetable / fixed plan to add feature x in version y just yet) or some kind of "design documents" where the larger goals of Elgg are written down. Based on such a roadmap the path to achive these goals could then be divided into specific steps (github issues). Is this what is called a top-down approach? This would be different at least in some parts to the current development process (that seems to me to be rather a bottom-up approach based on more specific, more or less detailed github issues where the overall picture of the future direction of Elgg might have gone lost to a certain extend).

  • i agree with something along those lines iionly, i raised that kind of idea years ago but no action was taken then. at the time i recall some controversy in that there were distinct groups who wanted different things for elgg - on the one hand there are those who want to use it commercially with clients and corporations and on the other hand there are those who need elgg to be more diversified and accessible even to non tech people for wider use. since elgg is short on resources and coders, the outcome was that nothing significantly changed. maybe a monthly group audio/video chat would work, but then again if there are 10+ participants then text would probably be better.

  • to clarify my previous comment further, there are three main groups using elgg - the creators/coders, the admins and the end users. to a large extent, the changes to elgg's core areas in recent times have been to resolve technical issues that make the coders' lives easier and also to improve performance. what we are now experiencing is the need to focus on the other user groups of elgg - the admins and end users. it's important to remember that to gain support for a technology it has to tick all the 'right' boxes and since the brains of humans are commonly around 60% dedicated to visual processing (as i am informed), that means that even if the technical aspects are the best around, if the look and feel of the experience of using the technology is 'behind' the competitors, it will not gain the userbase that it deserves (and needs for it to expand). this is why i think/feel the UX (and realtime notifications) are the most important aspect to improve to get people excited about elgg. there are much less capable frameworks and apps around that get much more user attention than elgg does simply because (imo) they focus on the superficial and UX experience primarily which, rightly or wrongly, gets people inspired. the people might then get frustrated when they find out later that they are forced to pay for plugins that often don't work very well and that the app can't expand in the way they need - but they will at least get a buzz from using the app initially, which is what is lacking with elgg for many people. if it weren't for the fact that i can code and elgg is a framework that is hospitable to coders i would have chosen something other than elgg for my site. in terms of how to practically achieve an improvement, beyond the UX changes mentioned - it seems there is room for roles in the elgg community that are non technical, that focus more on the human aspect and the task of getting elgg more widely known online. minds.com has been covered by most of the world's mainstream media and yet how many of it's evangelists even know that it was based initially on elgg and what elgg is? in my experience it's less than 1%.

This discussion is closed.

This discussion is closed and is not accepting new comments.

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.