Continuations - Latest Comments in Network Effects And Scale Economies (aka Spolsky vs. Heinemeier)

Re: Network Effects And Scale Economies (aka Spolsky vs. Heinemeier)

albert — Thu, 05 Nov 2009 21:42:56 -0000

Thanks for pointing out those things about Atlassian. Agree that there is definitely a fair bit of switching cost, but I have been surprised by folks switching other things that would appear to have high switching cost (e.g., version control systems). So some of that depends on how much integration has taken place and how hard or easy it is to export from existing systems and import into new ones.

Re: Network Effects And Scale Economies (aka Spolsky vs. Heinemeier)

nikiscevak — Thu, 05 Nov 2009 19:56:05 -0000

Albert, great comments and Atlassian already has a large developer community and plugin architecture and the real test of success - that participants in the platform can earn money - is already verified. Balsamiq started life as a confluence plugin (not JIRA the issue tracking software but that is the best known example). Another example is Grasshopper (an agile overlay on JIRA) that ended up being acquired by the company.

The second thing is, is network effects really what you should be focused on? I would argue that bug tracking has one of the highest switching costs associated with it. People just don't want to change once they and their team have invested in the product. This, more than network effect, is probably what is troubling Joel.

Disclosure: I have nothing to do with Atlassian but am good friends with the co-founders and went to school with them.

Re: Network Effects And Scale Economies (aka Spolsky vs. Heinemeier)

albert — Thu, 05 Nov 2009 18:00:06 -0000

Not sure this really qualifies as a network effect since it doesn't actually increase the value of the service to users. Maybe on an "expected" value basis it does.

Re: Network Effects And Scale Economies (aka Spolsky vs. Heinemeier)

albert — Thu, 05 Nov 2009 17:58:38 -0000

Agreed - in fact a well managed user community is very much a form of network effect.

Re: Network Effects And Scale Economies (aka Spolsky vs. Heinemeier)

Gary Luu — Thu, 05 Nov 2009 15:27:10 -0000

I'd take almost the opposite stance and say that everything has network effects. Market leadership is important for establishing social proof for a product as well as customer comfort. It's like the mantra I've heard before about IBM - "You can't get fired for buying IBM."

Re: Network Effects And Scale Economies (aka Spolsky vs. Heinemeier)

Kevin Shaum — Thu, 05 Nov 2009 14:49:28 -0000

Yet another weak network effect: using popular software makes it easier to find people who already know how to use it, whether you are looking to hire such people, or just find someone online to answer a question.

Re: Network Effects And Scale Economies (aka Spolsky vs. Heinemeier)

kidmercury — Thu, 05 Nov 2009 12:17:06 -0000

i agree, splosky won the beef. IMHO practically everything on the internet has network effect opportunities. one of kevin kelly's new rules is "connect everything" which i love for its simplicity and importance. and once you start connecting things i think network effects naturally emerge.

thanks for stepping into this beef and putting the smackdown on heinemeier. a bold move on your part albert to step into a beef between two notable technologists but i applaud you for fearlessly entering the beef and calling it as you see it.

Re: Network Effects And Scale Economies (aka Spolsky vs. Heinemeier)

kuleshs — Thu, 05 Nov 2009 08:47:40 -0000

Excellent points, Albert. You're right to point out bug tracking and software quality are something that can benefit from weak-network effects.

Recently I was at a talk given by Gary McGraw on building secure software. Among the approches I have seen for improving software quality the one he mentioned and practices/preach seems most effective (http://www.bsi-mm.com/). And that method does rely on weak-network effects or most useful when there is network-effect.

It seems bug trackers with capabilities to compile stats and allow projects to compare various trends might help build better software.

@kulesh.