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."
... other than it was written by a person who used unsupported software then complained about the lack of support.
Steps 7-9 are about companies working to develop the product or provide support for it. Why would that matter? Should there be a company, it doesn't actually guarantee anything. Actually it can be worse. If the company stops the development, the whole product can die.
Instead look into how many different companies are behind the product or how many main developers from the community are working for it. How often does the project get a new company/developer to join in. Everybody quits at some point, so the project will live only if new ones are joining the project.
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.
... on this guy's list makes sense to me, for having encountered the situation in practical life, more than once. Traffic-attracting set-up or not, the article does make some sense. I would recommend it to younger guys preparing to do their first software project as a team leader, project manager or software architect.
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Minor quibbles: it's friggin blog post, not an "article." And it's not about "navigating an ocean of open source" in any sense that you might imagine. It's more along the lines of an About.com "Here are ten tips for using Open Source in your business" page.
However, there's a lot of truth in it, and points well worth discussion.
When, exactly did we wind up being our own support desks? When did Google, forums, and bug lists become the primary resources for solving problems with software and hardware?
I'm staggered at the issues that I have with a Google branded Android phone running Google branded apps within Google branded operating system. At the end of the day it is IMPOSSIBLE to get any response from anyone at Google to any problem.
This, to me is everything that's wrong with Open Source, even Corporate Open Source; an attitude that goes way, way back to the days downloading Linux boot floppies by modem, then struggling to get X windows or a modem to work using only Man pages and snotty comments from geeks.
There was a time when I would spend hours or days fighting with recalcitrant software trying to make it work. I can no longer be bothered. I know I can install a Windows or Ubuntu variation and they'll just work. I know that LibreOffice will just work 90% of the time. After which I'll boot up Windows and use MS Office.
Beyond that I'll try a software package (Android apps too) once and if it doesn't work out of the box I'll toss it. And if all else fails, yeah, I'll pop the money to buy a commercial, closed source package. Life is too short.
Three Squirrels
I work in a consulting company and got a basic training in project management, including some risk management:
Assess the likeliness of the risk, and the impact on your project.
A) If you use an OS component sucessful for several years, developed on a stable background (e.g. Apache foundation etc.), then the risk that it wont be supported reasonably or that you have to support it alone.
B) If you use a newer, but fashionable component, there is a moderate risk that it wont be developed in the direction you like it to be
C) If you use something vey new, and special, then there is a high risk that you may end up maintaining it alone
Severity:
1) If you use a small library, which does an isolated task for you, the most severe thing which could happen is that you write this task yourself (which may be significant work, but far away from a failed project)
2) If the library is more complex and is more in the core of your functionality, doing the rewrite transparent to the user may be a hard task, and if reproducibility (e.g. of simulation results) in needed, very hard
3) Frameworks/programming languages. Well. If you bet your ass on the wrong framwork/language, and represent the whole appication logic in it, and something goes wrong there, then you are fucked. Consider that you may end up rewriting the project completely, and possibly (if there is a compatribility problem visible to the customer), loosing the customer.
Normally: Reject risks worse than A3, B2, or C1.
Customer ask for it: cover your ass, it must be in the requirements then. (iff customers insists in framework xyz, he can have it, on his responsibility)