2031 - A Software Engineering Utopia

It's 2031. Software engineering is on a new level. Open APIs and SaaS apps, funded open-source and an open cloud platform accelerate teams. We join Naomi, Javier and Kalina developing a new product in this environment.

It's July, 16th 2031, 8:00am.

Naomi is getting ready for the day. She will start today engineering a new project in the area of accessibility. Ten years ago it would have been tough to get funding for such a project. There is not much money in that market and projects used to focus on where the money is. But ever since the "Common Open Source Funding Foundation" (COSFF) was founded, this has changed. Almost every big company is contributing funds towards this foundation now. In exchange they get partial access to its unique talent pool, besides getting naturally free access to the developed open source.

Naomi is employed by the COSFF. But she is free to choose from the projects of the sponsoring companies. Also, from all the social, ecological and open-source initiatives that are participating in the COSFF as well. Since the sponsoring companies are providing the funding, she is obligated to spend 40% of her time on the projects of the those companies. 20% of the time, she is free to use. Some people use it for blogging, others to educate themselves, others use it as additional time to recover or to spend additional time with their families. The remaining 40% of her time Naomi can use for the social, ecological and open-source initiatives that she wants to advance. After working a year at an initiative to decentralize power supply and storage, she has now decided to move to this new project for accessibility.

Naomi logs in online to talk to her team. They are a newly formed team of three people that will bootstrap an initial prototype. Naomi, as a software engineer, is focusing more towards the engineering aspects. Kalina is the manager and representation to users and Javier is the designer. Also Kalina and Javier are employed by the COSFF and the three of them have worked on projects together before.

• Kalina: So, I got the budget setup in the budget planner. They use the open cloud platform here internally for development, which makes sense: Our project is acknowledged as a social initiative, so we can use it for free. Outside the company, the application is of course expected to run on all cloud platforms, so let's adhere to the open standard for cloud platforms. Then we have all platforms covered.
• Naomi: Hehe, all platforms...
• Kalina rolls her eyes: Also Amazon will finally get to it. They have realized that they won't keep their competitive advantage if they reject the standard. They are working towards it. If we develop against the open standard, then Microsoft Azure, Google Cloud, Apple Cloud and the open cloud platform will all already work. Well, and AWS eventually.

One of the bigger open source projects that came to live through the COSFF is the "Open Cloud Platform" (OCP). Ten years ago there were two main players on the cloud platform market: Microsoft with Azure and Amazon with AWS. Other companies like Google were trying to push into the market, but weren't really able to establish themselves. That changed in 2025, when Google came together with smaller cloud providers to create an open standard for cloud platforms. They founded a consortium and defined what a cloud platform is and what functionality it needs to offer in which way. They standardized how infrastructure is defined as code, how personal identifiable information (PII) needs to be stored and how users can access it, how the APIs to access application metrics look and how meta data on the used libraries and third-party software services is accessed. This gave Google and Oracle a competitive advantage. Because of the open APIs, third-party companies were able to build helpful products on top: Some to gain insights from application metrics, some to analyze GDPR aspects, some to find performance bottlenecks. These companies were now able to build products for cloud platforms that adhere to the open standard. Before, they needed to integrate with each cloud platform on its own.

• Kalina: Do you see the architecture as similar to one of your previous projects?
• Naomi: You mean: Can I just copy some files from an existing project and make some magic happen?
• Javier: Well, you can, am I guessing right?
• Naomi: It's actually pretty much a standard single service setup what we need right now. I couldn't do a setup yet since the budget wasn't approved yet. But I can use my standard template repository and bootstrap it from there.
• Kalina: What's included with that?
• Naomi: It's a CDN-deployed frontend based on an SSG, a dynamically scaled microservice with a document-based database. User management including GDPR-compliant PII management, application and user metrics collection with some customized dashboards and an application for DB monitoring.

Javier looks at her confused.

