3 ms·

I find this trend really interesting, and agree that its one of the potential futures of personal computing. I've heard, on HN, people lamenting that an early

by hazz99 6y ago

I find this trend really interesting, and agree that its one of the potential futures of personal computing. I've heard, on HN, people lamenting that an early vision of computing –– people creating their own applications –– has not arisen. Most people, outside of CS, have no idea how computers work. I think this post, the no-code movement, and products like Zapier show that there is a future for this. People don't need to know how computers work to create their own services – SaaS applications abstract over the implementation details, and APIs provide the interfaces for prosumers to connect them and build their own solutions. I'd be curious to hear your thoughts on Zapier. How do you think we can go beyond "API connector" products?

keithwhor 6y ago
API connector products are pretty much ubiquitous and that's the biggest sign, to me, that there needs to be centralization and consolidation in the market. Zapier, Mulesoft, Integromat, IFTTT, Automate.io, [...]. And then every at-scale SaaS product ends up building their own automation platform internally. The list goes on and on. In a lot of ways it's an extremely fragmented market. Every single one of these products starts out with the same epiphany we had, which is some variation of, "there needs to be an API for APIs...". People keep putting a band-aid when what's really needed is an architectural refactor of how we deliver and connect APIs, full-stop. The problem is there's very little market incentive to standardize how API integration works because it requires the complex coordination of thousands of companies and millions of developers. The barrier to transformation is extremely high, so the catalyzing agent has to be spectacular. A product (or set of products) needs to come along that completely changes the game and creates a real incentive to standardize and adopt a common integration scheme and format. The worst-case scenario for Autocode, as I see it, is becoming just another integration tool for some specific vertical. What we're striving to deliver is an open ecosystem for integrations that's accessible to non-developers who are going to derive the most immediate value from it as an introduction to development, but attractive to professionals as a development target as well. That's an extremely difficult balance to achieve but the rewards are just as large as the problem, technically the entire industry could be made more efficient at scale.
- paulryanrogers 6y ago
  My guess is the devil is in the details. And the more powerful and flexible the more consensus would be needed. Which can slow innovation. Still it kind of echos back to the semantic web. That could be a foundation to empower users and their agents to consume and produce in a more tool agnostic way.
- heroprotagonist 6y ago
  Check out OpenAPI. It's more than just automatic documentation and mocking/testing. Clients can write code to the OpenAPI spec and not necessarily worry about underlying changes to the target API unless they are significant (in which case they are likely versioned anyway).
  - keithwhor 6y ago
    There are a lot of problems with OpenAPI that are more pragmatic than ideological. “If we build to this spec, we get all this for free!” is the dream. It’s not the reality. You’re a large tech company. Your front-end of engineers want to build with GraphQL. Your legacy API is 80% REST with some SOAP endpoints strewn about. Who gets saddled with the job of building to the OpenAPI spec and why? Where is it creating customer value? You introduce it and then what, what value did you actually unlock from your customer ecosystem? I’m not saying that it doesn’t create value — but which stakeholders can you explain that to and how long does it take to convince them? On the other hand, if you start a new company, you’ll find that your API evolves organically. Locking yourself into a specification ahead of time is like writing all the unit and integration tests before a product ever gets in customer hands. Does anybody even want this? Are we even going to expose this API? What if we need to change it? OpenAPI isn’t bad — quite the opposite, it’s fantastic. When we encounter an API that adheres to the OpenAPI spec it makes our lives a lot easier. The problem is what I outlined above: for OpenAPI to permeate the market there has to be some sort incentive so powerful that it spontaneously aligns thousands of companies and millions of developers to accept it as the One True Specification. That’s just never going to happen. So “standardization” can only come from something that creates an economic incentive so great that everybody agrees to it without hesitation. Which is a Herculean effort; it requires something like a product that’s never existed before, or an entirely new class of web developer. When you start thinking down that path you start seeing through our eyes at Autocode. I’m not saying we have the exact right answer today, but I’m saying this is how we think about the space.
A12-B 6y ago
It is hard to make anything significant without that sort of background though. If your business actually is software, and not just a physical business built on top of software, it's hard to see how you're going to make much money by just gluing canned functions together. Either your own ignorance will do you in, or you'll have to hire someone who actually does understand computer science.
- keithwhor 6y ago
  Most of the internet is hastily glued together WordPress pages. People make a lot of money from hastily glued together solutions. In fact, people are making more money from hastily glued together solutions than ever before thanks to companies like Shopify and Stripe, that’s kind of the beauty of it.
  - vagrantJin 6y ago
    A toast to that. Consumers generally dont care about how bad our code is as long as it solves their problem. If theres a price, all the better for it.
- berkes 6y ago
  To add to that: if your entire company is "an idea + a week of learning and combining zapier and ITT" it has no sustainable business model. It may be a neat way to get an MVC or demo out. It may even be the seed to grow from. But you will need to grow beyond this really fast. Everyone can steal your idea now. And if you can learn+build something in zapier in a week, so can anyone: there is no competitive advantage there at all. Which does not mean that your product is no good, just that there is no business-model: the product is basically " free as in beer". The only businessmodel that I can think to service this, is one that makes the "marketing/brand" the competitive advantage. Sell a brand, instead of a product. I, personally, very much dislike these kind of "products", because I believe they hardly are one. Ninja-edit: businessmodel, not development model.
  - keithwhor 6y ago
    Building something customers want is a competitive advantage, whether you do that with Python or JavaScript or a low-code tool is irrelevant unless the problem domain specifically requires said tool.

