The Greedy Restaurant Shares Software Improvements with Other Restaurants

EDIT: If you are actually looking for Open Source Restaurant Reservation software, take a look here.

I recently came across a question asked by a high school student in the United Kingdom. One of his teachers had asked a question that seemed to imply that needing to share improvements to open source restaurant reservation software with the open source project that created the software was a disadvantage of using open source software.

Im currently delivering a high school qualification in the UK and part of the course is on open source. We have just had an examination paper with a question on what are the disadvantages of using open source software to create a restaurant booking system.

One of the model answers says that the restaurant would have to then release their changes to the public.

For some reason, the fact that this was a model answer bothers me, because that implies that this answer is something the student should strive to emulate to receive a good grade. As if that answer could possibly be part of a coherent answer that makes any reasonable attempt to take the full implications of open source economics into consideration.

So, let us examine the many ways in which sharing code improvements with “the public” for $0.00 is to the advantage of the individual restaurant. Each of the below points could easily be expanded to be an essay unto itself, but I shall endeavor to be brief. We will start by examining a few ways in which it has no negative effect on the individual restaurant because it almost certainly isn’t going to help the competition. Then, we will look at how it will help the restaurant.

Sharing Hurts Nothing.

To begin with, their food and customer service will never be identical to another restaurant – a streamlined reservation system does not change the attire or politeness of staff, nor the amount of curry in the food. Restaurants supply a heterogeneous product, and that product ain’t software.

Furthermore, the software would not even necessarily work for any other restaurant unless it was using an identical software stack minus these trivial modifications.

Thirdly, restaurants outside that city or county are not competitors. If one restaurant in several cities or counties use, improve, and share the software then each of these restaurants will benefit at the expense of all other restaurants in their respective cities. Unless the software becomes ubiquitous, odds are the small number of restaurants adopting the software will be from different cities — located in different markets.

Sharing Has Many Benefits.

It is in each individual restaurant’s best interests to submit the improvements upstream so that each time a new version of the software comes out, they can benefit from all of the other improvements without the need to re-patch the new version of the software with the stuff they wrote. It is far more efficient and streamlined to allocate resources towards working as part of the wider team than to allocate all of the resources that would be needed to maintain internal patches and revision control.

If a single competing restaurant in the given city does use the improved software, then it will still be in that other restaurant’s best interests to share-alike as well any improvements they make (or bug reports, or even feature requests) — so the two restaurants in the same city (eg, market) using this software can both share a comparative advantage over the other n restaurants in town.

Finally, explicit costs of sharing code improvements upstream (eg, “to the public”) are nil as the IT guy that is familiar with Open Source and can do a bit of coding is already assumed to be an employee in the scenario created by the question, and the Marginal Benefit of releasing modified source code back is almost certainly going to exceed Marginal Cost. If there is one thing drilled into the head of any student of economics, it is that if MB > MC – you move forward and do it. Period, and end of story.

So, clearly, it is not a disadvantage for a restaurant to share improvements made to the software “with the public”. They will not be getting any direct revenue for this software, but they will be getting additional indirect revenue through the continuous improvement in their critical customer service infrastructure that this is a key contributor to. The restaurant should not contribute code improvements upstream to be nice or to be communists, they should share this stuff for $0.00 to be greedy rational self-interested business people trying to make as much money as humanly possible.

Advertisements
The Greedy Restaurant Shares Software Improvements with Other Restaurants

One thought on “The Greedy Restaurant Shares Software Improvements with Other Restaurants

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s