• Naomi: It's a web page. We'll use an existing user management system and some systems to get insights into our app. I would suggest to add the 'SaaS hosting dashboard' and the 'SaaS cost dashboard' directly. The 'SaaS payment processor' we can add later on, doesn't really add a lot of value until we have first users where their payments in various currencies need to be processed.
• Kalina: The 'SaaS hosting dashboard' and 'SaaS cost dashboard' are already globally setup for the company.
• Naomi: Ok, great, then I exclude the files defining the overall setup and only include the two files that setup the two team-specific dashboards. Then we'll have an overview of our own used software and the cost associated with it.

Of course, not all functionality provided by cloud platforms is part of the open standard. The open standard only defines the minimal requirements on specific aspects that a cloud platform needs to adhere to. Different cloud providers continue to develop unique selling points that give them a competitive advantage. For example, monetarization was first developed by AWS with the 'AWS Payment Processor'. Soon, other cloud providers saw the value in it and developed alternatives. After two years, Google, as a key driver of the open standard, pushed to make monetarization one aspect of the open standard. Since then, new products like the "SaaS cost dashboard", the "SaaS budget planner" and the "SaaS payment processor" have been created on top of that standard. All these products work by default on every cloud platform. There is even a product to automatically create a tax report and send the according telefax message to the responsible government agency.

• Javier: Can we also add this new cool component design tool? It's supposed to be really great since I can describe the components vocally and get both an initial visual design and a textual description that I can version with together with your code.
• Naomi: Sure, just added it. Should be provisioned on the cloud platform in a minute.
• Kalina: Wait, what does it cost?
• Naomi: It's payment-by-usage and you should see it on your cost dashboard now. It's, like, 15 bucks a month for the three of us, can this be correct?
• Javier: It's open source. The majority of the funding comes from the COSFF and since we're acknowledged as a social initiative, it's even less. We only need to pay the one third open source maintenance part, the two thirds for hosting on the open cloud platform isn't required to be payed by us.
• Naomi: Ah, yes, alright, it even says here in the dashboard. Would be 60 bucks if we wouldn't be acknowledged as a social initiative.
• Kalina: I got a warning here that it doesn't manage personal identifiable information compliant with GDPR. 'Do you use this application as a customer-facing application?', it says.
• Naomi: Sorry, forgot to specify this in the setup code. You can click 'no' and it will commit the change back and the warning should be gone. Few other things... I'll add 'sgit' support on GitHub. This will track all our structured data semantically, which makes reviewing stuff way easier, since we'll see semantic diffs instead of changes line-by-line. Even outside the application code, it should help you with the work item definitions in the product management tool.
• Kalina: Apropos, product management tool...
• Naomi interrupts: Oh no...
• Kalina ignores her and goes on: I know you like to work with your fancy text files but I want to work in a nice web UI.
• Naomi: That's supported with 'sgit' now. Since the work items are stored and versioned semantically, it can be displayed in whatever way the viewer likes to see it. If I look at the work items in my code editor, it is really just a view on top of the semantic data. If you look at it in the browser, it is a different view. Hell yeah, I think that there is even a retro version of Jira that works as a view of it, if you really want to shoot yourself in the foot.
• Kalina: Oh... thanks, I guess? I'd rather go with the lightweight PM-View instead. And the integration with the 'Open Objectives' still works?
• Naomi: Let me check... Yes, 'Open Objectives' doesn't care where the work items are persisted as long as they adhere to the format of the 'Open Work Item Standard'. Do you want me to include the setup of 'Open Objectives' such that it gets provisioned?
• Kalina: Yes, please. It will be important to keep users informed, especially since we receive public funding. It will also allow us to get easier into contact with people with similar objectives.
• Javier: So, what are our objectives?
• Kalina: Let's take a break first and clarify this later. We made good progress setting up all the tooling and can go on defining our vision, objectives and how we measure that we are accomplishing them.

Sounds good. See you then!