If you're a programmer working on an open source project in your free time, what principles would you add here?
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 11 of 11.

• Open source should be faced as a serious line of thought in software development.
  2006-04-17 09:22:26  anderson_ito [Reply | View]
  
  
  I strongly agree on the points discussed in the article and truly believe that many practices adopted by open source projects can help corporate projects. With so many tools and techniques available that helps increasing the software quality and decreasing maintenance efforts, it is so frustrating when you work on a project that does not see the gains come from open source.
  
  Sometimes open source is seen as kidstuff, which is not true. There are professionals and very skilled people involved. Some companies just think that because it is open source, it lacks a tech. support model. Support is everywhere.
  
  The impression I had is a project failure is due to the lack of communication between all parties involved in the coporate software development projects, that I consider a very strong and important characteristic of the open source projects. Like said, "All developers are created equal", I would include: "All parties involved are created equal".

• Meetings
  2006-03-07 00:32:00  schiffbruechige [Reply | View]
  
  
  While I agree that corporate projects can learn some things from open source ones, I think there is a big difference in how a lot of things are handled. For example, OSS project meetings are rarely (if ever) face to face ones, instead they are held on IRC channels, newsgroups, chats and mailing lists. The usage of this medium is precisely the reason why 13 year-olds and 70 year-olds alike can gain acceptance and respect for their contributions. (Ditto women!) They are known first through their efforts, and only later is it known who they are, if at all.
  
  In the real/corporate world, these people will be taken first at face value, and then for their knowledge, if they get that far.
  
  Large, long, face to face meetings held in the corporate world are less useful, one can't point people at websites, code, or explain code so easily. Internal IRC servers or similar, which employees can use to help each other while they work would be much more beneficial.
  

• Policies vs. Documented Policies
  2006-03-05 14:01:38  TimKientzle [Reply | View]
  
  
  An excellent article! I have one minor quibble, though. I think the article (slightly) overstates the need for documented processes. I think it is more important to have processes than to have documented processes, and that the emphasis on documentation can actually be counter-productive.
  
  One corporate team I managed became vastly more productive after we instituted standard practices for source control and release management. Those practices were understood and practiced by everyone on the team for almost a year before they were written down. (In a sense, they were "documented" in the form of simple scripts that automated portions of the process; I credit this automation with the widespread acceptance of our processes.)
  
  In contrast, I've seen a few instances where people documented practices that weren't already in general use; frequently the practices never get adopted and the documentation turns out to have simply been a waste of time.
  
  I think that both developers and development managers often fail to understand that "more documentation" can be just as counter-productive as "more source code." Documentation needs to be reviewed and maintained just like any other project output.
  

• The Million Dollar Problem
  2006-03-02 14:54:19  sichen [Reply | View]
  
  
  I don't think lack fo requirements gathering is as much of an issue with open source software development. If you propose your changes to your mailing list, you'd get a lot of feedback on it. People can also be pretty vocal about what they'd like to have--even though they may not be able to do anything about it.
  
  That, unfortunately, is the real problem of open source software development: how to address the needs of non-technical users. It's not a problem of development processes but rather one of economics.
  
  The easiest way to think about it is this: if 100,000 users each would pay $10 to get better-looking user interface, how would an open source community make that happen?

• Good Fast and Cheap
  2006-03-01 23:16:29  AkashChandrashekar [Reply | View]
  
  
  I have actually just been through a HUGE corporate project involving many moving parts and individuals. The unfortunate nature of corporations in general is that they employ the "good fast and cheap" mentality of project management. Unfortunately in that formula they can only attain two of the three. The corporate nature of business is that when a CEO,CTO,CIO has their head on a chopping block the "sh*" rolls down hill. Managers make the shots then, and will tell you "just get 'er done". I can remember plans upon plans being created, revised, and finger pointing. I can also recall the quality, and the necessary steps to manage things taking a second seat. The attitude changes to "just meet the date and we'll accept that it should be as good as what we had before". Amazing - the amount of WASTE that goes on from all the unecessary layers that appear once peoples heads are on the line instead of doing whats right. Anyhow, I thought the article was extermely thought provoking and good.Having been recently through this experience, and leaving the orginization, because of the VERY things that are described in the article, I am actually happy to see that someone else had noticed and accounted for the level of dysfunction within corporations. What saves these orginizations is a HUGE bank account and their core business not being IT.

