Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cost Subtlety #4

Open
elansegarra opened this issue Apr 11, 2016 · 5 comments
Open

Cost Subtlety #4

elansegarra opened this issue Apr 11, 2016 · 5 comments

Comments

@elansegarra
Copy link
Collaborator

As it stands, the firm only incurs one cost each period and the current price adjustment heuristic only has them change price if their periodic costs are not fully covered (on average). One unfortunate result is that sellers continue to drop their prices (by undercutting neighbors) overtime. Seems like we need to add some heuristic to allow them to raise their price so prices are more dynamic (perhaps when their sales are "high"?). Furthermore there is currently nothing stopping them from lowering their prices "too low". We probably need to introduce variable and fixed costs so that there is some lower price boundary (like variable cost) which they are much more hesitant to cross.

@ysaikai
Copy link
Owner

ysaikai commented Apr 11, 2016

Sounds like it is time to go back to our textbooks and learn just a little bit more sophisticated price competition than the Bertrand model.

@ysaikai
Copy link
Owner

ysaikai commented Apr 14, 2016

Here is an idea base on my own experience. Vendors desperately wait for someone (in their neighbor) to raise the price (i.e. expectation for implicit collusion). A trigger for initiative is a signal of "doing well", e.g. 10% profit in t consecutive periods. Once she autonomously raises it, she 'reset' and restart counting "good days" (if any), and all the neighbors react. The process is very dynamic. One implementation may be having "sanguine periods", in which they do not reverse their decisions (either increasing or decreasing price) no matter what the neighbors are doing. That is temporarily ignore collusive opportunities. I guess we need adjust the current undercutting rule accordingly.

@ysaikai
Copy link
Owner

ysaikai commented Apr 17, 2016

Another key concept in LFS is authenticity. Simply put it, the larger, the less authentic as local farmers. Some consumers negatively see the adoption of the conventional scaling-up business strategy (becoming a Wal-Mart). So, how about writing the trust dynamics as a negative function of sales? Combined with a bit more sophisticated costs mechanism, we may be able to generate a more interesting and realistic picture.

@elansegarra
Copy link
Collaborator Author

In theory I agree with the idea that scaling up could lead to perceptions of unauthenticity (or "unlocalness"). However, do we think this would manifest in our model? In other words, when one of our local producers has a huge number of sales, are we envisioning that they are becoming corporate or that they just have a long line at their farmer's market stall?

@ysaikai
Copy link
Owner

ysaikai commented Apr 21, 2016

There is no magic to reduce costs but technological & managerial innovations and scale economies. And the latter is likely the option that the majority of local farmers think of for serving a long line at their farmers' market stall (esp. a single producer in our model represents some aggregated one). So, I wonder, if no qualitative jump from local to corporate, we may write embeddedness, which is more appropriate now than trust, as a negative function (say, quadratic or sigmoid functions) of sales. This is another effort to make us comfortable with and endogenize embeddedness.

Wittman, H., Beckie, M., & Hergesheimer, C. (2012). Linking Local Food Systems and the Social Economy? Future Roles for Farmers’ Markets in Alberta and British Columbia. Rural Sociology, 77(1), 36–61.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants