The release of the new Membership Entity module has brought up a number of good questions regarding its relationship to existing modules. (If you missed it, you can read the announcement blog post here.) One comparison in particular relates to similar aspects of Membership Entity and Organic Groups.
If you haven’t heard of or used Organic Groups before, essentially it is a module that allows you to organize your site into different groups that users may join. Groups can have their own content and access rules. It is quite useful and excels when developing a system like an online school, with courses and students, and sharing of content within the context of the virtual classroom.
More Than One Solution
Organic Groups is much like many other Drupal modules, in that it can be extended or repurposed for functions outside of its core use cases. With add-on modules, it can be used to create a working membership-based website, allowing users to buy or gain access to groups that grant them special access.
Membership Entity will obviously never be the only way to make a Drupal membership website, and beyond it and Organic Groups there are still other modules that can be used to accomplish the required feature set. They may not even be mutually exclusive. But, for many use cases and organizations a solution like Membership Entity module will be a more effective and efficient path towards achieving this.
Multiple Users Per Membership
One specific feature of the Membership Entity module that no other module seems to provide well, is the ability to associate more than one user under the context of a single membership. This was a requested feature for enough clients that it became one of the main reasons we developed the module.
You might say, couldn’t they just log in with the same account? For several reasons, this is not an ideal solution, if one could consider it a solution at all. Sharing a login and password may not be appropriate or acceptable to many people, and may be a sticking point with users. As well, if they have distinct metadata that shouldn’t be shared (different addresses, notifications options, etc.) or other info pertinent to the structure of the organization, this becomes an issue with shared login accounts.
Another area of functionality where Membership Entity is quite useful is when the organization needs a membership term based history that functions independently of order transactions. If you’re only relying on a transaction report for a term history you’ll likely just get the start date (date of purchase) but won’t easily get the term length or end date unless it’s factored into a product type.
Adding modifiers, such as an additional two months free for example, without a new transaction would also be difficult. By providing terms as their own entity, Membership Entity makes it easier to modify the term while also providing a robust history of a user’s membership with a complete set of metadata.
* * *
Overall, the most important things to consider are what you’re trying to accomplish and if the module at hand achieves this effectively. More often than not, a module that is purpose-built for a specific set of use cases will require less work to get working than making another good module do something outside of its core scope. Organic Groups is a great module that provides a lot of the features needed for developing a basic membership site, but may require more effort than necessary to provide the kinds of features that a large-scale membership organization will require. We've developed comprehensive membership sites for a number of these organizations. The membership entity module was designed to provide most of the core business functions required by these organizations out of the box.