Slashdot Mirror
Evaluating Open Source
CowboyRobot writes "Jordan Hubbard cofounded FreeBSD and now oversees the Darwin implementation of BSD for Apple. He describes open source as 'finally being openly acknowledged as a commercial engineering force-multiplier and important option for avoiding significant software development costs.' And thus, companies need to know how to evaluate open source engineering as an option for them. In a new article titled Open Source to the Core, Hubbard goes through a typical open source adoption process."
Maybe a little better than seeing all of Microsoft's code open sourced, but don't count on seeing any of Apple's proprietary code. Sure, if we could see the source for everything, right now, we could accomplish awesome things. But what is the incentive for most any software company to release their code when it is almost solely the act of keeping it proprietary that generates their income? If you want to see real changes in commercial software in regards to general openness, then we need to see real changes in the global and local economic model.
I am feeling fat and sassy
Why would you want to cut down soft.dev. costs if an engineer in India costs $400/month?
That is key, as I don't think corporations are even considering that aspect of open source software. Considering that, in all fairness, efforts should be made to contribute back to the community when using open source software, I think that the alleged TCO benefits begin shrinking drastically. I hope this has been mentioned somewhere, since it needs to be a reality. I don't want to see anything hindering the overall adoption of open source, but I also don't want to see the open source community being abused more than it already is now.
I am feeling fat and sassy
"investigation, evaluation, adoption, and communication"
Isn't this true for just about every migration plans?
Investigate -- find out if this will do what you want it to do.
Evaluate -- dig deeper into the idea. Get a better feasibility study with numbers and monetary figures. Make cool looking presentations to the higher-ups that sign the checks.
Adoption -- this is where you SLOWLY incorporate the new with the old. Make sure everything is working well. People may have to do double-duty to work with both systems just so they can give it their blessing (that it all works properly). This is where you train a "core" group of support folks from each department so they burden you less.
Communication -- this really should be earlier on, before adoption. Find people who run this stuff already and communicate whether it may work for you too. See if you can get a "we'll help you through it" before you even adopt.
Again, this isn't anything strictly for Open Source. I'm sure there are nuances and cultures, yadda yadda yadda...but a good plan of action helps minimize risk with ANY project.
The reference to Slashdot was suprising to me being referenced in the ACM without even a footnote because not everyone in IT knows about Slashdot, especially your average .NET programmer:
Marketing. First and foremost, your marketing people will (or should) want to have a prepared message about your use of open source, even if it's only to respond to any questions that may come up. Make sure that they also know enough to make correct assertions about it, or you may find yourself paying the price on Slashdot when one of them makes an embarrassing public gaffe about who provided the technology or attributes it to someone else.
BTM
That was the turning point of my life--I went from negative zero to positive zero.
I agree. In my experience over the last several years, I've found people who use OSS projects tend to be more self-starters, curious, and technically adept.
I joke that you learn a lot with Linux, et al, because you *have* to. Show me someone who is running Linux (or BSD) at home and I'll show you someone who knows and likes computers.