something i fear a lot is a piece of planning software that doesn't understand things. computers are fast, not smart.
imagine a simple approach of an IO table with every commodity in it. we could (using say the NewHarmony algorithm) get the total amount we'd need to produce of each commodity for any given final consumption we desire.
but we have issues. just because we need, say, 400 hammers, does not mean the factories making hammers can make them. what if there isn't enough labor time within a commuting distance of the hammer factory?
so then you program in location. and maybe you have have "households" as an industry producing labor power and you set its inputs as the minimum standard of living and whatnot. well now the software has no idea if there are enough trucks or roads or boxcars to get the raw materials *to* the hammer factory.
so now you add in every delivery route as a "commodity" as well. but then now you're really boned because if you're actually going to include every possible transit route, you'd need an insane amount of new commodities. For the US alone, there are around 1 million factories and 1 million retail storefronts. so you'd need 2 million * 2 million routes.
doing less than this and only existing routes tho leaves you open to extreme inefficiencies. what if the hammer factory isn't getting wooden handles but instead raw roundwood? that's horribly inefficient since around half of the weight of roundwood is removed during manufacturing into useful products like handles or boards. the software would assume that shipping entire roughhewn logs to a hammer factory is the only option.
the answer, in my opinion, is a piece of software that doesn't need to know all this but instead *could* know it. the workers actually doing their job will know more than we or the program ever could from on high. we don't need to put in every possible transport route, only the relevant ones. and instead of training a computer to figure them out, why not just let the people who actually do the work and already know be able to put them in as they need?
i expect that all the software would actually end up outputting is the total amount of inputs needed at a place in a given time period and the total amount of expected output from that place for that time period. the knowledge of shipping costs and rail routes and road capacity and all the rest could be put in from an outside source as constraints on the optimization.
I think that in terms of fundamental principles you'd want to develop the accounting system. There are essentially two fundamental parts of such a program that you'll need to get down - the accounting side and then the planning decision making side, which must be built on the former.
Users should be able to create defined categories, like in Quickbooks, for the different inputs and outputs used in production. If we're thinking of this as double entry accounting, for goods that were not acquired on a market you would have to include the inputs required to produce them or traded for them if it's a direct exchange with another enterprise. This also means that when you produce the final outputs for the enterprise, you know what the inputs were required to produce it.
On top of the accounting system you have the planning system, which allows you to estimate what technical coefficients you'll have and iterates on those as it gets real data, and spits out several bundles of different combinations of goods you can produce with your given budget of resources which you can choose your production targets from.
Additionally, maybe you can have a consumption planning software which issues tokens for the goods produced based off of user defined rules. It should be flexible enough to create different tokens/pools of consumption goods.
this is very inciteful. i definitely think you're right that the accounting module of the program should come first.
one idea could be to base it on this wonderful tool for the game factorio (that is if i'm understanding you correctly. i've only used quickbooks as a worker to log time and never for any analysis).
but we have issues. just because we need, say, 400 hammers, does not mean the factories making hammers can make them. what if there isn't enough labor time within a commuting distance of the hammer factory?
so then you program in location. and maybe you have have "households" as an industry producing labor power and you set its inputs as the minimum standard of living and whatnot. well now the software has no idea if there are enough trucks or roads or boxcars to get the raw materials *to* the hammer factory.
so now you add in every delivery route as a "commodity" as well. but then now you're really boned because if you're actually going to include every possible transit route, you'd need an insane amount of new commodities. For the US alone, there are around 1 million factories and 1 million retail storefronts. so you'd need 2 million * 2 million routes.
doing less than this and only existing routes tho leaves you open to extreme inefficiencies. what if the hammer factory isn't getting wooden handles but instead raw roundwood? that's horribly inefficient since around half of the weight of roundwood is removed during manufacturing into useful products like handles or boards. the software would assume that shipping entire roughhewn logs to a hammer factory is the only option.
I think what you'd need to do is make it so that every discernable production unit has their own "books" which then connect to each other depending on the supply line as well as send info back to central planners if they exist. Ideally, this software can be useful whether or not there is any vertical hierarchy organizing things. Having separate books is also important for auditing purposes and holding each autonomous unit accountable. It would also mean that commodities can exist at multiple levels of abstraction as defined in the books within the accounting software. A hammer can have logs as inputs or wooden handles depending on the granularity of the books of the enterprise. Maybe for birds eye view planner it's better to see the inputs as logs, but better for the factory to see break them down into hammers in their records. Conversion factors can be stored somewhere centrally with technical production coefficients, with an eye towards making them more efficient, perhaps using blockchain technology.
but we have issues. just because we need, say, 400 hammers, does not mean the factories making hammers can make them. what if there isn't enough labor time within a commuting distance of the hammer factory?
so then you program in location. and maybe you have have "households" as an industry producing labor power and you set its inputs as the minimum standard of living and whatnot. well now the software has no idea if there are enough trucks or roads or boxcars to get the raw materials *to* the hammer factory.
so now you add in every delivery route as a "commodity" as well. but then now you're really boned because if you're actually going to include every possible transit route, you'd need an insane amount of new commodities. For the US alone, there are around 1 million factories and 1 million retail storefronts. so you'd need 2 million * 2 million routes.
doing less than this and only existing routes tho leaves you open to extreme inefficiencies. what if the hammer factory isn't getting wooden handles but instead raw roundwood? that's horribly inefficient since around half of the weight of roundwood is removed during manufacturing into useful products like handles or boards. the software would assume that shipping entire roughhewn logs to a hammer factory is the only option.
I think what you'd need to do is make it so that every discernable production unit has their own "books" which then connect to each other depending on the supply line as well as send info back to central planners if they exist. Ideally, this software can be useful whether or not there is any vertical hierarchy organizing things. Having separate books is also important for auditing purposes and holding each autonomous unit accountable. It would also mean that commodities can exist at multiple levels of abstraction as defined in the books within the accounting software. A hammer can have logs as inputs or wooden handles depending on the granularity of the books of the enterprise. Maybe for birds eye view planner it's better to see the inputs as logs, but better for the factory to see break them down into hammers in their records. Conversion factors can be stored somewhere centrally with technical production coefficients, with an eye towards making them more efficient, perhaps using blockchain technology.
could you go over the concept of a "book"?
if i'm understanding correctly, it reminds me a bit of how dwarf fortress is programmed (at least what i've picked up on from hearing the developer talk).
each animal or dwarf or monster has a list of attributes (quite an expansive list. every body part, every tissue, the amount of blood in the body, whether any given organ is failing, etc.). there are also a series of independent functions which entities can call.
butchery in the game actually is just a dwarf using specific combat actions against a corpse. (this is imo a really good example of how the entire thing works out) so one entity is able to call a function targeting another entity. a dwarf with arms and the right skill calls the butchery function which modifies various combat functions. these combat functions are targeting specific body parts on the cow like the hip joint or the stomach and then adjusting attributes accordingly.
so are you saying that each commodity would have a similar set-up to this?
like hammers made at factory A and hammers made at factory B both have the attribute "hammer" but can take different inputs and other such attributes? this collection would then be called a "book"?
A book is what you call a company's accounting ledger. Say you've got a private holding company with multiple subsidiaries. Technically they're all owned by the same person, but so long as they're registered as different companies they each have their own set of books that can be audited.
something else that i think is very important for any planning software would be re-aligning how we think of work.
as David Graeber points out, an easy way to suss out what is productive or unproductive labor is to ask "does this work go toward caring for someone or enabling someone else to do so?".
we make a cup once but it gets washed a thousand times. we build a house once but it gets repaired and maintained for 50 years.
increasing the material wealth of a society toward a plan does not necessary involve the vast physical production of use values but the temporal expansion of use values. most of the use values capitalism produces are wasted. private homes and beds and cars and tvs and pools are all only usable to the small group of owners and the short-lasting products like single use bottles and packaging have their use-values gone almost instantly.
solving the first problem is easy since we could just produce things like hobby telescopes and model railroads and cars and pools and kayaks in amounts which would allow anyone who wants access to them ready access. (most of these things go unused 90% of the time so providing all with them could be 10x less work than under capitalism).
as for the longer lasting use-value issue, i think this could be done rather simply. the IO planning method already has baked into its calculations the wear and tear of goods. modifying it to allow for multiple goods (say a well-built home vs. a temporary shack) to provide the same use-value in the plan could allow the software to automatically plan for this. maybe it *is* more efficient right now to build up massive stock of temporary housing for workers and produce single use bottles while we wait for sturdier homes to be built and supply lines for glass container re-use to be deployed.
To elaborate, each company's books will also have specific categories created by their accountants depending on what kind of production they do. So if you're a business that manufactures glassware, you'll have expense categories for sand and fuel for the furnaces, and asset categories for the specific tools of the trade ect that most other businesses won't. In capitalist firms all these accounts are done in money, but in a non-capitalist enterprise they would be in material terms.
something else that i think is very important for any planning software would be re-aligning how we think of work.
as David Graeber points out, an easy way to suss out what is productive or unproductive labor is to ask "does this work go toward caring for someone or enabling someone else to do so?".
we make a cup once but it gets washed a thousand times. we build a house once but it gets repaired and maintained for 50 years.
increasing the material wealth of a society toward a plan does not necessary involve the vast physical production of use values but the temporal expansion of use values. most of the use values capitalism produces are wasted. private homes and beds and cars and tvs and pools are all only usable to the small group of owners and the short-lasting products like single use bottles and packaging have their use-values gone almost instantly.
solving the first problem is easy since we could just produce things like hobby telescopes and model railroads and cars and pools and kayaks in amounts which would allow anyone who wants access to them ready access. (most of these things go unused 90% of the time so providing all with them could be 10x less work than under capitalism).
as for the longer lasting use-value issue, i think this could be done rather simply. the IO planning method already has baked into its calculations the wear and tear of goods. modifying it to allow for multiple goods (say a well-built home vs. a temporary shack) to provide the same use-value in the plan could allow the software to automatically plan for this. maybe it *is* more efficient right now to build up massive stock of temporary housing for workers and produce single use bottles while we wait for sturdier homes to be built and supply lines for glass container re-use to be deployed.
There's already been a lot of work done for using IO tables to examine households, and essentially this is what planners looking at all of society would take into consideration.
While you obviously can't force everyone to use software like this within the household, you can use consumption statistics and labor time surveys to estimate what household technical production coefficients look like, as well as the depreciation rates for household "assets".
At the same time, this kind of software should be useable by household, communes and other types of organized communities for planning purposes.
but we have issues. just because we need, say, 400 hammers, does not mean the factories making hammers can make them. what if there isn't enough labor time within a commuting distance of the hammer factory?
This problem is solved with a constraint.
so now you add in every delivery route as a "commodity" as well. but then now you're really boned because if you're actually going to include every possible transit route, you'd need an insane amount of new commodities. For the US alone, there are around 1 million factories and 1 million retail storefronts. so you'd need 2 million * 2 million routes.
This is known as the multi-commodity flow problem, which is a subset of LP.
Most of what is talked about here regarding "books" is already addressed by the formalism that Dave Zachariah has developed and which is available in his and Loke Hagberg's Receding Horizon Planning project. See here for the related paper: link.
Regarding inventory, what will also be necessary is metadata. In one sketch I worked on a while back I had in mind a tag based metadata system. Something like a booru but for supplies. This allows grouping things. One also needs a schema for physical units, such as mass, volume and number of things. Another way to think of this is: a wiki for production.
@thardin a wiki for production feels like it would connect nicely to that idea I had of technical coefficients and certain accounting data being available on a blockchain. Imagine having access to a wiki which tells you what inputs you need for a given product and what the different distributions of those inputs are presently being used in industry, even some technical documents and guides that are open source. Clicking on inputs allows you to see disambiguation for various inventory supplies and all kinds of information about them.
Such a resource could allow groups of socialist enterprises to form with given agreements for distribution among themselves, and let individuals and households see where they can contribute.
@casperadmin Something like that. I also sketched an XML schema for it but perhaps an example is more illustrative, see attachment. Using a schema, contributions can be sanity-checked in various ways.
edit: crappy attachment limitations strike again. I'll just paste it inline:
<?xml version="1.0" encoding="UTF-8"?> <ent name="Test Testsson"> <fixed what="land" type="forest" amount="8" unit="ha"> <!-- the trees are on the forest land and can't be moved (markanläggning) --> <fixed what="trees" type="pine spruce" amount="800" unit="m³sk"/> </fixed> <fixed what="land" type="farmland" amount="4" unit="ha"/> <fixed what="building" type="detached" amount="1" unit="piece"> <floor level="-1" area="35" unit="m²"/> <floor level="0" area="75" unit="m²"/> <floor level="1" area="75" unit="m²"/> </fixed> <fixed what="building" type="barn" amount="1" unit="piece"> <floor level="0" area="200" unit="m²"/> <floor level="1" area="100" unit="m²"/> <tool what="chainsaw" brand="Husqvarna" amount="1" unit="piece"/> <material what="lumber" width="195" height="45" length="6" amount="10" unit="piece"/> <!-- 2"x8" --> <material what="lumber" width="70" height="70" length="4.5" amount="5" unit="piece"/> <!-- 3"x3" --> </fixed> <!-- loose property --> <tool what="power_supply" brand="Tenma" model="72-13330" amount="1" unit="piece"/> <tool what="signal_generator" brand="Tenma" model="72-3555" amount="1" unit="piece"/> <tool what="oscilloscope" brand="Rigol" model="DS1052E" amount="1" unit="piece"/> </ent>