What are people's thoughts on the future of no-code platforms with regards to open source? These days as a developer I see that languages where the only compiler is proprietary are increasingly niche, while widely adopted languages have an open source stack. Will the same thing happen with no-code platforms, or are the dynamics different?

I think the closer you are to the end user probably the more you can get away with that type of lock in

My hunch is that the model of Unity and Unreal — where the runtime is a closed source tool but the code and data you're working with are open and portable — strikes a better balance than what no-code is now where everything, code and data, are locked up inside the silo.

Interesting, @Ivan Reese when you say code is portable do you envision competing runtimes that can run the same (no-code) code?

it definitely seems like a concern, most no-code products are SaaS products where the business model is to encourage lock-in.

This is my main reason for not using tools like airtable and notion. I can imagine a sourcehut-like model where the code is open source but most people pay for hosting anyway because it's convenient and there is no lock in.

Microsoft, Google, GitHub, Amazon, Salesforce, Heroku, Apple, …. See a trend? Open source has it’s place in any business, some more than others, but it has zero effect on your business and customers of the product do not care, generally speaking. Don’t get me wrong, I love open source and promote it, however business-wise it posses little to no value. IMO most, if not all, no-code and low-code will have little to no open source software.

@Steve good point re. the list of companies. I guess it comes down to, will companies brining on no-code platforms evaluate them like platforms (Salesforce/Heroku/AWS) where it doesn't matter that they are open-source, or like programming languages. I'd point out that even from that list of companies, TypeScript, Dart, Go, and Swift are all open sourced.

@Paul Butler however, the usage of Dokku and Heroku are embarrassing insignificant when compared to AWS and GCP. I'm proud of Heroku nonetheless

sure, but I'd be surprised if I'm the only one who feels more comfortable building for Heroku knowing that Dokku exists as a fallback

The market is massive. Room for many. I would feel confident and proud to work on Heroku. I personally love the product

Open sourcing the application side of no-code solutions is likely all downside for most companies - only makes ripoffs easier and makes customers constantly wonder whether they'd be better off DIY. Kinda more interested about whether any of the no-code solutions have export & import with specifications and file formats

I don't think import/export that would be possible... The abstract and domain primatives would prohibit it. The amount of work to translate between products would become a product. Turtles all the way down.

An interesting approach would be for a no-code tool to transpile the no-code into a programming language to run, and to allow the user to download that exported code. Similar to how some desktop UI builders (for C++, etc.) used to work. This only makes sense if the transpiling step is a natural part of the no-code tool's design though; the further from code the tool is (e.g. Airtable) the less this way of thinking even makes sense.

I think interchange formats kind of have to be the place to start, otherwise you're just as locked into an open source no-code solution as you are into a proprietary one

Working at red hat I have some unique insights into open source and Nocode tools. By embracing open source culture it makes a really good developer story and makes it much easier to attract good talent, as long as the reason you are doing open source is because of open source of course, and not just saying you support open source to attract new talent as many companies seem to do these days. Open source is also a marketing tool now, for sure. However the term is so big now that it has actually become meaningless and ask 100 different people what open source is and you will get 100 different answers. Anyway, for customers there will be many developers who say they prefer open source because of lock in reasons , even when open source locks them in even more. These developers are mostly advising the budget holders who do not care one bit about open source, only about benefits your software provides.

Well stated Zubair 👏

Non techie users are already locked in by their lack of technical ability, so vendor lock in isn't an additional cost. Techies are not and so vendor lock in is a much larger cost

@Steve sure, I don't think there's a one-size-fits-all model here, but I think there is a space of no-code apps that could be transpiled to code. Excel is arguably the most successful low/no-code/end-user-programming tool of all time, and there are tools to export spreadsheets into code.

We are on the same page here 🙂 I’m not reading your comments as all-or-nothing; and I hope versa vise. I would still bark up the tree concerning the domain abstraction level preventing exporting may have a common graph; wherein there is a point where transpile/export is no longer possible (in full, not in part). I agree Excel is as you say it is, and indeed you can export the spreadsheet into code. This is made possible because the domain abstraction is not very high in the end. The line becomes really really fuzzy when the domain requires multiple systems in seamless collaboration. Excel does not have this.

Here's a story of lock-in in Open Source: https://blog.khinsen.net/posts/2020/02/26/the-rise-of-community-owned-monopolies/ Open Source is a safeguard against lock-in only for those who can themselves assume maintenance of all the Open Source tools they depend on. Which is roughly Google and Microsoft, plus perhaps Apple. The real question is not Open Source or proprietary, but how much a user's application profile matters for the producer of the infrastructure, and of course the long-term survival chances of the producer.

