Anatomy of an Open-Source Project

Anatomy of an Open-Source Project

** This thread discusses the article: Anatomy of an Open-Source Project **
Paying no dollars is the major attraction of Open Source products. The biggest advocates (other than individuals of course) are Academics and Non programming IS management and support staff who's budgets can be kept down with the use of Open Source. In reality, there are few instances where it provides better software than a commercial product functionally - other than where their requirements are minimal and more commonly when price is raised. You can re-enforce this thinking by comparing the size of the piracy market (think games, MS, or Adobe products) versus the size of the open source market. The end-users want it free. The "correct" approach would be to use an equivalent Open Source product but they don't - they'd rather pirate the commercial stuff. Ultimately though, it's a matter of IP. Solo App Developers and programming teams (the very innovators who are the seedpod for new products) will usually chase the IP. Why wouldn't they? Chances are they won't want to contribute their new MS killing program, the subject of thousands of hours development, to "the collective"? In Australia recently a local Open Source leading light was bemoaning the lack of contribution from Australian Industry. It was amusingly obvious what was occurring. What value does the enterprise get by giving away it's internally developed code? Take it further, how would this relate to a recent thread on customised development and the competitive advantage a company gains from it's use? Surely the logic follows that they should be encouraged to just give this code away to the collective. But then the management team might have a different take on that option. And finally, we have the somewhat hypocritical positions of enterprises like IBM and Universities. They all want Open Source to go ahead. It saves them money in developing O/S and code themself and in the install costs. But look deeper and it is IBM that consistently wins the battle on IP applications per year. Wouldn't that be locking away innovation from others? And the half dozen universities I have dealt with in the last 5 years have ALL had several clauses in there agreements where they attempt to take ownership of any new work created for them or any idea they may derive from the application, or indeed any new change added to the program to address a particular issue on their campus. Why do these people all crave IP rights and not expect the rest of the community, certainly the programming community, to want the same benefits?

Anatomy of an Open-Source Project

** This thread discusses the article: Anatomy of an Open-Source Project **
Actually, I did mention the "real" cost of modifying a purchased package. At the company I described, the comparisons were kept very high-level, with bids put out to the business partners of the commercial packages that were investigated. The company had formal requirements, written in advance, and RFPs were sent out to numerous business partners for the commercial package that had been identified as the target. The original package software was identified at a cost of $10K, with many of the out-of-the-box features that matched or approximated the RFP. The customization bids that were returned ranged from $20K to $60K. The management then began the process of selecting, based upon the traditional values of "lowest bid/best quality". They selected the $20K business partner. The business partner spent $20K analyzing the project and came back and said that the actual cost would be $100K. That ended the conversation, and the budget was blown. Management complained, got its $20K back from the business partner, and then started looking at open source. The unfortunate, but not unusual, part of the story was that even with a well-defined RFP the business partner could not make an accurate estimate of the costs when it bid on the project. The pressures on an consulting analyst to identify actual costs are exceedingly high, and the accuracy of the estimate is usually based upon experience with the packaged software -- not with the experience with client. Time is always scarce when such estimates are required. As a result, it's not unusual for estimates on any package software to be 20 to 30 percent lower than what it actually costs to deliver. Such is the "pain" suffered by consultants who make a living modifying packaged software. What was really unfortunate in this company's experience however was that its management was not prepared for the scope of variance. It had made plans based upon budget, and was looking for the most cost-effective solution. When it received first a low bid, and then a revised estimate, its initial thought was that it was being wheedled. The only moral that it learned is that "Packaged software is packaged." You don't gain any economic advantage by choosing a package if your intention is to start "modifying" what comes out of the box. Configurability is another thing.

Anatomy of an Open-Source Project

