List out the software lifecycle phases that we supply by default

[inverted-capital]

With every object we supply at least the following lifecycle solutions:

1. Ideation
2. Market Segmentation
3. Prototyping
4. Recruitment
5. Fundraising
6. Build labour
7. Infrastructure
8. Support
9. Sales
10. Revenue
11. Equity
12. Updates
13. Resale (selling to a different purpose)
14. Backups

As suggested to us, we should diagram these up, and compare that to traditional ways to manage these lifecycle phases, with the point being the people, time, and effort that gets cut out of the system by supplying full management up front.

breaks out from #53

[TartanMalcolm]

Could add:

15. Bundling - combining pre-existing objects to create new value through their combination
16. Demand discovery and validation - starting with demand and working back to an Idea
17. Idea validation - starting with an idea and validating that someone out there has previously undeclared demand for it
18. Coordination - previously known as management, now is self-organising as it's permissionless
19. Licensing - through the DCL and extensions

I've been working on an idea as to how to diagram all this using Feynman style diagrams. Not there yet, but possibly there's a really sweet shorthand there. The whole point of Feynman diagrams are to reduce complexity to a simple time axis where states and objects can be linked in a chain of forces and consequences.

Will see if I can get it clearer than that by the next call, or rule out that idea. Don't know which it'll be yet

[TartanMalcolm]

Have moved what I previously wrote here to Discord, https://discord.com/channels/905191169498157159/905191170198609942/972140432643465350

[panick-carousel]

For the labour component I want to draw a parallel between in house staff being like having inhouse baremetal. Then having EC2 servers is like having outsourced contractors like what we had in Kharkiv, but the ultimate is serverless functions style where it appears like a new staff member for each individual task.

That should lead naturally into the parallel and elastic abilities you mentioned of how we handle the "workload" vs traditional baremetal style staff.

[inverted-capital]

I want to strongly show the connection between fungibility of compute using Interblock, and fungibility of labour and equity using Dreamcatcher. We can use the evolution of cloud computing as pointing towards full fungibility, and show trends in labour methods as pointing towards fungibility too.

We designed the Dreamcatcher as a reaction to the destructive political problems we had when we had a blockchain that even partially seemed feasible, but as #53 points out, we never really show the history of how we arrived at even wanting the Dreamcatcher in the first place. We should somewhere, somehow, show why we need the Dreamcatcher if we are to have any hope of building and sustainably maintaining a blockchain large enough to be considered universal compute.

[TartanMalcolm]

Something along these lines? Funding line is a bit clunky and naming needs worked on, but really like the idea of paralleling tin->serverless you mention above.

[inverted-capital]

I have absolutely no idea how this diagram relates to what we're trying to express