Thursday May 07, 2009

Puzzling on the Value of Bundles

Measuring values of a product bundle, particularly when the bundle contains non-equal or potentially complementary lots, has puzzled economists and business strategists alike. I don't claim to have solved the puzzle but I have puzzled on some other aspects of the problem in a short three page briefing I wrote a few weekends ago.  

Thursday Feb 05, 2009

Golden Rules for Contribution-based Communities

There are some basic, golden rules when it comes to having a vibrant community of contributors.

The following are rules I have extracted and learned based on my experience managing and working with engineers actively involved and participating in the Apache/Derby, PostgreSQL and MySQL open-source communities. These rules are also based on extensive discussions with many folks involved with the MySQL community, with the PostgreSQL community and with the Apache/Derby (Java DB) community, over many years.

Before I go through these rules, I would like to thank Marten Mickos for having suggested some of the headings for these rules. (I originally had much longer headings for all of them.) I would also like to thank many of MySQL, PostgreSQL and Java DB colleagues, as well as to many other colleagues involved in open-source development, for having contributed to the ideas and practices behind these rules.

A) Transparency.
1.Often, this openness can span all the way from development (architectural specification, implementation design and planning, implementation, code review and walk-through) to testing, qualification and release.
2.It may be possible to move towards greater transparency over time but openness in development is often the minimum starting point. 

B) Dialog.
1.It should be possible to conduct open dialog and conversation regarding any aspect of the development (and other aspects of) work.
2.When mailing lists and other archive-able communication channels (such as wikis) focused on development work are opened up, it becomes easier to conduct open dialog and conversation regarding the development work. 
3.Of course, when a corporation or business concern contributes (either as a major contributor or a minor contributor) to the development of an open-source product, it is to be expected that some aspects of the development work (e.g. those related to specific customer needs) may remain obscure through mechanisms such as withholding of a customer's name. 

C) Pace.
1.It should be possible to track the fate of any contribution and have a public archive of the conversation conducted regarding that contribution—recording decisions made and various feedback loops in time for the purposes of learning and further work.
2.For this purpose, it is often sufficient to have a time record of the conversation conducted with respect to the given contribution.
3.These records can be searched to determine the fate of the contribution.
4.These records help provide a learning platform for the future contributors.

D) Setting Expectations.
1.Using available and open information, the contributor community should be able to form and entertain valid expectations regarding milestones, releases, timelines, etc.
2.Anticipating the future and related risk management helps all market participants to reduce transaction costs.

E) Small is Beautiful.
1.While it should be possible to absorb contribution of any size, emphasis should be put on  absorbing smaller and incremental contributions.
2.To create mass and momentum and community and quality, it helps to encourage smaller contributions.

F) Differences.
1.Not all contributions are equal.
Contributions are judged by whether they are well designed, fit into business roadmaps, are well documented, comply with standards, do not produce regressions in the code and improve performance.
2.Not all contributors are equal.
Contributors vary in expertise, skill and experience.
These variations give meaning to the practices and procedures of the contributor community.

G) Places.
1.It is clear where one needs to work.
There are enough branches or trees to serve distinctly different target groups.
2.Trees and branches are well-groomed.
Active code branches or trees are kept at a minimum set in order to keep the product roadmap and expectations coherent.

H) Parallelism.
1.Contributions are added in parallel with frequent synchronization so that community participants can respond to each others' work.Parallel work leads—naturally and out of brute necessity—to modularization, better and faster integration.

I) Incrementalism.
1.Work is conducted in increments.
2.Each contribution does one thing.
3.Each contribution has a test case that exercises it.

J) Learning.
1.Contributor community assets (channels of communications, forums, bug databases, etc.) are developed to improve learning by all participants and contributors.


Acknowledgment

I'd like to thank Brian Aker, Knut Anders Hatlen, Davi Arnaut, Kaj Arnö, Jorgen Austvik, Igor Babaev, Mark Callaghan, Peter Eisentraut, Sergei Golubchik, Shawn Green, Lenz Grimmer, Rick Hillegas, Stefan Hinz, Geir Hoydalsvik, Henrik Ingo, Alexey Kopytov, Mark Leith, Dmitry Lenev, Manyi Lu, Giuseppe Maxia, Paul McCullagh, Mårten Mickos, Chad Miller, Francois Orsini, Konstantin Osipov, Trudy Pelzer, Sergey Petrunia, Jay Pipes, Jeffrey Pugh, Ole Solberg, Georg Richter, Mikael Ronström, Kristian Waagan, Dag Wanvik, Monty Widenius, Jeff Wiss, and more.

Wednesday Sep 10, 2008

A Position Paper Resurrected

This four-year-old position paper I wrote for the W3C Mobile Web Initiative still reads well. 

Saturday Dec 23, 2006

Multi-Lot Auction Design

Here is another academic presentation from my Haas years. It describes "Multi-Lot Auction Design: Applied to 3G Spectrum Auctions." I hope you can follow it. Like the previous paper I just posted, it needs some editing and work to bring it up to par. It is definitely worth a separate paper of its own if only time would allow.

Put together originally as a presentation for a game theory seminar, it distinguishes auctions involving multiple lots (items) of potentially complementary value from auctions involving identical lots (items). An example would be if you would participate in an auction involving pieces of adjacent properties of various sizes as opposed to auctions involving instances of the same object. Another example of the first kind, discussed in this paper, are spectrum auctions because these auctions are national and span multiple, but separate, municipalities and regions with value complementarities having to do with costs of maintaining a mobile network on a particular topography of auction licenses.

A Transaction Cost Economics View of the Bullwhip Effect

I'm posting another one of my papers form the Haas years: "A Transaction Cost Economics View of the Bullwhip Effect." It was written in May of 2004. It does need another good round of editting. So, I might edit and repost it at a later time.

In short, this paper gives a TCE assessment of the bullwhip effect observed in supply chain systems. It was written as part of an independent study with professor Oliver Williamson, who was kind enough to review the work and provide some very valuable suggestions. It was an honor to learn a few things about TCE from him, and of courses, errors in this paper, including the typos and techincal ones, are all of my own.

Sunday Oct 15, 2006

Credible Commitments vs. Credible Threats

As part of my interest in transaction cost economics, I've also been fascinated by the follies and excesses of modern strategy theory which focuses, almost exclusively, on a view of economic and social relationships based on anti-social power differentials as opposed to social interdependencies.

Here, I'm posting an essay (PDF) I wrote in May of 2003 on the concept of "credible commitments" in contrast to the-so-called "credible threats." The former concept has been used by prominent transaction cost economists while the latter remains a part of the common terminology in much of game theory.

(Again, anyone may use the essay  as long as the user provides appropriate reference to its origin and author.)

Friday Oct 13, 2006

Efficient Adaptation in Long-term Contracts

Here is a commentary (PDF) I wrote in 2003 on “Efficient Adaptation in Long-term Contracts: Take-or-Pay Provisions for Natural Gas” Scott E. Masten and Keith J. Crocker (American Economic Review, vol. 75 (5), 1985).

If you want to make use of my commentary for a business school paper or otherwise, make sure you give an appropriate reference to it. In other words, use the well-known, common principle: No plagiarizing!
About

MortazaviBlog

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today