SOGo 6 - February News

February 12, 2026

Dear SOGo community,

We are happy to share some news about SOGo 6, the complete refactoring of SOGo 5.

FOSDEM

Thank you to everyone who visited our stand at FOSDEM! It was nice to see both newcomers and old-timers and discuss with you about SOGo’s future. See you all next year!

In the meantime, you can find our team at AlpOSS, a French Open Source event taking place on February 17..

It’s a date!

Finaly we can reveal our projected roadmap: The first public release of SOGo 6 is planned this summer!

This initial beta version will include the complete web application, though it will not yet feature the desktop synchronization server. That way, you’ll be able to test it, include it in your architecture and report bug while we’re finishing the product.

There is still a significant amount of work ahead to reach this milestone but be assured, we’re doing our best!

SOGo 5

The new patch 5.12.5 will be released this February. It includes several security fixes.

Topic of the day: The Backend

SOGo 6 has two mains goals over SOGo 5:

→ Use a more modern language than Objective-C: This has been achieved by moving to Python. For our API we’re using Flask and gunicorn.

→ Be modular to get new feature. SOGo 5 has reached its limit in term of functionality (after 20 years which is quite a good score!). Any new features, aside of the pain of writing them in Objective-C, would have required to break large part of the code to rewrite it.

Our approach for SOGo 6 is to separate the code onto small bricks. Each component operates without tight coupling to what comes before or after it. This architecture allows individual modules to be upgraded, replaced, or extended much more easily.

• API: defines the endpoints, the input data format and no others logic. They only call the Interfaces
• Interfaces: Their main goals is to call the appropriate modules and format the output data to be directly returned to the API.
• Module: Here stands the most logic. Modules are specialized (Module Mail, Module Calendar…) and know what kind of resource is needed. They dynamically instantiate manager according to the SOGo configuration.
• Manager: They communicate with external services. They have basic methods and don’t know what are the data or what they are needed for.

Understand that the modules don’t know what protocol or services is used. There are parameters in SOGo configuration set to either Posgtresql or mariadb/mysql. With that, the module will dynamically instantiate the correct manager. Let’s say in the future there is the need to use Mongodb instead, “only” a new manager will be needed. And it’s the same for all modules (mail, calendars, contacts, user source, authentication…).

In brief, SOGo 6 is not “SOGo 5 in modern language”, it’s a complete new modular design that will be able to go way further than SOGo 5 and respond to new challenges.

But for now, see you next time 😉

SOGo Team