If you are building something like WikiSuite, here is some advice.
WikiSuite started in 2011. Since then, some Alternatives have surfaced, evolved and some have died. Looking back on this period, here are some lessons learned from our and others successes and failures.
You will invest a crazy number of hours in this. It is a wise investment to do thorough research into all the Alternatives. Is there really nothing out there which corresponds to your vision?
It's not just the code. You'll be running a full-fledged organization.
Here is an example to illustrate the various roles and responsibilities in a large software project: https://tiki.org/Teams
Recommend reading:
Think of the flow from the end user perspective as they move from feature to feature.
End users will have all their data in this. You need to do this having in mind to support it for the next 20+ years
And thus, you need to plan for the long run, and be mindful of technical debt
Developers want to jump in and code. Be careful: it's not just building it, it's supporting it for the next 20+ years
WikiSuite was announced in 2011. There were several iterations before getting to today's list of components. Sometimes, changing one component has a cascading effect. Once you have users and data in one system, it will be very difficult to have them follow you in major changes.
Think ahead 10 years. It is not unlikely that some of the components you have picked will run into difficulties. Make sure to be involved at certain level to participate and help them strive.
Many hard decisions are about trade-offs. Which interests will you sacrifice in order to make things better overall?
For example, in WikiSuite, we don't support Multitenancy. Each project should have its own virtual machine. This has many benefits and drawbacks. We live with that choice.
Be prepared to make such trade-offs.
An example of a trade-off: Using established standards offers many benefits. But it can constrain you. And the standards process can be very very slow.
Ex.: Tiki uses SVG-Edit as a Drawing tool. It's great because drawings can also be worked on by another tool. However, it limits us to what is in the spec. For the record, we plan to add support for an alternative Draw.io in Tiki 19. Draw.io has way more features, and a better UI, but it doesn't use SVG.
Another trade-off: Supporting IMAP (more compatible) vs JMAP (more features and performance) or both (more work)?
It is to be expected to have a handful of major players in any market segment. They have a different drive / vision / DNA. And this will drive different design decisions and diverse outcomes for end users.
For example, in the case of WikiSuite, we explain it at Alternatives and we make clear design choices for tons of integrated features because we believe it's the best way to avoid the pitfalls of http://pluginproblems.com/