Elgg Blog: 2013 Review and the Road Ahead

Statistics on our progress in 2013 and some thoughts about where Elgg is going from here.

2013 Review

Here are some numbers highlighting what was accomplished for Elgg in 2013:

  • About 2000 commits to Elgg core, not counting merge commits

  • 217 new plugins and themes uploaded to the community

  • 30 contributors to Elgg core in 2013.

  • 4 bugfix releases for the 1.8 branch (1.8.12 - 1.8.16)

  • 3 new core developers: Juho, Pawel, and Matt

  • 1 ElggCamp: ElggCampAMS

In addition to the above, we’ve done a lot of work to give the community more power to make Elgg awesome. For example:

  • You can now submit your Elgg site for display in the showcase, a great way to promote both Elgg and your design work

  • We added the concept of “trusted users” so that designated moderators can help us admins keep spam under control

Finally, we also made great strides toward the release of 1.9. All of the major work and features are done, which include:

  • Convert comments + discussions to entities

  • MySQL-based queue for async tasks

  • Async notifications

  • AMD for JS modules

  • Refactored core libraries into classes

  • PHPUnit tests

  • New lightbox (Colorbox)

  • New WYSIWYG editor (CKEditor)

  • Default theme uses HTML5

  • Bundled responsive theme by PerJensen

  • Bundled RST docs

  • Maintenance mode

  • Robots.txt support


Before we’re comfortable offering a 1.9.0-RC we just need to iron out the last few major bugs, and before we announce 1.9.0 final we want to upgrade the community site to 1.9 to make sure that experience is straightforward even on a large existing site.


No new features are going into Elgg 1.9 at this point, as we want to focus on stability and getting it shipped.

The Road Ahead (2014 and Beyond)


A very common request for the core team is “What’s on the roadmap?” While we have made it clear that it’s impossible to promise dates, I do want to give you a glimpse into the general direction of the project post-1.9.


Reducing the Maintenance Burden

Elgg is a huge project and takes lots of time and effort to maintain. It is a labor of love that many of us have been committed to and excited about for a long time, but we feel like there are some things that we can do that will really streamline progress for Elgg as a whole.

Giving Contributors More Ownership

Adding 3 new core team members was a great decision for Elgg. Juho, Pawel, and Matt have all been such incredible contributors since we gave them commit access that we figured “why not give more people access?” Maybe we’ll get the same results. Elgg has always been a community-driven project and we think that trusting more people with write-access to Elgg’s repos.


So we’ve given 5 of our top contributors write access to all of Elgg’s repositories on github. We considered anyone with 10+ non-trivial commits to Elgg core since January 2013. If you have submitted 10+ substantial commits in the past year and don’t yet have write access, please email us at info@elgg.org and we’ll seriously consider your request. If there is some reason we’re not quite comfortable giving you access yet, we’ll let you know what you need to do and get you on the right track. We want everyone who cares about Elgg to feel like (and act like!) an owner.


Reducing Release Overhead

It turns out that releasing each new version of Elgg is a lot of work. This fact, not surprisingly, discourages us from making releases until there are enough features/bugfixes to make it “worth” releasing. That means we try to squeeze a lot more features into each release, which require more testing, increasing the overhead of the release, and the cycle continues in a downward spiral until you’re over two years between “minor” releases. This is sad because sometimes it means that code we commit today might not actually help real people for years. That is crazy in a fast-paced world like ours, and simply isn’t sustainable going forward.


The core team knows all this and is taking steps to automate the release process more, such as asking for commit messages that are machine-readable so that the Changelog can be auto-generated from those commits. (It turns out that manually drawing up a meaningfully detailed changelog can take hours effort -- hours that aren’t being spent writing new code or making the community site more awesome). I won’t personally be happy until the release process is 100% automated and releases happen on a regular, predictable schedule. The details of how to accomplish this and how often we’ll do releases haven’t been determined, but consider that one of my goals for 2014. You will not wait another 2 years before 1.10!

More third-party libraries

Elgg was first created a long time ago before there were mature third-party solutions for many of the problems that are solved today. As such, it feels a bit like Elgg suffers from NIH syndrome. The more custom code we have, the more work we have to do to maintain it all, and the less we can focus on the features that make Elgg truly unique.


Therefore, as of 1.10, we’ll be requiring PHP 5.3. This will allow us to take advantage of many more high-quality third-party libs out there, offloading much of the maintenance burden onto those communities. It’s incredible we’ve even stuck with PHP 5.2 for as long as we have, since it’s been without official support for years and work on PHP 5.6 is already well under way.

Transparency

If you don’t have behind-the-scenes access to what’s going on with the core team, the status and direction of the project can feel a little mysterious. That’s why we’ve moved all of our discussion about Elgg core development to the community site. You can follow along by subscribing to the Feedback and Planning group. Consider this our sincere effort to involve everyone in the future of the project, not just those who know how to write code. We also trust that using Elgg more for our day-to-day operations will motivate everyone more to make sure using it is a truly great experience.


What’s after 1.9? 1.10? 2.0?

 

My guess: you’ll probably see development on both in parallel. I can’t say much right now as the core team is trying to focus on releasing 1.9, but it’s exciting times ahead and I can hardly wait to really start planning. We have fantastic ideas to make the community a higher-quality place to gather and discuss Elgg, taking the opportunity with 2.0 to make Elgg a much more modern web framework (think offline, realtime, mobile, etc.). Again, if you want to make sure you’re getting the latest bleeding edge news, subscribe to the Feedback and Planning group for updates.


Evan Winslow

Software Engineer at Google. Elgg enthusiast. I wrote the Javascript and CSS frameworks for 1.8.

Latest comments