** This thread discusses the article: Anatomy of an Open-Source Project **
Nathan, First, thanks for the comment. Second, the question "Who are the real innovators?" is a very important one. When you look at how commercial software has developed in the past, it usually is a story of one company or developer who takes a business problem, devises a solution, and then takes it to market. The success of the solution as a product then starts its own evolution, spawning imitators. Usually, the first one to the marketplace with the solution is not the ultimate winner, commercially. (e.g. Microsoft did not initially gain dominance in the Office environment by innovation, but by imitation of products like 123, Word Perfect, and some Lotus products. And let's not even talk about the Windows interface.) Where I see open source innovation right now -- particularly in the areas of PHP -- is under the covers. The PHP community, the MySQL community, and the open source developer community are combining talents to bring a whole new hardware store of tools to the business environment. This is an evolutionary process, and the first phase was to build the tools and the frameworks. We're now in the second phase in which open source developers are applying those tools to standard business problems. The methodology of assembling and using these tools is significantly different than the commercial packaged software methodology that we've seen in the past. Anyone can assemble the tools! Anyone can access the open source frameworks! Anyone can extend the functionality! But the current phase of evolution is to provide the basic functionality of commercial packages at a fraction of the cost. What is not clear yet is how this translates into a business model for the developers. Some use the frameworks as leveraging their expertise for consulting. Others will use the basic frameworks as starting points for packaging add-ons or plug-ins -- the true value-add proposition. At this phase, it will be continually difficult for IT managers to evaluate the advantages of one solution over another. The differentiators may be things like quality, support, and overall service and reputation. It will be interesting to see how these values are sorted out. What will probably NOT happen will be market dominance in individual application suites. What will probably NOT happen will be proprietary packages that eliminate the competition. What will probably NOT happen will be a single Microsoft-like corporation controlling the conversation. And for this reason, open source is a great hedge against entrapment by large commercial software organizations. IBM has a great point when they say that the future of computing is in collaboration, and the requirements of collaboration is open source. Web2 is that first next step. How this materializes will be an interesting game to watch. Thomas M. Stockwell Editor in Chief MC Press Online, LP

[nandelin]

Anatomy of an Open-Source Project

** This thread discusses the article: Anatomy of an Open-Source Project **
Last night I listened to a couple podcasts, which were interviews with one of the founders of SugarCRM, which is becoming a prominent open-source offering, which was referred to by Duncan Kenzie in his recent article. The founder's message was very impressive and convincing. It laid out a plan for dominance in the CRM software market by a product, a company, and a community that leveraged open-source software (namely PHP, mySQL, Linux, Apache) and developed under that same model in a way that would attract widespread acceptance of their products. But I did notice a couple chinks in their armor. First, they talk about how the open-source approach breeds innovation. But when you demo their product you begin to see many similarities between it and a comparable offering from SalesForce. I got the impression that SalesForce was there first. Who are the real innovators? The founder also alluded to the difficulty of coming to agreement on features and functions, when you open the design to a community of developers. Out of 500,000 downloads, which is very impressive, 500 signed up for paid commercial offerings. It's just an interesting topic, and I appreciate you (Mr. Stockwell) writing about it. Nathan M. Andelin

[R.Daugherty]

Anatomy of an Open-Source Project

** This thread discusses the article: Anatomy of an Open-Source Project **
I'd say buying a closed source module that's 1/3 the price of a low end complete closed source package will get you what was described in the article, lockin that is more than questionable. The training thrown in stuff without a cost apportioned to it is also a major problem in analysis. Generally it's a trip to the vendor on your dime, plus they spend the whole time hitting you up for more needs, customization, more products, additional services, and on and on. You can pay a consultant to travel to your site and train. I don't see a clear comparison there at all. The company should be looking to be a participant in the community. If training materials are insufficient, sponsor some work on it and donate back to the community. Same for non-competitive advantage enhancements such as some of that interface work between the 30 some addons. Open source addons. The company should be looking to add back simple work like that to the open source community where they got it. Lastly, open source can not be crippled. It usually is a lighter on function version than a commercial product, but it's a buy/build choice, not a limitation from a closed source vendor on what your software can do. That's the huge distinction in open source. rd

Anatomy of an Open-Source Project

** This thread discusses the article: Anatomy of an Open-Source Project **
the "real" cost of modifying a purchased package? You seem to have left this out.

[MCWebsite.Staff]

** This thread discusses the article: Anatomy of an Open-Source Project **
** This thread discusses the Content article: Anatomy of an Open-Source Project0