Hello I have a tough love question, I’m currently comparing Meltano vs Airbyte. I like the answer that you guys provided in Hacker News. I am willing to put the extra effort for the connector to be compliant with Airbyte Protocol vs Singer. However the deeper question is in terms of your future business model. If I spend hundreds of hours creating connectors that are specific to Airbyte protocol and then suddenly I have to pay to use them I will be very very frustrated because that same time I would have spent it using Meltano (or Singer for that matter) instead. Thanks for you help

hey Juan! I don’t work at Airbyte but I’ve read in multiple places on their blog + philosophy that they’re not interested in winning the market this way. With my business hat on, FiveTran and its 50 other competitors are betting hard on building network effects, expertise, etc around integrating with as many data sources as possible (especially the painful long tail!). Airbyte, as far as I know, strongly believes that open source + community is a better way to build robust connectors…. and they’ll instead monetize the STUFF around the connectors (hosting, auth, rbac, reliability, compliance, etc - https://airbyte.io/pricing/).

Understood @Srini Kadamati But now that they have investors, at some point they will want their money back and if the “belief” or the “bet” of the open source doesn’t pay off they will likely move to the same BM as Fivetran that now charges for the amount of data that it’s being moved

Hi Juan, that’s a great question! It’s obviously tough to speak about future changes, however we truly believe open source is a superior approach to tackling integration long tail. The strongest evidence to this is our adoption of the MIT license

@Juan Suarez (MeisterLabs) the licensing stuff helps, we can always pack up and fork the connectors 🙂

In that case @Davin Chia (Airbyte), would you be able to insure that at least the “early contributors” will have some kind of benefit in the future even if you change your BM ?

fair, but I’ll say that every option has its own tradeoffs. • I’m involved with Apache Superset, and part of the holy rules of the Apache Way is that no 1 vendor rules them all. There are pros / cons to that approach, the pro ofc is better guarantee of long term sustenance (although with many projects like Drill, when the main sponsor leaves the commnity often dissipates anyway). The main con is more bureaucracy and sometimes slower pace of innovation. Also, some of the nice-ties (e.g. Airbyte’s UI) historically don’t come out from this approach (since its more by engineers for engineers) • Open core like Airbyte or Gitlab. These companies are investing lots of their own resources and their business success is aligned. But there’s always the risk that they change how they do things. The pro is you get PM’s and designers more deeply involved, and a series company backing the project. The con is potentially more lock in risk.

I can’t promise anything (except the cool swag we give early contributors!). However like Srini pointed out, the MIT license means contributors won’t ‘lose’ any of their valuable contributions. If the worry is time, I actually think we’ve done a decent job with our open source connector contribution experience. Anecdotally, most of our connector contributors take a couple of hours to implement their connectors. Of course we are always here to help and eager to hear feedback on how to better our process!

@Srini Kadamati I agree, I still need to make a choice, and I’d like to eat the cake. And the choice here is between 2 OSS. So the questions is a little bit trickier. But otherwise I agree with the philosophy behind it not only with the open source but the “let’s do it right” part. Thank you for your answer @Davin Chia (Airbyte) I’ll then put my efforts into it 💪

Of course. Really appreciate you reaching out. Please don’t hesitate if you have any questions/thoughts/suggestions 🙂 (FYI, our connector competition might interest you if you were already planning to build some connectors!)

We can guarantee that the core community edition (which right now is just the whole airbyte repo) will stay OSS and free.

I think @Juan Suarez (MeisterLabs) makes a good point. I was an early adopter of FiveTran at a different role and their differentiator was paying per connector, not the volume of data. Investors can influence things.

@Juan Suarez (MeisterLabs) You’re raising some really great questions! My TL;DR is: even if Airbyte disappears tomorrow, you will still retain any effort you put in. Like Charles said: anything that is free right now will be free forever. Same for any new connectors. So even in the “nuclear scenario” where Airbyte (the business) goes away completely, you can create a conversion layer between Airbyte and other protocols/tools you use. This is actually much easier to do going from Airbyte to other protocols than the other way around because we have pretty strict enforcement for connector quality: https://docs.airbyte.io/contributing-to-airbyte/building-new-connector/testing-connectors and so you have a guarantee that everything behaves exactly as the spec says it should. This is not the case with a large number of e.g: Singer connectors. The Singer spec has pseudo-standards that aren’t in the official spec (e.g: https://github.com/singer-io/getting-started/issues/71 ) and no guarantee a Singer connector complies with the spec. This means that if you were to convert from Singer to anything else, you are constantly running into landmines (We’ve had to solve this to support Singer taps in Airbyte)

Thank you for your answers @charles and @s. Although my question pointed in the collectors direction, it’s not exactly that my concern. What I value the most in my life (as everyone) is my time. Not the connectors. So if you disappear or charge for the connectors, I don’t really care. What I just want is to not invest my time doing something that will increase the value of a company, which will at some point make me regret my investment. In that case I prefer paying another company and spend less time doing the connectors, and by doing so knowing what I can expect from my investment on the long run. So, again, the problem are not the connectors but the ROI of my time.

Can you share an example of things you are worried about/would make you regret the investment?

@s Yes I have some that come to my mind : • Tomorrow you decide to charge for the amount of data that transits through the pipelines (like Fivetran is doing now). And people that contributed for free have the same price as anyone else. So I would have spent my time to increase the value of your company without any retribution • The connectors although having good specifications at T0 don’t work at T1 not because of their quality but because the protocol of the service changed. How long to fix it ? Do you plan to maintain the connectors, even if they were created by someone else ? • The (unnecessary) difficulty to create new integration as sources or destinations vs the time required for Singer. Have a stricter protocole I would expect to spend +15-20% more time but if requires 2 or 3 x more time, it would kill the benefits

all fair points! Thanks for sharing this feedback Your feedback about pricing is duly noted :) cc @John (Airbyte) We do plan to maintain connectors even if they were contributed by someone else. Totally agreed with you on dev velocity. It’s something we are actively thinking about.

indeed, fair points! 1. you will always have access to the open-source edition, that includes all connectors. so you will have access to your contribution. and as Shrif mentioned, the team and the community will help maintain. here's exactly what we have in mind in terms of business model: https://docs.airbyte.io/company-handbook/business-model 2. Yes, we are committed. Airbyte only works if its connectors work. Our focus is to get to a point where "it just works". When a connector fails, its users will be notified about it. And the first fix provided by the team or the community would then be propagated back. That's what we have in mind. 3. We're working on a low-code way to build connectors. This abstraction would also help on the connectors' standardization and help on their maintenance. This should be coming soon, in the next few weeks. hope that makes sense!

3. We’re working on a low-code way to build connectors. This abstraction would also help on the connectors’ standardization and help on their maintenance. This should be coming soon, in the next few weeks.

This sounds cool, I’d love to be involved with this effort if possible!

great! amazing @Michel

Got it, thank you @John (Airbyte) and @s