Group is finally released. A look on the past and the future.

But before we get started, I’d like to clarify that this blog post is about the Group module’s development history and decisions, not its inspiration or origins. If you’d like to read more on how I was daring enough to take on this behemoth’s development, please read the following blog post instead: (Organic) Groups in Four Voices

How did we get to a D8 version and what does that mean for the code

Initial development choices

When I joined Deeson in late 2015, the goal was to take the good parts from Group’s D7 version and release them for Drupal 8 as soon as possible. I had learned my lesson about trying to appease everyone and decided that it would be feature-poor rather than rich, but with easier extensibility to make up for it.

I knew that I wanted to completely remove any “special privilege” for my own functionality and instead focus on writing a few APIs that I would implement myself, levelling the playing field as much as possible for anyone trying to extend the module.

It was at this point that John Ennew suggested I’d use the same connection for all things added to a Group, even if it didn’t seem to make sense for some use cases. After having done my research, I found that it could definitely work on Drupal 8 but I did have to jump through a lot of hoops to get the ball rolling given D8’s young age. In hindsight, it was one of the keys to Group 8’s success and I’m happy we went through that pain then to get to where we are now.

Choices I regret making

One of the major drawbacks of having to go fast, is that it makes it difficult to go far. When I started writing Group for D8, I had not properly taken the time to completely study every subsystem of core and my test-writing skills were virtually non-existent.

This meant that I sometimes wrote code that worked well on the surface, but later turned out was not using core’s APIs properly and led to having to write some nasty updates. Example: Groups were not translatable at first and making that possible after the fact was a huge pain in the earlier versions of Drupal 8.

To make things worse, I started off with zero test coverage because who has time to write tests when all you want is to write awesome code, right? Wrong! Several of my earlier updates and even one or two of the more recent ones turned out to break something that was previously working fine. Not having tests is a huge red flag that I strictly try to avoid now. Which is why all of the more recently introduced APIs or systems in Group come with a large amount of tests to make sure they work well.

The final push: Finishing Group -and- Subgroup in one go

We got to an agreement with the Japanese agency ANNAI to help them build an extension to Group which allows groups to be placed within groups, called Subgroup. They needed a system in which permissions could be inherited up or down a hierarchy and rather than writing an extension to Group themselves, they asked if I would be willing to work on it for them.

One of their key requirements was that all of the code would be covered by the security team, so they’d know that their application can be considered safe going forward. When I explained that I had a few troublesome issues still blocking a full Group release, they agreed to also fork out the budget for me to finally get those issues resolved and be able to release both Group and Subgroup all at once.

None of this would have been possible if it weren’t for my friend and former colleague Mori Sugimoto setting up the meet at DrupalCon Amsterdam in the fall of last year. And I’m pleased to say that the collaboration has been great from start to finish. Group finally got a full release and Subgroup was finished on time and comes with high-quality code and full test coverage.

Subgroup’s release candidate can already be found here and it will be promoted to a full release shortly, after we’re done with some internal testing.

What’s next?

A new way of developing

I’d like to consider the code quality of Subgroup as my new standard. So anything going into Group now should ideally meet that way of coding. This means that, over time, some older aspects of Group will have to be rewritten to receive the same attention that the newer functionality got.

The goal now is to look at popular feature requests and squash bugs for a while, making releases as we go, and then start working on a 2.0.x branch. That branch will do away with all of the older parts I really dislike and replace them with newer systems that I cannot put into place without breaking backwards compatibility. It may also involve renaming a few poorly named systems, but I’m still on the fence about that because it might make migrating from 8.x-1.x to 2.0.x more difficult.

Calling for your help

I’ve been going at it solo for far too long now. So my most ambitious quest right now is to find new co-maintainers to help me achieve all of the above. Ideally, I’d like to see whether the people behind Organic Groups and I can discuss something we all like and perhaps work on something truly amazing together.

Having said that, I’d already be really satisfied with someone stepping forward and wanting to help out. It’s pretty obvious you’d need to know a thing or two about Group and core, but having your head in the right place would already go a long way. I’d encourage anyone who feels like they are up for the task to contact me directly via drupal.org or through Drupal Slack to see whether we can come to an agreement somehow.

Looking for new projects to dedicate myself to

Usually, I’m not big on marketing my skills or trying to pitch a sale to someone. I enjoy developing cool software and everything else is “meh”. But in this case I’d like to make an exception.

You see, I’ve had so much fun developing software the way it ought to be developed over the past two months, that I’d like nothing more than to be able to do it again. So if you have a desire for an extension to Group and you have some budget to throw at it, do not hesitate to contact us.

Not only will you be able to get someone who knows the Group module inside-out to work on your project, you’d actually be sure that person is really motivated to work on your code too! If this win-win sounds like music to your ears, hit us up at hello@factorial.io and let us know what you need.