@atainter56 the Leopard Index System is on the roadmap. Initially our focus is the ACL implementation, and now the deployment and scaleability will be prioritised. Please join our GitHub and Slack Community and be part of the solution.
@gneray we started ory/keto with the OPA implementation, then added AWS IAM conventions. Last year we started with Zanzibar since we appreciate the powerful simplicity and the architecture pattern for wide scale geographic deployment. With the previous approached there were some scaleability problems. Now ory/keto evolution does all of the above. check it out on GitHub.
I think that today's developer tools, such as GitHub, represent the main difference to application developers. The secondary factor is ship cadence and deployment infrastructure. Lotus Symphony was one of my favourites at the time. It was so advanced with its own language "script" when it appeared. It supported add ins, an early predecessor to APIs, and had its own database. But dev tools such as Macro, Quick C, Quick Basic, MFC, Bench, NextStep, and Hypercard. There were many great Unix tools such as Emacs and RCS along with languages such as Smalltalk, LISP, Pascal, and C. And not to be forgotten Symbolics - the beginning of AI hardware. It was a great time to develop software. Anything was possible and everything seemed impossible. There was only some Internet (ARPANET) if you worked at the university like I did, or some advanced research lab, and to launch a product you went to trade shows and advertised in Dr Dobbs Journal. In the 80s we wrote wonderful software, and while as @rozzie says, most of it is gone forever, the innovations live on IMHO.
OSS gives me a chance to work with people I like, to learn, and to contribute to some great software projects. Most of what I do these days is either building or using OSS. Last year I quit my job to do OSS full time with a few friends. Since most big companies see OSS as „free“, it’s not simple to make a living from OSS only. OSS is creative like art. Somehow we need to think differently about compensating indie OSS projects (code, docs, examples, analytics, slack, community, and cloud services) for their work. Free is not so easy. GitHub offers people a way to contribute and there are other ways to donate. It’s usually not enough. We also do some commercial support, and that pays a little. But it’s difficult to get a regular revenue stream. Especially with cloud it’s time to rethink how OSS „works“ for the makers. Maybe there are ways to keep open, and still have some minimum level of money from commercial uses especially from established cloud companies? Still, I love doing OSS and working with so many others that share the same feeling.