• Forgets key factors
  2006-03-01 16:47:47  kolding@alum.berkeley.edu [Reply | View]
  
  
  This article forgets two key factors that drive corporate software: budget, and schedule.
  Open Source projects usually don't have either.
  
  Pretty much all software projects end up being over both budget and schedule. It's just truism, like the sun will rise tomorrow. But in a corporate world, sometimes those can't slip. My company won't get paid if we miss our release date. A friend at an online retailer once stated "Christmas doesn't slip". When a release date is looming, and things aren't ready, changes happen. Bad decisions get made, or (more often) good decisions which have ramifications later, get made.
  
  How many Open Source projects have hit schedules? Or even announced schedules? How long has it been between release of GnuCash? Or the Gimp? They are typically done when they're done. There's no hard deadlines which must be met.
  
  Similarly, since most open source projects are run by volunteers, there's no budget. No "what do I cut" when the money's running out. The volunteers will just keep on going (or, sometimes, they don't, they just disappear, slipping any future releases).
• Forgets key factors
  2006-03-20 13:08:39  dlc311 [Reply | View]
  
  
  I think that's the mentality that the article addresses. In a consulting company, this doesn't make any sense, because a consultant's job isn't to produce software the is most cost effective. A consultant or a contractor is motivated to do as little as possible for as much as possible. This is why some foresee a "backshoring" or "inshoring" trend in the next 10 years. Software development can only be made cost effective if that development group is supporting the business using it, not a client. The FBI has been the most recent and obvious victim of such disbelief. Given that your goals are for the most cost-effective solutions, deadline predictions are much more accurate, and costs are much lower, while quality increases. Accuracy, reliability, quality, and cost-effectiveness can easily compensate for fixed deadlines, perhaps not with the same clients. As for budget, I haven't read a study in software, nor participated in a project, that doesn't support early-process mistake-aversion because it is cheaper and quicker than streamlined, top-driven pet projects.

• There are milestones but no end
  2006-03-01 16:43:13  jonathanhager [Reply | View]
  
  

  One of the things that I see wrong with corporate projects (at my current corporation) are that they are run as a project. After the project ends the team is re-deployed. Sometimes after users have only been using the system for a week. This means that all your knowledge of the code is immediately disbursed and any new developer has to learn what the team did, generally with little documentation.

  
  
  

  In open source projects, 1.0 is a milestone, not a finish line.

• Not sure that all developers are really equal
  2006-03-01 14:45:46  wjbaird [Reply | View]
  
  
  I like the article overall --- some very good points in there. However, I'm not sure I agree with the "philosophy of treating all developers equally"...
  
  In my experience both on open and closed source projects, I've encountered some developers who are really, really good, and others who are frankly horrible. However, I think your point is that there is often very little correlation between job title / position/longevity on a project and how good the developer is.
  
  I think the thing that makes the successful OSS projects successful is that they operate as a meritocracy --- They don't care if you are a 12 year old prodigy who is bored, or a time traveller trying to change the past - if the code is good, they use it...
  
  I've seen estimates that a good developer is 10x to 25x more productive than an average developer - so I don't think it's really useful to pretend that everyone is equal...
  

• Apples to Oranges
  2006-02-27 21:21:57  trcull [Reply | View]
  
  
  I think corporate projects could indeed learn a lot from open source projects, especially around how to work with a distributed team of people who haven't met each other (think off-shoring).
  
  But the corporate-to-GIMP success rate comparison doesn't hold water: take a look at SourceForge.net some day and consider how many projects are permenantly stuck in the pre-planning or alpha stage, never to release a working piece of software. I'd bet the ratio of those failed Open Source to GIMP-like projects is much worse than 30%.
  
  http://www.thedwick.com/blog
• Apples to Oranges
  2006-02-28 08:57:32  Karl Fogel | [Reply | View]
  
  
  The whole way we measure success rates is fundamentally flawed. We need to measure the project's actual success against its own *expectation* of success. For example, a person or an organization might start a blue-sky project just to see where it goes, being careful not to pour in too many resources until they see that it has promise. They may give the project, say, a 10% chance of success at its outset, and structure their investment accordingly.
  
  Now suppose that 10% of such projects actually do succeed. Would you say then that we have a 10% success rate? No. It would be more accurate to say we have a 100% success rate (and if 20% of them succeed, we have a 200% success rate!) as measured against originally expected success.
  
  That's why looking at just the numbers over at SourceForge can be deceptive. Yes, the vast majority of projects there never go anywhere. But did the people who started those projects expect them to go anywhere? If so, where, and with what probability?
  
  (Hmm, and I made the same oversimplification, at the beginning of http://producingoss.com/html-chunk/introduction.html, perhaps a footnote is in order.)