This is an open discussion on how could be a better OSS alternative to Backstage today. Last week, based on hundreds of interactions with platform engineers, I explained why Backstage is so complex - in a nutshell: too many concepts, you need to be a React developer to customise it, it requires you to adapt to their model and not the other way around. Today, I make a proposal on what could be a better open source alternative to backstage. https://substack.com/home/post/p-143537791 The 3 main pillars I suggest: • Ease of use • Low maintenance • Intuitive for developers What do you think? I share concrete examples for each pillar in the article.

Imo, I like your trail of thought and like how things would be configured via yaml. You can then spin up a static portal site, similar to how MKDocs works using CI/CD

Yes, I think we can really make things much simpler than what they are today.

I have seen a lot of your posts on this and think you raise a lot of interesting ideas. One thing that confuses me is your focus on an OSS replacement when backstage is itself OSS? 🤔

Hey @Abby Bangser 👋 sorry for the confusion. Of course backstage is oss. I just wanted to clarify that this alternative will be also oss - since there are a bunch of proprietary alternatives out there.

Hey @Romaric Philogène. That was a really nice read and it perfectly aligns with what I've been designing for a client. I have a quick question: I was mainly focused on using OpenAPI Schema to define the fields that the UI is supposed to create dynamically. Even though I'd prefer a simpler approach, I chose it because it's widely used and also the preferred choice for CRDs. What's your take on this?

Hi @Önsel Akin 👋 , thanks for your feedback - OpenAPI is something that I’m familiar and I personally don’t like 😅 I find the syntax a bit inconsistent and I wonder if it has been designed to be written by humans (genuine question). Besides my personal opinion, here the goal is to make the Portal easily configurable by Platform Engineers (who are mostly coming from an IT background) and are familiar with YAML. So that’s the main reason here. But what’s your take on this?

I completely agree with you on that :) It feels like a YAML-ified version of XSD schemas (kind of exaggerating here, but you get the idea 🙂) So, I'm leaning towards developing a simple yet extendable schema that would be easy for people to pick up. Thanks for sharing your thoughts @Romaric Philogène

Do you plan to open source what you’ve done @Önsel Akin?

Yes, I definitely do, once I see that it works for the client 🙂