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.
"i mean, why duplicate an airport driver in the core system when the actual product has a really good one? why create an intuitive user/group system when the actual product is really damn good at managing them? i think the point of darwin is to maintain a really slick foundation for an operating system, not an OS all its own."
Maybe I feel Darwin should useful on its own. Otherwise, there is no point in it being opensource other than to get free engineering for Apple.
What I see wrong in this argument is this. Company A charges $100 for selling a product that paid its developers, marketeers, artists, accountants, sales people, people who burned the CDs, boxed it, handles shipping, etc, etc Now here comes the OSS product, giving it for free, download it and install and off you go happily as a freebee. Lets say the OSS developer got a consulting deal and even earned a few bucks. Now this OSS project has been successful in destroying the otehr software company, which in turn lays off lots of employees. Do you really think that the OSS project has helped? Taking this further, big companies like OSS for one reason and one reason only; to have their fat cat wallets filled to the brim. Lets say IBM, SUN, HP, Hitachi, etc have to develop their own OS and apps... each has to employ a lot of software engineers, but what do they do? give some money to OSS and get them to the work and share the loot. Who benefits? Was it the samll individual that benefited? or was it the big corp? Just look for the real puppet masters behind OSS before you contribute your own src code to this plot to take the power of the programmer.