Comments on: The Shackles of Success with Closed vs. Open Source http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/ One foot in the muck, the other in utopia Wed, 03 Dec 2008 20:24:52 +0000 http://wordpress.org/?v=2.6.3 By: James Governor’s Monkchips » Open, Social, Only People: Putting the Ad-hoc into ERP. On SAP, Breakthrough Productivity and Bring Sexy Back http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-113453 James Governor’s Monkchips » Open, Social, Only People: Putting the Ad-hoc into ERP. On SAP, Breakthrough Productivity and Bring Sexy Back Tue, 11 Dec 2007 18:57:07 +0000 http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-113453 [...] and as such, are an asset to control and manage rather than enable. Cote often refers to the shackles of success. The idea of “the shackles of success” is largely one about protecting and continuing existing [...] [...] and as such, are an asset to control and manage rather than enable. Cote often refers to the shackles of success. The idea of “the shackles of success” is largely one about protecting and continuing existing [...]

]]> By: James Governor’s Monkchips » Carter and The Devil in the Detail: a mammal’s eye view of industry analysts http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-84822 James Governor’s Monkchips » Carter and The Devil in the Detail: a mammal’s eye view of industry analysts Mon, 05 Nov 2007 17:49:12 +0000 http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-84822 [...] am a known as a fan of “legacy” technology platforms: they do however create shackles of success.) RedMonk is playing a different game, with different influence dynamics. In some communities [...] [...] am a known as a fan of “legacy” technology platforms: they do however create shackles of success.) RedMonk is playing a different game, with different influence dynamics. In some communities [...]

]]> By: James Governor’s Monkchips » Seth Godin, The Dip, Shai Agassi and The Bursty Economy http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-25955 James Governor’s Monkchips » Seth Godin, The Dip, Shai Agassi and The Bursty Economy Wed, 25 Apr 2007 12:57:27 +0000 http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-25955 [...] may have just tired of the shackles of SAP’s success. The future of the planet is surely a more important Dip than the success of SAP. Like many in the [...] [...] may have just tired of the shackles of SAP’s success. The future of the planet is surely a more important Dip than the success of SAP. Like many in the [...]

]]> By: People Over Process » Blog Archive » Outsourcing my Feed Reading: Info Consumption with the del.icio.us network http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-24360 People Over Process » Blog Archive » Outsourcing my Feed Reading: Info Consumption with the del.icio.us network Tue, 17 Apr 2007 20:18:16 +0000 http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-24360 [...] often know what I want to read about rather than looking to stumble upon something. For example, ColdFusion. Google Blog Search, Google News, and Technorati are good here. Search feeds are a sort of gray [...] [...] often know what I want to read about rather than looking to stumble upon something. For example, ColdFusion. Google Blog Search, Google News, and Technorati are good here. Search feeds are a sort of gray [...]

]]> By: James Governor’s Monkchips » Hyper Productivity And Information Saturation Economics http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-24309 James Governor’s Monkchips » Hyper Productivity And Information Saturation Economics Tue, 17 Apr 2007 13:00:37 +0000 http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-24309 [...] spotting the opportunity isn’t enough. The mothership also needs to act on it, and often overcome the shackles of success. But i know one thing. Without social/knowledge/collaboration tool junkies on staff your company [...] [...] spotting the opportunity isn’t enough. The mothership also needs to act on it, and often overcome the shackles of success. But i know one thing. Without social/knowledge/collaboration tool junkies on staff your company [...]

]]> By: Mark Wahl http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-24192 Mark Wahl Mon, 16 Apr 2007 17:23:13 +0000 http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-24192 One difficulty is when the cost-benefit tradeoff decision function for a developer is too different than that of an end user (individual or organization). E.g., an end user organization doesn't see the cost of bugs they haven't encountered, and any change that isn't purely fixing the bugs they've reported or adding features they've requested is going to be a negative due to the instability that may result. A problem in some open source development is that community developers may not be motivated to consider the long-term maintainability of their source in the end user's environment, not just in the development environment. (And vice versa, when end users contribute code back to the trunk and expect that it'll be maintained in the way they use it.) Open development processes can give the end user visibility into what's going on. One positive outcome of this is if the end user develops empathy for the other end users and can feel that changes are being made for the set of end users as a whole. End user community management is important in closed processes as well, of course. Large software companies have user group meetings, and some long life products develop active fans (e.g. http://www.openvms.org/). One difficulty is when the cost-benefit tradeoff decision function for a developer is too different than that of an end user (individual or organization). E.g., an end user organization doesn’t see the cost of bugs they haven’t encountered, and any change that isn’t purely fixing the bugs they’ve reported or adding features they’ve requested is going to be a negative due to the
instability that may result. A problem in some open source development is that community developers may not be motivated to consider the long-term maintainability of their source in the end user’s environment, not just in the development environment. (And vice versa, when end users contribute code back to the trunk and expect that it’ll be maintained in the way they use it.)

Open development processes can give the end user visibility into what’s going on. One positive outcome of this is if the end user develops empathy for the other end users and can feel that changes are being made for the set of end users as a whole.

End user community management is important in closed processes as well, of course. Large software companies have user group meetings, and some long life products develop active fans (e.g. http://www.openvms.org/).

]]> By: Dan Davies Brackett http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-24187 Dan Davies Brackett Mon, 16 Apr 2007 16:34:59 +0000 http://www.redmonk.com/cote/2007/04/16/the-shackles-of-success-with-closed-vs-open-source/#comment-24187 *of course* all developers are silo developers. *of course* all technology that requires any kind of user lockin requires developer lockin as well. Everyone knows only what they know; you can broaden your own 'silo', but you're still siloed. I, for example, still don't grok functional programming in any meaningful way. So I'm stuck in the procedural/object-oriented/mainstream 'silo' there, and as a consequence I don't get Seaside (or the advanced parts of ruby, or what Paul Graham is going on about). The silos that open-source developers find themselves in might be differently organized, though. The primacy of community in the open-source world can lead to insulation from outside opinion, and (for example) the LKML is a hostile and alien environment to someone who just wants to find out how to get pretty graphics on his Debian box. So rather than being siloed on a technology, they're siloed on an idea or three. *of course* all developers are silo developers. *of course* all technology that requires any kind of user lockin requires developer lockin as well.

Everyone knows only what they know; you can broaden your own ’silo’, but you’re still siloed. I, for example, still don’t grok functional programming in any meaningful way. So I’m stuck in the procedural/object-oriented/mainstream ’silo’ there, and as a consequence I don’t get Seaside (or the advanced parts of ruby, or what Paul Graham is going on about).

The silos that open-source developers find themselves in might be differently organized, though. The primacy of community in the open-source world can lead to insulation from outside opinion, and (for example) the LKML is a hostile and alien environment to someone who just wants to find out how to get pretty graphics on his Debian box. So rather than being siloed on a technology, they’re siloed on an idea or three.

]]>