Navigating the Vast Ocean of Open Source 23
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."
What's the point of the article... (Score:4, Insightful)
Re: (Score:2)
To drive traffic to SlashBi, of course.
Re: (Score:2)
I figured Dice would jettison that part of Slashdot since it seems to overlap with their own website.
Re: (Score:2)
Re: (Score:2)
To drive traffic to SlashBi, of course.
Please 'scuse my ignorance. What does "SlashBi" mean? Is that some sort of "bisexool" crack? [I have no irons in this fire; just curious.]
Re: (Score:2)
To drive traffic to the 'business intelligence' side of slashdot (or whatever their current corporate owner is).
Why should there be a company behind it? (Score:2)
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 pr
Biggest problem: support, customization (Score:5, Insightful)
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.
Re:Biggest problem: support, customization (Score:4, Informative)
So you are admitting that Linux had a strong showing in servers? This would be precisely the area that is supposed to be driven by being able to call a company like Microsoft. That's a bit of a contradiction.
You are also giving Microsoft far too much credit as a server support vendor when the real competition is the likes of Oracle, or Sun, or IBM. Microsoft is a lightweight by comparison.
By your own admission Linux thrived despite of this mentality where everyone assumes "you can't get fired for buying Microsoft"
"Desktop" software is pretty lightweight by comparison.
What Google has is marketing. Guerilla marketing just doesn's work with n00b consumers. It's not like professional tools where all you have to do is "build and they will come". You need to dress it up and run TV ads and all manner of flim flam.
Re: (Score:2)
Re: (Score:3, Interesting)
Re: (Score:2)
No. What I'm saying is that companies that developed new products tended (pre-Android) to steer clear of foss precisely because of the perception that they might have to chase some hacker around his mother's basement to find and code some obscure and highly specific issue very quickly. That code issue issue might be of no relevance to anyone else. Windriver and Monta Vista improved this by hiring and building foss expertise extensively (like Google) and providing their own embedded linux platforms for OD
Re: (Score:1)
How come this was labeled insightful?
The situation is actually much easier with FOSS. Try using ms word in a for-profit project. Then try getting hold of the right person to modify/fix it for you. You just can't - and it won't help shaking a small bag of cash at those ms programmers. They are paid already. And you can't get someone else to do it either - no source. (Ms may listen if you are really big, but lets say this for-profit project only generate a few hundred thousand sales - you're nothing to them)
Re: (Score:2)
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.
In which case an emergency commercial line of support is essential. Not to mention that some specialized areas of development are exotic and it's hard and slow hiring those guys. They are usually already hired. That is not to say that oss is not a far superior model if you can get hold of the resources to work on the codebase. Closed source is bad because it removes that possibility altogether if the copyright holders don't want you to do it. There i
Only point #10... (Score:4, Insightful)
Navigating? Beating into submission? (Score:4, Insightful)
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.
Re: (Score:2)
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.
Not even that, really. It's about integrating obscure open source components in the software you're writing. The article doesn't make sense if you try to apply it to running a stock Linux server or desktop.
Speaking from a risk management perspective (Score:3)
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)