Launch HN: Serra (YC S23) – Open-core, Python-based dbt alternative

That was my mistake, not the founders', and I've changed the term to source available (edit: now open core) to try to avoid misunderstanding. I assure you there was no attempt at fraud!

OSI maintains a list of open source licenses which is as close to an industry consensus as you'll find. If a license is on that list I don't think many would say it's not open source.

https://opensource.org/licenses/

That's for software only, if it's an AI model all bets are off.

I understand your frustration.

IME, HN tends to use the term open source in two senses. It can either refer to:

- the license or;

- the business model.

And we know that licenses exist on a spectrum of permissive to restrictive.

So when the community is presented with a for-profit entity in a Launch/Show HN, they tend to dwell on the 2nd sense.

If it’s a side project that’s on display, then the 1st sense kicks in.

Based on this, I’d like to offer the following colloquial interpretations for the terms you mentioned.

1. Open source: permissive (or more correctly, well-known) licenses like MIT, Apache, BSD, GPL, LGPL etc that do not prohibit commercial derivatives (or prevent cloud hyperscalers like AWS from using it).

2. Open core: our code is split into 2 parts: the open source bit (often under a permissive open source license in #1) to attract fellow devs and the closed source bit. The closed source bit is how we plan to make money.

3. Source available: we plan to make money however we see best so as insurance, our code can only be available under an obscure license that was designed to be restrictive.

So, I think what’s really happening is that labelling something “open source” will cause the community to quickly to point out that said license is restrictive.

Congrats on the launch!

Interesting project in a space that I am pretty certain is going to change a lot in the coming years. Here is a bit of random feedback and questions.

* Some of your messaging related to python vs yaml is a bit confusing, which results in me not being immediately clear on the value prop. After digging through docs and code I now understand that the yaml is a declarative pipeline calling the underlying python code that can include user defined transformations. Nifty! As someone who has led data platform teams, I understand that this would be a big win for any data platform team to better support data eng/scientists. But you don't tell me any of that. I would look at trying to give more context to what this is and adding more of these use cases and values in your marketing (even if they are pretty nascent at this stage)

* From the loom, the play you are doing is clear and makes a lot of sense to build a cloud service to easily run these jobs... but that makes me wonder if your licensing choice is maybe a bit too restrictive? IMHO, the most important thing to do when building dev tools is to be very deliberate in your end-to-end user -> customer journey and designing your open source and commercial strategies to nicely dovetail. For a product like this, I would think the faster and bigger I can build a community, the better, and that may mean "giving away" a lot of the initial core innovation, but with a clear plan on the innovation I can drive through integrated services, which would imply as open as a license as possible. As is, I think you might find it much harder to get people to take it serious, as, unlike other source available companies (Elastic, Cockroach, etc) you aren't yet proven to be worth the effort to get this approved vs a full open source alternative

* On a similar note, what is in the repo right now seems to be a relatively thin wrapper around spark. That isn't a criticism. Many technologies and communities have started based on a "remix" of a lower level tool that offers simplified UX/DX or big workflow improvements. What sets those apart though, imho, is to drastically lower the barrier to entry to using the underlying technology and to be seen as leaders and experts in the space you operate. I am guessing you probably have lots of features planned, but I would also give a soft suggestion to look as much into thinking of learnability as a feature (via features, interactive docs, etc) as I would almost anything else, as that is really where a lot of the value of a higher level interface like this comes in

* My past experience with really large and complex ETL jobs that essentially required dropping into spark to represent them has me wonder how much actual complexity can be represented by the transformers? I would be curious to know what your most complex pipeline is? It doesn't seem there is an API limitation why these pipelines couldn't get quite a bit larger and represent many sql statements, other than big long spark pipelines getting kind of ugly, and in some cases, could even remove the need for quite a few airflow jobs. I am curious to know if and how you see Serra addressing those sorts of problems like those types of ETL jobs.

Once again, congrats on launching! Happy to give more context/thoughts in a thread or reach out to me via in profile

These are all great points, and no, Disney didn't use dbt. We wanted the demo to show how you can modularize SQL into reusable objects that you can fully customize error logs for, while also adding the value of handling all steps of ETL in-house. You could definitely write this script modularly using dbt, but we feel like that value add of having connectors that easily integrate with your transforms (e2e), as well as taking the software engineering best practices that dbt applies a step further by turning each transform and connect into objects that you can test, modularize, and customize error logs for is our main differentiator.