by hazz99 6y ago

keithwhor 6y ago

API connector products are pretty much ubiquitous and that's the biggest sign, to me, that there needs to be centralization and consolidation in the market. Zapier, Mulesoft, Integromat, IFTTT, Automate.io, [...]. And then every at-scale SaaS product ends up building their own automation platform internally. The list goes on and on. In a lot of ways it's an extremely fragmented market. Every single one of these products starts out with the same epiphany we had, which is some variation of, "there needs to be an API for APIs...". People keep putting a band-aid when what's really needed is an architectural refactor of how we deliver and connect APIs, full-stop. The problem is there's very little market incentive to standardize how API integration works because it requires the complex coordination of thousands of companies and millions of developers. The barrier to transformation is extremely high, so the catalyzing agent has to be spectacular. A product (or set of products) needs to come along that completely changes the game and creates a real incentive to standardize and adopt a common integration scheme and format. The worst-case scenario for Autocode, as I see it, is becoming just another integration tool for some specific vertical. What we're striving to deliver is an open ecosystem for integrations that's accessible to non-developers who are going to derive the most immediate value from it as an introduction to development, but attractive to professionals as a development target as well. That's an extremely difficult balance to achieve but the rewards are just as large as the problem, technically the entire industry could be made more efficient at scale.

paulryanrogers 6y ago
My guess is the devil is in the details. And the more powerful and flexible the more consensus would be needed. Which can slow innovation. Still it kind of echos back to the semantic web. That could be a foundation to empower users and their agents to consume and produce in a more tool agnostic way.
heroprotagonist 6y ago
Check out OpenAPI. It's more than just automatic documentation and mocking/testing. Clients can write code to the OpenAPI spec and not necessarily worry about underlying changes to the target API unless they are significant (in which case they are likely versioned anyway).
- keithwhor 6y ago
  There are a lot of problems with OpenAPI that are more pragmatic than ideological. “If we build to this spec, we get all this for free!” is the dream. It’s not the reality. You’re a large tech company. Your front-end of engineers want to build with GraphQL. Your legacy API is 80% REST with some SOAP endpoints strewn about. Who gets saddled with the job of building to the OpenAPI spec and why? Where is it creating customer value? You introduce it and then what, what value did you actually unlock from your customer ecosystem? I’m not saying that it doesn’t create value — but which stakeholders can you explain that to and how long does it take to convince them? On the other hand, if you start a new company, you’ll find that your API evolves organically. Locking yourself into a specification ahead of time is like writing all the unit and integration tests before a product ever gets in customer hands. Does anybody even want this? Are we even going to expose this API? What if we need to change it? OpenAPI isn’t bad — quite the opposite, it’s fantastic. When we encounter an API that adheres to the OpenAPI spec it makes our lives a lot easier. The problem is what I outlined above: for OpenAPI to permeate the market there has to be some sort incentive so powerful that it spontaneously aligns thousands of companies and millions of developers to accept it as the One True Specification. That’s just never going to happen. So “standardization” can only come from something that creates an economic incentive so great that everybody agrees to it without hesitation. Which is a Herculean effort; it requires something like a product that’s never existed before, or an entirely new class of web developer. When you start thinking down that path you start seeing through our eyes at Autocode. I’m not saying we have the exact right answer today, but I’m saying this is how we think about the space.

A12-B 6y ago

It is hard to make anything significant without that sort of background though. If your business actually is software, and not just a physical business built on top of software, it's hard to see how you're going to make much money by just gluing canned functions together. Either your own ignorance will do you in, or you'll have to hire someone who actually does understand computer science.

keithwhor 6y ago
Most of the internet is hastily glued together WordPress pages. People make a lot of money from hastily glued together solutions. In fact, people are making more money from hastily glued together solutions than ever before thanks to companies like Shopify and Stripe, that’s kind of the beauty of it.
- vagrantJin 6y ago
  A toast to that. Consumers generally dont care about how bad our code is as long as it solves their problem. If theres a price, all the better for it.
berkes 6y ago
To add to that: if your entire company is "an idea + a week of learning and combining zapier and ITT" it has no sustainable business model. It may be a neat way to get an MVC or demo out. It may even be the seed to grow from. But you will need to grow beyond this really fast. Everyone can steal your idea now. And if you can learn+build something in zapier in a week, so can anyone: there is no competitive advantage there at all. Which does not mean that your product is no good, just that there is no business-model: the product is basically " free as in beer". The only businessmodel that I can think to service this, is one that makes the "marketing/brand" the competitive advantage. Sell a brand, instead of a product. I, personally, very much dislike these kind of "products", because I believe they hardly are one. Ninja-edit: businessmodel, not development model.
- keithwhor 6y ago
  Building something customers want is a competitive advantage, whether you do that with Python or JavaScript or a low-code tool is irrelevant unless the problem domain specifically requires said tool.