I'm a developer myself, and I think that this is the wrong approach.

I'd talk with all of them and help them build multiple teams, by identifying leaders and we'd try a couple of business models. You don't need that many developers to work only on one thing.

Only down the road, when you have something that resembles more like a product and a proper team that increasing headcount will yield more work done. You need to build and grow the team based on the scope you've got.

It goes without mentioning that you need people from other areas, like sales, to do anything useful.

I think the question would be.. If you and a team had heaps of cash and time and could build anything, what would you?

60 John Romero, John McCormack, Elon Musk, Bill Gates grade programmers in their prime, 60 sci-fi concept artists/directors/sciengineers, 60 in financials and office worker wildcard jokers of the pack, 6 years to first demo, 3 year margin in case of out of control delays. Implement the HAL9000 with IBM in command of Tesla Dojo Pods in control of armies of Tesla Optimus bots for the U.S. U.K Army given the prime directive to defend the oil refinery plant in Saudi Arabia using renewable solar and battery store capacity or mobile nuclear. Shootdown swarms of drones with laserbeams and railguns. Calling in airstrikes or any manned machine is outside the rules and considered cheating.

100 developers in isolation without product definition, project management, marketing, sales, etc. isn't going to prove fruitful. It would be like asking what 100 carpenters would work on, absent of an architect/project plans, plumbers (are those DBA's in this analogy?), electricians, roofers, realtors, etc. you're going to get a bunch of random walls, stairs and some framed structures. I would expect similar output from 100 devs - random bits of software.

Depending on skills the easiest path to success might be to open a developer consultancy type of shop where they work on other people's projects.

A user friendly easy to configure data diode with proxies for all the protocols we could get done in time. A second isolated duplicate output would be a standard feature to be supported. (So you could safely tap and log all data flow)

People don't appreciate how secure things can be if you use these correctly.

Having trouble understanding, the idea is you're funnelling multiple protocols into one pipeline with multiple actors on the other end?

A data diode is a unidirectional network link. You can ONLY put a packet through it in one direction, and never, ever, get an ACK or anything back. Usually they are accompanied by a pair of helper hosts, one on each side.

The source host polls a desired set of things in the network it can access, and puts them all into an internal buffer, and transmits that data, plus a lot of forward error correction, and KEEPS sending it, to the matching destination host.

So, if you have an industrial system, such as an oil refinery, production line, etc., you can have the source host poll for status from the PLC, etc... and then forward that data to the destination host outside the firewalls, etc. Remote users will be able to view the status of things as they get updates, using web or whatever protocols you like, but have ABSOLUTELY ZERO chance injecting data back into the industrial system.

It's simple enough in theory. But widely underused in practice.

I guess it depends on the type of developers. If we are to generalise I believe that we would let about ~25 (or a quarter) just create new things on their own, like let them ideate, and build their own ideas that can possibly be big or really innovative things (obviously aligning with the company mission/objectives). You can see very often the creativity of developers being absolutely suppressed by boring or very straightforward/linear projects that leads to very little excitement from the people developing or implementing them. The rest would probably go to making those potential bold ideas happening and keep on building a great product with input from users.

note: this is possibly only viable with a large enough number of devs (>100) and enough money to spare.

I’d fire the worst 90 and then do something real with the others.

There is an old joke. A client asks an old developer: Can you build me a site in a couple of days? Yeah, sure, he answered. And in a couple of weeks? I have to think about it, but that’s doable, said old man. Okay, but can you build a site in a couple of months? The old man scratched his head and said: Well, I’m afraid for that we’d have to hire a team.

-

I guess the answer to OP is “a site”?

I might consider replacing UNOS with a better system. Something that is both secure and organised. (no pun intended)

Humm.. An AI system for teaching reading and math to kids. Something that would learn where the student is weakest and adjust automagically. I might even include teaching kids to code. But as a game like system.

If they had the skills to work with the packages and knowledge I would have them work on OpenWrt. My fave SW at the moment. I would have them fix any outstanding bugs. All so have them get it to run on as mutch HW as they could get it to run on to stop old routers and APs from going to land fill.

I'd create a laptop for power users and a new OS to go along with it.

Open source Winamp clone. Wait does your hypothetical require that we have something that will make money?