While I agree people underestimate the maintenance burden of OS, there is a meaningful distinction in the degree of lock in. It's not about migrating, it's about tying your viability to another organisation. If everything is open then it is possible to keep running an old version of something, potentially on old hardware, almost indefinitely. There are countless enterprises out there stuck on Java 6. Obviously this slow death is not desirable, but IMO it is a completely different risk to say, Dark getting bought out and shuttered.

@Chris Knott I'd say that's more the difference between local vs. cloud, not open vs. proprietary. I know lots of people who still run Windows XP on old hardware, usually because they have drivers for exotic lab instruments for XP that were never ported to later versions.

Or even just the difference between open, well understood data models and deliberate lockin. I used sublime text for a while, even though it was proprietary, because I would still be able to use it if the company folded and I would still be able to read my files if I stopped using it. Plus the extension api etc were well understood enough that someone would probably just clone it if it died. Similarly for using a proprietary service to host my email, because I can still backup my email with a standard protocol and easily migrate it somewhere else, or use third party software to read it if I don't like the interface. It's still a cloud service but I don't feel locked in. I guess I'm happy to use proprietary tools when they are to some extent fungible.

Yeah, the question of whether no-code tools have a clearly describable data model that can be disentangled from their one implementation is pretty important. Like: software is the lines of code that define the software. Even Dark, you can imagine, because the text code is a 1:1 representation of the internal magic, that you could create another backend. Zapier-style tools, you can imagine a YAML/declarative definition of the workflow, like GitHub Workflows's YAML definitions. But then once things start getting visual… once you can move around nodes & boxes, is that ineffable? Is it position metadata on top of a graph that could be exported? Somewhere in between?

Everything is just bits in the end. I don't think there is some ineffable magic that can't be exported in the data model. The important distinction imo is whether they are willing to define and commit to a data model. One of the defining features of the rise of cloud services is the end of backwards compatibility. Most cloud services own all the user's data and hide the internal details, allowing them to arbitrarily migrate code and data whenever they feel like. It certainly makes development easier and the lockin it generates is just icing on the cake. Compare this to eg apps which store their data in sqlite which has a very stable serialization format and meta-model (sql schema), making it easy to access and understand that data in third party tools. Some cloud services do expose the same underlying api that all their front-end code goes through, which has a similar effect but still takes more work to interact with than a standard interface like sql. Perhaps the rise of graphql will lead to more of this kind of portability.

There's intentional lock-in, creeping lock-in, and explicit design to prevent lock-in, which involves in particular well-documented data models, storage formats, and APIs. It's much like code complexity: you have to fight it actively to prevent it from sneaking in.

Lock-in “creeps in”, because a lot of technology is commercially driven these days, and building on open standards just doesn’t make economic sense in a world where you need to own a platform to make money, or at least make it look like you will at some point in the future. The groundbreaking technologies we still have as foundations, the internet, TCP/IP, HTTP, email, etc. have all been invented without business models in mind. What’s locking us in, and what’s keeping us back in inventing the future are the incentives set by business models and what is considered being successful today.

On the bright side, the desire to own your data is a very real one. Which means there’s economic incentives to helping people own or duplicate their data from “locked in” services. Companies like https://fivetran.com/ help.

@Stefan All true, but as I try to explain in my blog post, creeping lock-in can also happen in an Open Source project such as Python, with no business model. It is sufficient that the developers have some interest in increasing their user base, even if it's for glory rather than money. Ultimately the issue is competitive development, rather than collaborative.

@Konrad Hinsen Sure, strong communities have strong opinions, and it starts to look a lot like a cult, religion, or whatever we want to call it. I would think that this is almost necessary to create a successful community. Overall, I think the aspect of a project being open source is perceived as more important than it really is. Many successful open source projects are practically driven by commercial organizations and their values and economic incentives reflect on the direction these projects take. At the end of the day the real issue seems to be about trust — do I trust the organization to not screw me over, go out of business, and stay aligned with my values? At least with the current commercial landscape you can look at the business model and get a good grasp on what you can expect.

@Stefan Yes, trust is a big issue. In small communities, it is based on personal relations. For business, the business model is a good indicator. For big Open Source communities, there don't seem to be good criteria for outsiders to develop trust.

Re. trust, I think open source software can act as a sort of "poison pill" here -- if a sufficient number of people lose faith in the direction of a project (especially a direction that aligns too much with the corporate steward of the project and not enough with the userbase), forking is an option. Forks are rare because they are expensive and destructive, but the fact that they do occasionally happen (Mozilla Navigator -> Firefox, MySQL -> MariaDB, OpenOffice -> LibreOffice) creates stronger incentives for the corporate stewards not to mismanage them.