Congrats on all your hard work! Those are some impressive libraries. I come from an OSS background, it’s what started all of this, so I appreciate the hustle and contributions! The project that spawned all of this was a Node.js framework for easily building APIs that went viral here four years ago [0].
If it helps clarify, Autocode is for people looking to solve integration problems (A to B) for businesses easily. We can talk all day about which specification we use, but that argument is adjacent to the fact that the combination of tools we offer are faster by one — if not two — orders of magnitude at just delivering business value — a finished software product that connects A to B (to C to D).
We’ve spent years of work developing this tooling and thousands of hours talking directly to both API companies and end-users about what they need. This is the result, and we’ve worked at making sure the tools we use — even if bespoke — are open source for others to learn from [1].
P.S. If this is your jam, reach out! We are hiring :)
Thanks for the kind words. I don't drop those links to brag or troll for compliments, to be clear--more to establish bona fides. I've spent a lot of time building stuff for an open and interconnected web. I think you should be, too. But it looks like you aren't, and that sure seems like a real bummer.
I get that it's both unsexy and probably a little uncomfortable, but the thing is, the demand for control that you're expressing here by going against open and collaborative standards really and truly does matter. Like--fundamentally and inescapably, the messaging I'm getting from you is "it's 'open source' but we demand to own it." Why do you need to own the specification to do what you do? What is OpenAPI stopping you from doing? Did you try to work with the OAS folks to improve it to enable whatever (if anything) can't be expressed? Did you evaluate stuff like vendor extensions to it to express those things?
I get that the core of your Standard Library is open-source--but "open source" and "community collaboration" are pretty far apart. I understand the process for OpenAPI's evolution and change over time. What's yours? Whose commits get in? Who decides?
I realize that the likely answers to these questions are trivial in the power-politics/realpolitik sense. Which is why my hackles are up, TBH. Not playing in the sandbox with all the other kids is a clear indication that you have it in you, whether you are or not right this second, to raise barriers to entry against anyone else who'd consider doing something with your tech. And that leads to a fragmentation ("welp, we'll have to fork") that this space well and truly doesn't need. If this was using standard tools and standard approaches--which all totally work with this, by the way, I've written a simpler but spiritually similar thing just by using openapi-js to dynamically generate clients--I'd be cheering you on. As-is? This sure looks like pissing in a community pool for your own benefit.
How am I wrong? (Because, to be clear: I'd love to be. Stuff like this is important.)
This may be a little different than you expect: OAS didn’t meet our needs for defining serverless function schema semantics.
We considered an open approach, but we then watched numerous small companies die trying to convince standards bodies to adopt their innovations. Like, raised money, convinced nobody, stagnated or died, and highly paid engineers at BigCos that were unintentionally unempathetic to the excitable new founders — whose dreams just evaporated in smoke — kept attending open spec design-by-committee meetings with little forward progress.
So we decided to work directly with API companies — not standards bodies — and figure out how to deliver the right product(s) to solve real customer needs.
That’s all there is to it. We stand on the shoulders of giants and we certainly love working with companies that adhere to existing standards — as mentioned, the things we’ve contributed are completely compatible! We don’t have an ego about our specifications, we just have a desire to deliver value and not die — and waste the most productive years of our lives — waiting on standards bodies.
Can you elaborate on how OpenAPI didn't meet your needs for serverless function schema semantics? Because if OAS3 doesn't meet your needs, it clearly needs revision. I'm very happy with my current gig, but I'd certainly be interested in contributing to the OpenAPI specification to be enable it to be flexible enough to express what you need it to express. The community of open and collaborative APIs doesn't need to be fragmented to do encompass whatever's concerning you, does it?
I'm happy to make that offer because, frankly, I have also spent a pretty long time observing the OAS3 work, and it is not a committee where things get "bogged down" for years. The characterization strikes me as pretty unfair--the prevailing attitude certainly seems to be open, inclusive, and driven towards solutions. Everyone wins when the OAS stuff gets better, so the drive is to just do that. It's not an XML standards body or something.
Beyond that, OpenAPI certainly doesn't require a company to adopt a single thing about it in order for somebody to write a spec and to generate a client from that spec. It helps, but there's no need to advocate anything. It sounds like a misdiagnosis to claim it as the reason a company would fail as an integration partner given the significant help that being able to work directly with that company actually is.
Tearing down OAS for what have to be pretty minor flaws (and I use "minor" judiciously; if they're impactful upon "serverless function schema semantics", it's a niche of a niche--and AWS's API Gateway sure doesn't seem to have a problem building OpenAPI specifications off of serverless functions, either via import or export) and a downright fictional characterization of the process of its evolution is really unfortunate.
There are thousands of companies with production APIs that don’t adhere to any specification, let alone OAS.
On top of that, Companies that were considering OAS now have GraphQL APIs instead — or even JSONAPI. When we need to respond to the needs of one of these companies, we need to move quickly.
I think we’re just comparing apples and oranges. We’re working on solving API integration issues in a real way, which means we build the tool for the job. OAS is an idealized, democratic position that — while absolutely a best -in-market solution — does not directly and meaningfully incentivize companies to rely upon it.
As 'codegladiator indicated, OpenAPI is descriptive, not prescriptive. If you have an API that cannot be described in OpenAPI, that is a bug in OpenAPI. And personally, I've literally never seen an HTTP-based, non-GraphQL API that cannot be expressed, and fairly easily, in OpenAPI and even in a subset that can generate programmatically "acceptable" to "great" API clients in a variety of languages. Heck, it's not even that hard to make a RPC-based API with XML as its lingua franca work just fine in OpenAPI.
Now, you're correct about GraphQL, but it's also apparently not super relevant, as the APIs you're trumpeting on your site are overwhelmingly either RESTful or adjacent to RESTful. But even so? You could pretty easily have vendor extensions (`x-` properties) for GraphQL--ones that in the future maybe even become canonical ones!--in OpenAPI while using it for standard APIs, an approach whose deficiencies you've consistently chosen to retreat from after you state them.
This fundamental misapprehension about specification versus description, and the way you dropped your "serverless function schema" claims like a hot rock (and I want to underline that the offer to work to improve OAS wherever it happens to lack is genuine and is work I am very happy to do) and the absolute unwillingness to address any question that touches on your obvious attempts at barriers to entry, frankly, makes you think you're just bullshitting me.
I'd like to wish you well, but you have demonstrated to my satisfaction your intent to piss in the public pool for your own benefit. I wish you wouldn't be so bound and determined to do so.
To be direct, I don’t really understand your criticism — we’re a small team working like crazy to create value for folks. I get that you don’t like the way we’ve implemented our own specifications, and that’s okay, but to be honest I’m a little offput that you’re accusing me of bullshitting when I believe I’ve been straightforward with you.
If you’d like to use the product / platform and work with us to make things better, we’d love the support!
If it helps clarify, Autocode is for people looking to solve integration problems (A to B) for businesses easily. We can talk all day about which specification we use, but that argument is adjacent to the fact that the combination of tools we offer are faster by one — if not two — orders of magnitude at just delivering business value — a finished software product that connects A to B (to C to D).
We’ve spent years of work developing this tooling and thousands of hours talking directly to both API companies and end-users about what they need. This is the result, and we’ve worked at making sure the tools we use — even if bespoke — are open source for others to learn from [1].
P.S. If this is your jam, reach out! We are hiring :)
[0] https://github.com/keithwhor/nodal
[1.0] https://github.com/FunctionScript
[1.1] https://github.com/stdlib