Home 
CM Journal Articles Open Source or Open Season?
CM Journal Articles Open Source or Open Season?
|
| Vendors will tell you that you get what you pay for. Open source people will tell you they are liberated from the Matrix. Who should we believe? Can we get what we need in free tools? Can we build what we need? Are we doomed to the annual tyranny of maintenance fees? The truth is in here somewhere. But we will need to be honest with ourselves and persistent. There are a lot of questions to ask and we may not want to hear the answers.
Start with the Needs The very first answer you need is to the question, “what are my needs?” If you’re a single developer, doing your own thing, you have very different needs from NASA who’s coding for a Mars mission. If you’re using VSS but want some level of integration with issue tracking, can you get that from an open source tool? What level of reporting functionality do your users need? Can your business users get the data they need from the tool without having to come to IT for a special report? How much parallel development will you do? Do you have offshore resources you have to deal with? Do you have traceability requirements to satisfy Audit? Is there an integration between the testing tool and the issue tracking system? The more persistent you are with the questions, the better understanding you’ll have to build our tool requirements list. Dig Down into the Tools You also want to consider that every tool does something. It has a reason for existing and it’s important to understand both what it does and what it’s capable of doing or not doing. CVS does version control. Eventum does issue tracking. You could add automation and triggers and all sorts of bells and whistles to your free system but know there are some things they cannot do. Every tool has its limitations. Can you get the right information from DotProject? VSS (sorta free) is excellent at version management but is limited in its parallel development functionality. ClearCase can be hugely powerful but has a learning curve to match. Serena Professional has tons of features but doesn’t force process like Harvest. Is that good? Depends on what you are looking for. I’ve personally used all the tools listed here, except DotProject but I’m looking into that. And open source does not necessarily mean less features. Be sure to read Austin Hasting’s article “Open Source, and other Dumb Ideas” in this month’s CM Journal for an excellent look at the concept of open source tools. How much time are you willing to spend in looking at various tools? Are you willing to run a pilot and have it fail? A lot of organizations have little stomach for that. They see it as failure instead of the learning opportunity it really is. Not every choice we make will succeed (or none of us would be working for a living!), so how much R&D can you support in the quest to find the right tool? Time is expensive but you’re going to, hopefully, have it for a long time and you have to calculate all the interactions of all the users on the system. More time up front means less hassle for years down the road. Know the Full Price How much are you going to spend? This is not an irrelevant question for open source. You will spend money on open source, guaranteed. The tool must be maintained. Often it must be compiled, functionality added, and adjustments made. You might be able to do all that yourself but what else could you have done with the time? A COTS (Commercial, Off The Shelf) system will obviously have cost. There will be the initial purchase and probably maintenance fees as well. All of these are very definable costs. What about the lesser definable costs? Does your open source issue tracking tool provide dependent fields or customizable forms? If not, your users may put things in an awkward state or waste time cruising through extraneous fields to find the items they need. After the Glow Fades Perhaps you can get the specific functionality you were looking for in both a COTS tool and an open systems tool. Does support then become an issue? Open source tools have user communities, as do COTS products. Can you depend on the information you’ll get there? I have at times found better answers there than I did from the vendor. Open source gives you a lot of flexibility but that also comes with the hang up of asking for help with what can ultimately be a one-of-a kind tool. What about the ability to upgrade? Do you have custom fields or scripting that would be jeopardized by trying to merge or upgrade with new versions? Do your customizations lock you into a certain level of functionality? With a COTS tool, paying for a feature usually means it’s good until the next generation of the tool. Often with an open source tool, a minor upgrade will impact an “aftermarket” feature such that it will need to be rewritten, adding cost at every upgrade. Trading Off Other considerations may also be in place. Perhaps you have the funding for either a good requirements tool or a good issue tracking tool but not both. Which are you willing to forego functionality in? Perhaps your organization is really struggling with requirements but because of good iterative practice and experience, the development staff has limited defects in their code. It may be worth putting up with lesser functionality in one tool in trade for the other. Do your trade-offs include personnel? Could you buy a really stellar tool if you give up that extra body you’ve been requesting? Would it be worth it? Maybe you can automate enough with the new tool to offset the loss. Surely if you saved that money in excess of cost, it would wind up in your paycheck, right? OK, maybe not. But it never hurts to look at this like it is your own money. Define your own Boundaries The most difficult question to ask is about your own limitations. You can code this. You can write a script to do that. Sure you can. Or do you hope you can? This isn’t just a question of brainpower. Maybe you are up to your neck in alligators and just won’t get to make the changes you need in the open source tool for another 6 months, if then. What does the organization suffer in terms of functionality that could have been bought? Workarounds may be costing your company twice as much as it would to just buy the right tool. Numbers Game To be sure, buying the right tool is not lazy or unimaginative. In most companies, it all comes down to numbers. What matters is how you obtain them. Do you have the complete numbers? How do you calculate the opportunity cost of every user for those things a tool could do for them? By the same token, are you buying more than you need? This is really where persistence matters, answering the hard to answer questions. Licensing is always something of a gamble since some IT departments fluctuate in size monthly or worse. Are you buying more functionality than you really need? If you bought that phenomenal testing tool but no one understands it or your product just isn’t quite suited to it, then it was not worth the money. It’s easy to fall in love with a new tool but you have to be sure you’ll still be happy after the honeymoon. In terms of tool acquisition, have you really done your market research to understand what your users need and how they will use the tool? You might get a great deal on a tool but if it’s not getting used, it was just money down the drain. You could be doing exactly the opposite with open source. It may not have the functionality your users do need. What is that costing your company? And no matter what you buy, you will probably have to spend time tweaking it. Out-of-the-box is pretty much a non-existent concept for most configuration managers. Be sure you add that cost to the cost of the tool. Finding these answers requires the persistence mentioned in the second paragraph. It means talking to users, understanding where the organization is and where it is going. In Sum The truth is there for us if we look far enough or inward enough. It’s free but you might have to customize it and provide your own add-ons. And then there are the truth forums to confirm what you believe. Or maybe it’s just better to buy the truth. We can get just the right truth-feature set we were looking for. We’d have to field calls from truth sales people with truth brochures and demos. And after truth is installed, we can have ongoing truth support. Wouldn’t that be nice? In the end though, open source or COTS, it’s really the truth for your organization that matters. No one else’s truth will do. Links to mentioned tools: CA Harvest http://www3.ca.com/solutions/Product.aspx?ID=255 CVS http://cvs.nongnu.org/ DotProject http://www.dotproject.net/ Eventum http://dev.mysql.com/downloads/other/eventum/features.html Rational ClearCase http://www-306.ibm.com/software/awdtools/clearcase/index.html Serena Pro http://www.serena.com/Products/professional/Home.asp Visual SourceSafe http://msdn.microsoft.com/vstudio/previous/ssafe/productinfo/default.aspx Randy Wagner is a Contributing Editor for CM Crossroads and VP of Technology Development with Taylor Bean & Whitaker in Ocala FL. His experience ranges from major financial institutions to multimedia multinationals to the Federal government. Working in small to large project efforts has given him a unique perspective on balancing the discipline of SCM and enterprise change management with the resources and willpower each organization brings to the table. You can reach Randy by email at SR_71_98@yahoo.com.
Set as favorite
Bookmark
Email this
Hits: 8369 Trackback(0)Comments (1)
|
| Last Updated on Sunday, 05 August 2007 15:02 |
TrackBack URI for this entry
Subscribe to this comment's feed
