commericial versus open source
we're trying really hard to migrate to subversion at work these days. from a clearcase background, i'm having a lot of trouble getting my head around the different philosophies of SVN.
i can appreciate the challenges of working with CC as a developer, but i've yet to experience anything that comes close when it comes to configuration management. perhaps, as some folks suggest, configuration management and source control should be two separate entities. i've always worked with them as one and am trying to understand how you would implement such a philosophy but i still don't get it.
then you get into the commercial versus 'free' open source tool debate ... SVN works wonderfully for all sorts of open source projects so if it is so great with 'teams' that never meet we must be able to adapt it to work great for us in-house. right?
or do open source processes just not translate well to commercial software practices:
http://blogs.open.collab.net/svn/2007/04/take_more_than_.html
http://blogs.open.collab.net/svn/2007/06/building_a_hous.html
i know these links are supposed to advocate using an open source tool and processes in a commercial environment, but i think they highlight reasons why the open source environment may not adapt well to commercial software development.
first SVN was designed by developers, for developers. not CM folks. not build folks. not QA folks. not program management.
open source project can be successful with limited 'interference' from those groups.
open source process works because open source developers are passionate about the project. they are involved because it is close to their heart, not because it provides a paycheck. open source folks want to provide a good, useful tool and aren't worried about paying bills with it.
i'm sure many commercial enterprises would love their developers to be as passionate about their products. i'm sure there are some commercial developers that are as passionate about the commercial products they work on. but, due to the constraints of commercial development (releasing stable code under a deadline to generate revenue for those paychecks versus having a luxury of no deadline in the open source world), i don't see the open source processes advocated in these links as being reliable in a commercial environment.
code reviews are a great idea. in open source, folks actively review code because they're passionate about this idea/hobby/what-have-you. in commercial development, we strive for code reviews. we often have to put in processes to enforce a code review process. and it's not because commercial developers aren't interested in code review (well, maybe a little), but deadlines and resource constraints in the commercial world don't allow for 8 people to review every code change and thereby ensure a stable code base despite changes.
i think that in order to put out revenue generating software on a deadline, you can't adopt all open source tools and processes as they are used in the open source world. it's a different model that doesn't work for the commercial world.
it doesn't make either good or bad ... just different.
i can appreciate the challenges of working with CC as a developer, but i've yet to experience anything that comes close when it comes to configuration management. perhaps, as some folks suggest, configuration management and source control should be two separate entities. i've always worked with them as one and am trying to understand how you would implement such a philosophy but i still don't get it.
then you get into the commercial versus 'free' open source tool debate ... SVN works wonderfully for all sorts of open source projects so if it is so great with 'teams' that never meet we must be able to adapt it to work great for us in-house. right?
or do open source processes just not translate well to commercial software practices:
http://blogs.open.collab.net/svn/2007/04/take_more_than_.html
http://blogs.open.collab.net/svn/2007/06/building_a_hous.html
i know these links are supposed to advocate using an open source tool and processes in a commercial environment, but i think they highlight reasons why the open source environment may not adapt well to commercial software development.
first SVN was designed by developers, for developers. not CM folks. not build folks. not QA folks. not program management.
open source project can be successful with limited 'interference' from those groups.
open source process works because open source developers are passionate about the project. they are involved because it is close to their heart, not because it provides a paycheck. open source folks want to provide a good, useful tool and aren't worried about paying bills with it.
i'm sure many commercial enterprises would love their developers to be as passionate about their products. i'm sure there are some commercial developers that are as passionate about the commercial products they work on. but, due to the constraints of commercial development (releasing stable code under a deadline to generate revenue for those paychecks versus having a luxury of no deadline in the open source world), i don't see the open source processes advocated in these links as being reliable in a commercial environment.
code reviews are a great idea. in open source, folks actively review code because they're passionate about this idea/hobby/what-have-you. in commercial development, we strive for code reviews. we often have to put in processes to enforce a code review process. and it's not because commercial developers aren't interested in code review (well, maybe a little), but deadlines and resource constraints in the commercial world don't allow for 8 people to review every code change and thereby ensure a stable code base despite changes.
i think that in order to put out revenue generating software on a deadline, you can't adopt all open source tools and processes as they are used in the open source world. it's a different model that doesn't work for the commercial world.
it doesn't make either good or bad ... just different.
