Hi, I'm Charles and leading the engineering work on Twenty!
We've made the bet to invest on a tailored design for our components. Using an existing UI library is a strength to use robust components and move faster, but I've always struggled to customize it.
There is always a point where you want something custom that is not supported by the library and you start hacking into it.
On previous projects, I've almost always used existing UI libraries.
For Twenty, this is a long term project and the initial burden of creating UI components vs customizing existing ones will be marginal on the long run.
IMO, if you have strong design requirement (and you have enough resources ofc), don't go with UI librairies ; I take as much inspiration as I can from them, I may fork one but I would not hack their API
Hi, I'm one of the main maintainer of Twenty and we have onboarded Gitstart on our codebase a few weeks ago. I can give a feedback on our collaboration so far:
1) Code quality is good, I would compare it to a very good junior engineer (I suspect some senior engineers are reviewing the code before shipping it!). We are reviewing all PRs and it usually takes 1 or 2 round of feedbacks before merge.
2) Gitstart developers are very reactive on pull-requests, their response time is not a bottleneck
3) You will need to be very accurate about your features. I think Gitstart direclty makes sense for open-source projects as this is part of the culture to discuss everything on issues, to share resources (figmas, specs, technical vision). If your company already has a culture of documenting most of the knowledge async, this should be a good fit.
Interesting feedback!
The recommended install is already local (through yarn).
The only piece mentioning docker is to provision a Postgres database, which you need to have to run a CRM anyway. We have planned to replace it by a section explaining how to install Postgres on the different OS. Planned for next week!
We are unsure about the right license to use, so this is a great feedback. We had a MIT license one week ago that we know that we cannot hold on long term and we felt we were lying to the community by keeping an MIT license and changing it in one year.
By using AGPL, we feel it's the right level of restriction. It's the license used by Metabase for example (https://github.com/metabase/metabase) that many companies use internally.
Obviously, we don't want to restrict people to self-host the CRM for their own needs.
Yes, as an engineer I am rooting for opensource and to build something that last beyond the company. I also think it will force us to install a good company culture centered around transparency and give back.
They are many example of successful businesses that are emerging while being fully/mostly opensource (Hasura is a good example).
It might be naive but we think it's the right time and we can get investors on board with that.
Yes! https://app.twenty.com . It's still very early but we are happy to share it and to get feedbacks. We already have a few users that are using it on a daily basis and we are trying to get as much feedback as possible to prioritize our roadmap!
Very interesting, this makes sense, it is definitely a direction we could go into. We are using Postgres and were also considering using 1 schema per tenant.
Thank you for the feedback. What you said resonates with me a lot.
Standardized APIs:
While we are designing Twenty, we have in mind to provide three APIs: a GraphQL API (headless), a Front-end React API and a NodeJS API that engineers could use to build their own plugins. We imagine that you could build your plugins in your own repository using SDKs maintained by Twenty. Then on your twenty instance you would be able to install a plugin from your custom repository or a shared marketplace (this would maybe imply a vetting process)
There are many challenges around that, especially in resources monitoring and security given we are going into the multitenant architecture
API that don't assume custom business logic:
Here, we might have a slightly different opinion: we think that Twenty should come by default with a quite opinionated behavior. We will likely introduce a rich library of standards objects and fields that would have pre-defined behaviors. However, we would also enable the users to create custom objects and custom fields if they need that can be customized in whatever makes sense for their business. So: Standard objects/fields + Custom object/fields. We don't know yet if they share the exact same API
We have mainly chosen to use JS on the frontend and on the backend to lower the learning curve for people that would want to contribute / extend it to their own needs.
Then typescript (with its limitations!) it our best shot on top of JS, especially as we are using GraphQL
A middle ground I've encountered in an ERP system (prophet21 if you're interested) was each table had multiple "CUSTOM_XX" columns that were initially blank. Customers could edit their UI and would drag/drop the custom columns onto the appropriate form and change the label to be whatever they'd like. That gave them some flexibility but kept the core schema coherent.
I'm rather worried about having a large table being able to accommodate for any custom object than the fact it is multi-tenant, we could shard by tenant_id quite easily.
I might be missing your point and I'm far from being a database expert. Would you give me more details about what challenge you have in mind?
Yes, agree! We try to re-use as much opensource software as possible. One difficulty is that we are also trying to make it as easy as possible to self host the CRM. If we start including all these tools by default, it will be hard for people who self host to manage all these tools.
Our current plan is to have Twenty supporting different drivers for everything. By default, you only have the basic ones implemented (let's say CSV import + direct connection to Postgres). Then, if you wish and take time to add the right configuration, you can activate Airbyte, Segment...
The same goes for file storage for example: by default we use local storage, but we also make S3 drivers)
On the cloud version, we would of course made all these drivers available.
Thanks for the feedback! We have been discussing this a lot.
Here is one of the option we have in mind for the upcoming months and we would love to know if this could work in your opinion.
Data ownership:
a) Twenty makes the distinction between Twenty owned data models (People, Company, Pipeline) and your own data models.
b) Let's say you use the cloud version: you can plug your own external database as a datasource. You would be able to describe your own data model through config file, Twenty would understand it and will keep in sync your data with the one stored in Twenty. Your data will remain the source of truth regarding whatever is tied to this datasource.
c) So, if you wish to switch to self-hosted, you can, you will have to transfer Twenty owned data to into your own instance through exports / imports. You would not have to transfer your own data as this was already configured as an external data-source.
Extensibility:
a) Twenty is exposing a GraphQL API on top of your data that you can leverage. It doesn't matter if you are using the cloud version or if you are self-hosting it.
b) We are thinking about a plugin system. To enable that, we plan to provide developers API for both FE and BE that will keep consistent between the different versions of Twenty (of course, they will likely be some breaking changes between major versions but hopefully minimal so you can keep using the latest version of Twenty).
c) you can build anything you want using these 3 apis, either an external tool leveraging the GraphQL API, either a front-end plugin on FE API, either a backend plugin on BE API. You will be able to deploy your plugins to the cloud version (we will make sure they only impact your own tenant, which is challenging technically). Here too, if you choose to move to self-hosting, you will obviously also be able to write and deploy your own plugins on your self-hosted instance
So, if we provide stable APIs and are able to safely run custom plugins into the cloud, it doesn't matter if you are using the cloud version or the self-hosted version. As both are using the exact same source code, you should be able to switch between the two quite easily.
If you self-host, you completely own your data, if you use the cloud you don't but you can still fully benefit from Twenty APIs and extensibility.
We've made the bet to invest on a tailored design for our components. Using an existing UI library is a strength to use robust components and move faster, but I've always struggled to customize it.
There is always a point where you want something custom that is not supported by the library and you start hacking into it. On previous projects, I've almost always used existing UI libraries. For Twenty, this is a long term project and the initial burden of creating UI components vs customizing existing ones will be marginal on the long run.
IMO, if you have strong design requirement (and you have enough resources ofc), don't go with UI librairies ; I take as much inspiration as I can from them, I may fork one but I would not hack their API