Twenty VS copybara

I had the opportunity to work on a github issue in an open source project to add a Github workflow that runs if some files where modified in the path packages/twenty-website and checks that the website is still building.

You should check out Twenty! https://twenty.com/ (YC S23) -- they're an OSS CRM.

I totally agree the object management UI is too clunky right now. I want to redo that set of pages, they were the first ones we shipped. Not gonna lie, idk if anyone except me and Ned are really pining to learn hotkeys for managing object schemas, since in practice we're the only ones doing that on a regular basis -- we do initial setup on behalf of our customers.

Yeah, I consider latency part of UX. We're doing some somewhat fancy stuff to reliably replicate every record into a couple of stores, each of which is optimized for different access patterns (search, get latest by ID, etc.). The big central Postgres(TM) is mostly there to be authoritative and to transactionally maintain invariants in the system.

Open Source software will never be able to monetize as well as closed-source. We might only capture 10% of the value we create. But being open source inherently creates strong network effects that tends to push towards a limited number of winners, and the addressable market in CRM is so big that it's still possible to build multi-billion dollar company while massively driving the costs down for everyone.

It's kind of like the Prisoner's Dilemma: If every company keep their software proprietary, they can all make on moderate growth/profit. But if one goes open-source, they could attract a large community, drive innovation, and potentially reap long-term profits while reducing the overall market size.

[1] https://github.com/twentyhq/twenty

Twenty- A modern CRM offering the flexibility of open-source, advanced features and sleek design.

Twenty: https://github.com/twentyhq/twenty/pulls?q=is%3Apr+author%3A...

Our main technical challenge has been securing code sharing. One solution was building GitSlice, which enables creating sub-repos that sync with the upstream repo. When GitStart devs create PRs on the platform, GitSlice syncs them upstream while pulling back CI/CD checks and review comments. This enables our devs to contribute with limited codebase access.

To prevent slices from breaking, we verify they run within a docker container, which also enables us to build review environments. Fun fact: we managed to support native iOS and Android codebases by building and running them on appetize.io instead of docker.

There have been countless attempts at this space so we would love to hear your feedback on how we approached this problem or your past experiences working with junior devs in this way. We look forward to a good conversation!

Interesting, the UI looks the same as Twenty ( https://twenty.com/ ), that was shared on HN this week.

Sorry about that, it's not an intentional dark pattern, just the result of a very short timeline to build this. I've just created an issue to prioritize this soon: https://github.com/twentyhq/twenty/issues/774

We are trying to be conscious about data privacy too (e.g. no tracker or third-party cookie on our website)

sure! it used a collection of tools, the main ones were

* copybara [https://github.com/google/copybara] to mirror between github and our internal repo and transform the source tree layout to our internal conventions

* mercurial patch queues [https://hgbook.red-bean.com/read/managing-change-with-mercur...] to apply internal changes

there are internal tools to automate the copybara configuration for python packages specifically, and to map between mercurial and google's version control system, but that's the main idea, and a specific review process for adding new packages.

the process is actually documented here though not all the referenced tools are available (or even applicable) externally: https://opensource.google/documentation/reference/thirdparty...

Step two of installing Copybara is to install Bazel [0], so that doesn't exactly contradict my claim that if you're not already using Bazel you probably won't use Starlark.

[0] https://github.com/google/copybara

> Also, they have a bunch of tooling to manage open source projects that mirror google3 projects. ... if I recall correctly the tool itself was open sourced too.

https://github.com/google/copybara

You can potentially use CopyBara https://github.com/google/copybara

We go much further than CopyBara by syncing CI / CD pipelines, syncing review comments and so on.

We are considering launching GitSlice as product on its own. If you are interested, email me and I can keep you updated when its ready to test (hamza [at] gitstart [dot] com)

I haven’t seen much info regarding their setup, aside from the bits about Pants and Bazel.

Are those actually the upstream repositories, though? And is it known how they interact with them?

Google has Copybara [1], which allows portions of a monorepo to live outside as an entirely separate repository without the need for things like Git submodules. It supports synchronization of histories, pull requests, path and file transformations, etc.

In that sense, something like Copybara would allow them to, relatively, easily open source those bits, receive outside commits, and then sync the changes back to the monorepo.

[1]: <https://github.com/google/copybara>

Take a look at https://github.com/Olivr/copybara-action and https://github.com/google/copybara

I use copybara to sync them, and once I go through and audit them making sure that they're not causing any breaking changes, will release it and then update the code that depends on it.

Another option is to use Copybara (https://github.com/google/copybara) to create a light-weight version of the repo from the local repo, and then push that. The problem is that it will be push-only. You won’t be able to pull. Again, a pain in the ass.

Also you may want to try developing in a monorepo. If you need to publish them you can use stuff like Copybara / Copybara action to push them to individual repos