Slashdot Mirror
Navigating the Vast Ocean of Open Source
Nerval's Lobster writes "Open source is no longer relegated to the discount software vendor that serves cash-strapped startups. In enterprise software development these days, open source is not only immensely valuable, but increasingly crucial to stay competitive in releasing high quality software at regular intervals in a world where technology is changing so fast and every edge matters. Today, rolling your own logging package instead of using something like log4j is as silly as trying to build your own web server instead of using Apache httpd was 10 years ago. Still, there are other components like guava that are less well known, but are currently making a name for themselves as libraries that can take the solution you are building to the next level of sophistication and quality. Just knowing they exist — and knowing where they fit — can help you design and build better software at a lower cost. In addition to conducting a traditional build versus buy analysis, it's critical to think about the maintenance and support story surrounding an open source package. This article lists some things to consider and questions to ponder."
Speaking from experience here and also as a strong believer in FOSS: the single biggest hassle with using certain FOSS code for commercial use/adaptation can be getting hold of the right person to modify/fix the code for use in a for-profit project. You'd think it'd be easy, right? Just post to the dev list and start a discussion offline about paying them for adaptations, right?
Wrong. Usually doesn't work if you go in cold and the devs don't know who you are, even if you start shaking bags of cash at them over email. Many foss developers work for other companies and aren't interested. If it's sophisticated, difficult code, hiring someone to get across and then hack the code base may just be too slow a fix commercially. This is why Google, Red Hat, Canonical etc snap up key foss developers in challenging areas such as the kernel. Even if their pool of key developers don't know how to fix something, chances are they might know how to get hold of the right person. Notice the inbuilt randomness of "chances are".
The ad hoc-ness of that situation is just not acceptable in many industries. They want to pick up a phone and get the work done now, not chase people around on an obscure development list trying to hire them. It's no wonder that Microsoft et al had the game sown up for so long and that it took a huge company with massive resources (Google) to put linux on so many devices that weren't server boxes.