Discussion: Reinventing Chapter as a SaaS plus on-premise as an option

[vkWeb]

Problem

Quincy's vision for the Chapter from the beginning has been to build a self-hostable event management tool. As we kept on developing Chapter we all noticed that there's a lot of friction for organizations to successfully deploy a Chapter instance. Even if we optimize it to the extend of just one-click and done, still the organization will need to manage the cost of their own domain name, enviornment variables, scaling databases / servers, email delivery services.

Yes on-premise is great for well-established event groups like OWASP. But for the majority that's not the case, they can't handle the techincal expenses (manpower and money inclusive). If we move ahead with just being an on-premise solution, IMO, we will solve only half the problem.

It will be like our majority of the users need Medium and we are saying them to host their blog on WordPress. I hope I have conveyed the problem. Now, let's talk about the solution.

Solution

The solution is simple: offer Chapter as a SaaS with on-premise being an option. The user stories will remain same as our planned MVP. But we will need to make a breaking change for this to work. There will be many organizations not just one as with the case in on-premise. A user will be able to start their own organization from our platform. A user will be able to create chapters under that organization and events under the chapters. Much like the current db schema with one additional table for organizations and a foreign key organization_id in the chapter table referencing that organization.

First, let us see if we are agreeing to this solution or not. It's the perfect time to shift the path else it will be too late. I believe we have not yet progressed that much that we can't change paths. We are still in the early stages.

So if you think we should go with this solution (SaaS + on-premise as an option) please react with 👍 else 👎.

If we get more 👍 we can discuss this solution in as much depth as required else we will keep moving the old way. All thoughts are welcome on the thread :)

cc @QuincyLarson @Zeko369 @timmyichen @allella @tomiiide @ojeytonwilliams @tomnoland @KatieN @pdotsani @megajon @Ryuno-Ki @RandellDawson.

[allella]

I've been assuming that eventually numerous people would attempt to host larger Chapter instances, whether for free or for a fee. This was part of at least one early conversation involving the terminology.

Once we're past MVP and early testing, I've been expecting to personally offer free event hosting via a Chapter instance for Greenville, SC USA under our local hackgreenville.com brand. This could serve smaller, local meetup groups which aren't connected to a larger parent organization. We'd expect some local chapters, like freeCodeCamp, to host events under their national / global instance.

I'm not sure we'd need / want the local instance to support multiple organizations for this use case since we can set the chapters.name to match each of these local entities.

I believe others would consider doing the same for their communities, whether for a geographic area or any other topic area.

I 👍 agree there's going to be a multi-organization use case, like the SaaS model suggested above, where having multiple organizations would be necessary for finer permissions, hosting of custom subdomains, custom branded UI, etc.

However, we're already struggling to move forward on the initial MVP and I personally 👎 wouldn't expand the MVP to include implementation and hosting for multi-organizations.

My vote would be to put this issue on the roadmap and continue this conversation to surface ideas about what we'd need to add / change to Chapter, post-MVP, to make multiple organizations a viable feature.

If anything is likely to cause future, breaking changes with adding multiple organizations it would be the database schema. If this conversion identifies any major issues with the ability to migrate the current schema (image is out-of-date, but still reasonably accurate) to deal with multiple organizations, then those would be changes I'd think we could work into the MVP, now, to avoid future problems.

[ojeytonwilliams]

I think @allella has covered most of my concerns, but I'll just reiterate quickly. If I understand correctly, what's being proposed is essentially that we would set up the infrastructure, domain name, email, db etc. as part of the set up. That's instead of those all being things that the user handles and then configures in Chapter.

That would definitely simplify things from a user perspective and, as Jim said, it makes sense to design things so as to accommodate that possibility. We do want to keep making progress, though, so I would say keep this for after the MVP.

[QuincyLarson]

Thanks for bringing up this potential use case, @vkWeb.

I agree with @ojeytonwilliams and @allella that we should add this to our roadmap. While it does not fall within the scope of our MVP, it is something we may be able to tackle shortly after we have a few organizations using Chapter self-hosted (not necessarily on-premise – freeCodeCamp for example will host our instance of Chapter on a cloud services platform).

@vkWeb Could you summarize the specific steps and features you'd like to see in a SaaS offering here?

[allella]

To continue the conversation about what this feature would need to handle multiple organizations, I think an organizations table would be the most obvious addition. For MVP, that table could exist and have just one record and probably not serve much purpose besides a place from which to pull an organization name.

New organizations table

• id (1)
• name (Example Community)
• domain (chapter.example.com)

Add to chapters table
org_id

I'm not sure the users, besides those with an administrator role, would be linked to an organization since it's possible, as with popular solutions like Meetup.com, that users are part of various chapters within any number of organizations.

Certainly the permissions would need to account for situations where a user is an administrator for one organization, but not all organizations in the instance. The out-of-date schema image doesn't visually reflect the user_chapter_roles and user_instance_roles tables summarized in #270 and added in #296. However, it seems we already took a step towards allowing for roles for multiple organizations when those tables are considered.

We have an owner role and I believe that role would remain unchanged since it has full control of all organizations and chapters for an instance.

the role of a user who can configure the "Chapter" application instance and manage administrators for an entire organization

Also, our early definition of an administrator is

"the role of a user who can setup and manage chapters and organizers for an organization"

and that fits well with the idea of having super user(s) for 1 or more organizations.

Add to user_instance_roles table
org_id

Do we feel adding these fields into the schema of the Chapter instance would prepare us for multiple organizations when we get past the MVP?

[Ryuno-Ki]

👎 since it would add more complexity (the term you are looking for is known as multi-tenancy) to an already too complex implementation. We don't even know yet, whether there's an adoption for what we have in the pipe right now.

[vkWeb]

When I was drafting this issue I knew the biggest concern is going to be our slow progress on MVP and adding more complexity to it will make it slower. But I wanted to convey my thoughts and get feedback.

@allella, @ojeytonwilliams, @QuincyLarson I agree to your concerns.

@vkWeb Could you summarize the specific steps and features you'd like to see in a SaaS offering here?

As @allella said there are smaller, local meetup groups which aren't connected to a larger parent organization. These smaller groups host on meetup to reach mass audience. My mindset was to shift all of these smaller groups to Chapter. I believe only freeCodeCamp has the capability to do this because: we have a huge community following & we have good contributors base. We can provide a fair tool & good audience to these groups.

@QuincyLarson The features will remain same as our current MVP stories. The only additional enhancement we need to make will be allowing smaller independent groups to host events by creating their own organization but not necesarrily chapters under that orgnization.

For example, take Serverless Delhi as a organization, this and most small organizations doesn't have chapters. They host all events under their organization's name. If an organization has zero chapters they should be able create events under their organization name. They can create a chapter when they feel they need more granular control.

Regarding @allella's concern for custom branding, we can keep the custom branding to minimum to keep things simple. I think the major changes will be on the database area and infrastructure side. I will need to research on how we can achieve this optimally.

👎 since it would add more complexity (the term you are looking for is known as multi-tenancy) to an already too complex implementation. We don't even know yet, whether there's an adoption for what we have in the pipe right now.

@Ryuno-Ki Yes we can say multi-tenancy. Agreed. Ummm, Yes I can feel the complexity this will add. We should ship MVP first.

---

Finally, I would say we should stick to our current vision and plan of MVP. Then once MVP is shipped, we can test and steer forward. That being said, the design should keep the possibility in mind (as @ojeytonwilliams & @allella mentioned). @allella has added this to roadmap so I think I can close this issue to keep our team focused on the MVP plan.