How To Approve the Use of Open Source On the Job 123
New submitter Czech37 (918252) writes "If you work in an organization that isn't focused on development, where computer systems are used to support other core business functions, getting management buy-in for the use of open source can be tricky. Here's how an academic librarian negotiated with his management to get them to give open source software a try, and the four phrases he recommends you avoid using."
"Open Source," "Free [Software]," "Contribute," and "Development" appear to scare managers away.
Nobody ever got fired for buying $big_corp (Score:5, Insightful)
Old saying. Nobody ever got fired for buying IBM. Nobody ever got fired for buying Microsoft. Nobody ever got fired for buying SAP. It's a simple cover-your-ass game.
Managers, unless they have a very special bond with the company (like, say, they built it from the ground up) don't give a shit about the company. They care about their ass. And when the question is whether to blow a million of company money for software they don't know jack about but has a big name behind it, or to save the company a million bucks using software they don't know jack about but has no name to it, they blow them money.
Because they needn't explain why they did it. It's IBM/MS/SAP, how should he have imagined that it's no good?
Re: (Score:3, Insightful)
Unless you can find a written policy forbidding it, just do it.
Its easier to get forgiveness than permission.
Chances are you won't find any policy, unless you work for a big bureaucratic compartmentalized organization. Even then, in the absence of a written prohibition, cost savings can sell the day as long as you provide a support contract. (Some how bean counters become blind to expenditures on support contracts that never ever get exercised).
Re: (Score:2)
Getting forgiveness is only available from C-Level on. Below, they just kick your ass out on the street.
Re: (Score:1, Informative)
Getting forgiveness is only available from C-Level on. Below, they just kick your ass out on the street.
In real life; almost never. You are going to have to check your own company carefully. Likely this will only happen in a really big company where you already had an explicit warning about open source. Make sure you read through all your IT policies. If there is an explicit one against open source in some way, then always act ignorant ask your manager before breaking it. "Hey, there's this really neat package Gimp which will let me make that special photo we need. It will save me thousands over buying P
YMMV (Score:2)
Its easier to get forgiveness than permission.
Not always. Not everywhere.
My first instinct when a geek summons up a Slashdot meme to make his case is to do precisely the opposite of what he suggests.
Re:YMMV (Score:4, Informative)
My first instinct when a geek summons up a Slashdot meme to make his case is to do precisely the opposite of what he suggests.
But it isn't a slashdot meme - it is a Grace Hopper quote well known long before Slashdot existed, and rarely encountered on slashdot.
Re: (Score:2)
Re: (Score:2)
This is why you never give people admin rights. They'll randomly install shit and when something breaks, go to someone else and let them spend (potentially) hours of their time trying to figure out what went wrong.
If you think randomly installing shit is fine, I think it's fine to just reimage your machine without bothering to see if your stuff is backed up.
When you're at work, it's not your equipment. It's the company's and yes,
Re: (Score:2)
Re: (Score:3)
Oh, plenty of people have been fired for buying Oracle. Their enterprise apps are a bad joke.
The joke's on the poor sap dumb enough to buy them.
Re: (Score:3)
Their enterprise apps are a bad joke.
Re: (Score:3, Insightful)
Oh, plenty of people have been fired for buying Oracle.
Yeally?
Their enterprise apps are a bad joke.
Yes, but they're such an *expensive* bad joke that it is too embarressing to too many important people to write off the cost, so usually, the system is kept and forced to work and declared a success.
If you fuck up a $100k contract, you'll be fired. If you fuck up a $10,000,000, people will work very hard to find a way to make it not look like a fuckup, especially if they've been involved in any way at all.
Re: (Score:2)
> Yes, but they're such an *expensive* bad joke that it is too embarressing to too many important people to write off the cost, so usually, the system is kept and forced to work and declared a success.
> If you fuck up a $100k contract, you'll be fired. If you fuck up a $10,000,000, people will work very hard to find a way to make it not look like a fuckup, especially if they've been involved in any way at all.
This. Generally true, I think, of any ridiculously expensive fuckup. What generally happens
Re: (Score:3)
I would fire someone buying SAP period. Interestingly their products are mediocre at best, but the real scam is everything surrounding the product. You don't buy SAP, you get a tailor made software. To find out what you need a a team of consultants will monkey around your business for a month or two, at your expense. Then a few developers will write 5 lines of custom business logic binding exciting modules together and swap a few logos and acronyms. On top of that you need to train all users in the most bas
Re: (Score:3)
Wait, so they do work, and you have to pay them? What a scam!
Except for the really edge cases most SAP installations cover the exact same grounds. What are the chances that, for example the accounting, which is strictly governed by laws, is radically different from one shop to the next? In few cases a shrink wrapped solution would have done the job too.
And provided it works, what's wrong with that?
Except that you are billed around half a million for the "integration" efforts.
What SAP sets itself apart from shrink wrapped solutions, is integrating with existing legacy or non administrative systems. For example th
Re: (Score:2)
d'uh - the people "buying SAP" are C-level people signing it off. And they never get fired, they simply leave to spend more time with their family due to the stresses of their incredibly stressful job.
Same applies if the company goes bust - they still get first dibs on whatever payoff cash is left over.
Re: (Score:2)
"But everybody else is using IBM/SAP/MS? They are successful!"
Re: (Score:2)
Experience? No. MS/IBM/SAP are certainly NOT to blame when their product don't run well in your company.
For some odd reason, C-Levels tend to be kind religious. Not in the orthodox sense, more in the sense that they follow some creed from some consultant, some "management standard", some other holy book that tells them how they should be. That these holy books all ignore the fact that humans are humans is something I'll never quite grasp, but so be it.
Since MS/IBM/SAP are certified to follow those creeds to
Re: (Score:2)
I do have a job. Let's say it deals with security.
The main reason why I have a hard time greenlighting the use of OSS is simply that very few of it comes with the relevant certs, something the relevant commercial software will almost invariably have. We could of course audit the living shit out of the OSS packages ourselves... which we actually celebrated once with the result that it's more expensive.
This is admittedly a very, very specific case and I don't think I'd cite it as a reason to avoid choosing OS
Re: (Score:2)
Re: (Score:2)
Yeah, and I find it really funny that people think that way about Open Source. Who has managed to pin blame on a software company in any meaningful way? Who gets support that is guaranteed better than community support without paying for it? You can usually find consultants for any important OS software.
Re: (Score:2)
That's not even a requirement. I was puzzled by the same when I asked my first boss (back in the early 90s) why no chance to try Linux for some of our lesser important systems. His answer was, in all sincerity, "but who do we sue if it goes wrong?" I was sitting there as puzzled as you are, thinking "You want to sue MS over their crappy OS? Good fucking luck, idiot!"
Later I learned that this isn't even the point. The point is that you COULD sue them. You won't, of course, but you have someone to shift the b
Pet projects and the hidden skunk-works. (Score:5, Interesting)
In small businesses - often the best foot in the door for open source software is a pet project, something you can do transparently to design something to show management about the advantage of the software has over more traditionally licensed fare. Being able to speak the language of IT management helps - Cost of Ownership, Return on Investment, being able to present facts based on license costs is also helpful - management listens to dollars and sense, followed by legality.
Of course, if your business deals with large vendors who have a stake in keeping things locked to Microsoft, Oracle, IBM or HP - you are fighting a steeply uphill battle.
Re: (Score:2)
And in what way do you think you are doing a better job with ISS + C# and MSSQL? The Apache + PHP5 + PostgreeSQL stack is in par with the MS stack and the primary fault lies with the developer of the application. That same developer would have botched the ASP site equally well.
GPL (Score:1)
Re: (Score:2)
It depends. In my experience they have heard of freeware, which often comes with a "non commercial" clause and the legal department said that is evil. Free software is freeware right? The better educated managers know about the GPL and that makes all our software free software, but we wanted to sell that software. All free software is GPL right?
Re: (Score:2)
How is my reproduction of incohesive rambling of managers relevant to the TFS. I get away with allot of Free Software libraries (Apache/MIT/BSD licensed) integrated in commercial products. But each time I have new manager it takes a while to get them up to speed with the realities of licensing free software. All libraries used in out software needs to cleared with legal, so in the end it does not matter what the manager thinks.
Re:GPL (Score:4, Insightful)
.Avoid terms with negative connotations, such as "GPL" and use the more acceptable term, BSD. As a hiring software developer, I know of what I speak.
That wouldn't work with my old boss, who would take any unfamiliar word and enter it in Google, and then hit the "Images" link for screenshots or easy to understand slides.
Suggesting BSD would then be career suicide.
The best way I know of suggesting free (as in breasts) software is to present it with the pricing for someone who sells support. If you can buy the support through the hardware vendor,all the better.
Which is one reason why there are so many IBM / Red Hat systems out there.
With a small company, this is easy. (Score:5, Interesting)
However, with every SMALL company I ever worked for, introducing Open Source software...was a blessing from above to them, it's free, it's cheap...and the programmers are enthusiastic idealistic & proud of their work, so bugs gets fixed faster and new features are introduced frequently as opposed to the commercial bug ridden bloatware where companies are afraid to admit ANY wrong doings as they're afraid of liabilities and such.
I've been using Blender (3d Software) for over 10 years now, making a living of it, and all the commercial alternatives are slowly fading away with their fanboys. Long live Open Source, it really is true freedom.
Re: (Score:1)
Well, if free is the problem, you can always cut a big check and send it me when you adopt such software. Of course I will channel all such funds received into furthering the benefit of mankind (or at least 1 man). I will even gladly give you a receipt for your "purchase"
Re:With a small company, this is easy. (Score:4, Interesting)
i have been working in two of theand really big companies (both > 100k employees), one Japanese, one german.
in the Japanese company there was no strategy regarding software and "whatever works" was fine, which included open source.
the German company had the strategy to explicitly manage the obligations from open source. effectively the rules were:
Apache style, bsd style licenses and LGPL where white listed
GPL 3 was blacklisted
GPL needed special consideration (so kind of blacklisted)
Re: (Score:3)
Considering that those licenses all cover distribution I don't see the difference for an in company product. Especially since the difference between GPL and GPL 3 deals with preventing locked bootloaders. Now if you're doing embedded development or selling software, it's a completely different story. I don't agree with it, but I can see why companies want complete control of their products.
Re: With a small company, this is easy. (Score:1)
Doesnt gpl3 also have effects on web services? I thought it folded in agpl.
GPLv3 != AGPLv3 (Score:3)
Re: (Score:3)
A company I worked for had the exact same policy. Though it was a bit more formalized in that if you want to use a not-previously-approved piece of software (commercial or open-source), the license and justification must be sent to Legal in order to vet it
Re: (Score:2)
inadverted creation of obligations:
-the matlab compiler signs code for execution. no GPL3 is compatible with it (even if they never mention the term "DRM" in the manual).
-what happens if a part of your software sits in controllers owned by your customer (for whom you develop) which logs data as a service offered to his customers? as long as you own the controller they dont need to pass the code on, but at whuch point should that happen?
-assume that you develop software to be delivered to a daughter company.
Re:With a small company, this is easy. (Score:4, Insightful)
There IS no such thing as a free lunch.
Free as in speech, not as in beer.
There are many advantages to Free software, such as Freedom, being the microsoft doesn't have leverage over you. If your a large enough corp, you can write whatever features MS will never give you, or pay red hat to make them for you.
Re: (Score:2)
Until a data issue means you have to ship a database backup or large data file to the developer to reproduce and fix the issue, and you have no company to make a data confidentiality agreement with. Or the main developer is outside the company, because international law is a bitch.
Want to fix it yourself? Now you've signed up for internal maintenance unless you can get it accepted upstream. And without a repro, and bad data to test with, the need for the fix is not obvious.
As always, your circumstances wi
Fictitious data to trigger a misbehavior (Score:2)
and you have no company to make a data confidentiality agreement with
Why can't you execute a data confidentiality agreement directly with the main developer as an individual contractor?
And without a repro, and bad data to test with, the need for the fix is not obvious.
If a patch is made with the intent to correct misbehavior, this implies that a cause of the misbehavior has been found. And once a cause is found, it shouldn't be too hard to generate fictitious data that likewise trigger the misbehavior.
Re: (Score:2)
And what if the developer says no? There may be many reasons for it - including legal obligations elsewhere (day job, say) that may prevent said developer from "commercializing" their work or even accepting money for the task.
Or even a non-compete, if you happen to be with a competitor of whom the developer works for (you pro
Re: (Score:1, Insightful)
When I tried this with bigger companies, it was H*** on earth to try them to embrace Open Source. One of the business managers simply doesn't understand the concept of a free lunch.
There is no free lunch. There's just economies of scale, and sometimes a free ride.
It's like hitch hiking. If someone stops and picks you up, and is going the same way, you might get a free ride, otherwise it's "cash, ass or grass". If someone's already made some OSS that does exactly what you need, you get a free ride, otherwise you still have to put the work in or pay someone else, to turn it from what it is, to what you need. Sometimes that's a short walk, and sometimes it's a year long trek.
I've been on
Re: (Score:2)
Except that every fork produced has a free Lunch Replication System built in nowadays.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
hidden advantage to open source (Score:3)
It seems like the best bet is to not raise the question in the first place. Management doesn't need to know that Apache is free, for instance. And there are commercial and free versions of Nagios, Tripwire, Sendmail, and so forth. We have over half of our prod servers running Red Hat, for which we buy maintenance, but in the lab we run CentOS. The Open Source community realizes that companies have a compulsion to spend money, and there are companies that will sell you free software (think about that phrase for a minute...) to satisfy this requirement.
Don't sell Open Source, just present the options (Score:5, Interesting)
So in other words, put Open Source on the table just like any other software. Don't try to differentiate it as "Open Source", because if you do, decisions makers and stakeholders will wonder why you're putting extra effort into justifying it.
Put it up with a support contract and necessary consultants just like any other piece of software and you'll get approval.
Re: (Score:2)
exactly lay out the facts:
product A is owned by commercial company with billions of dollars and developers backing the product
product B is written by some really smart people in their free time that may help you on a forum or in an IRC chat room if they can
You hit the nail on the head. That is one of the big problems indeed.
Re: (Score:2)
exactly lay out the facts:
product A is owned by commercial company with billions of dollars and developers backing the product
product B is written by some really smart people in their free time that may help you on a forum or in an IRC chat room if they can
You hit the nail on the head. That is one of the big problems indeed.
There is sometimes overlap between the two groups. For example, Linux.
Re: (Score:2)
Re: (Score:2)
One of the big problems is that people actually believe that stuff. In this reality, "backing the product" doesn't mean accepting blame or necessarily fixing your problems with it, or in fact anything guaranteed useful.
Re:Don't sell Open Source, just present the option (Score:5, Informative)
Good idea, but incomplete:
exactly lay out the facts:
product A is owned by commercial company with billions of dollars and developers backing the product
product B is written by some really smart people in their free time that may help you on a forum or in an IRC chat room if they can
Product C is free, maintained by a mid sized company, and they sell support contracts
Product D is proprietary, owned by a company that might be bought by the competitors, who may or may not keep supporting your product
Product E is a great software product, proprietary, but your company is not in the target market, so licensing and support don't match your needs
Product F is proprietary, and you might need small development tasks on top of the product. Only can buy from the owner.
Product G is free, and you might need small development tasks on top of the product. You can buy from the developer, build your own, contract, whatever.
Add to that, whether there is an easy way out should the unthinkable happen (end of life for products). Does the software support industry standards? Are there alternative implementations of these standards? Have you tested compatibility?
I'm not hiding the technical or strategic advantages some proprietary products might have over free ones, but they are stated everywhere, only trying to lay out more aspects you need to care about.
I think regarding the article you just need to do your job, and lay out all the things you consider. Free software is almost always better in the long run, but it's only sensible to lay out everything you considered, so others can make the best decision.
Re: (Score:2)
Agreed. I take a dim view of managers that demand I "sell them" on what I think is the right choice.
It's their job to make decisions wisely, not my job to force what I consider wise decisions down their throat. I try to be honest about the pros and cons. If the choice lies within my authority, I try to make the best choice. If it's within their authority, then I hope they make the best choice. If they don't, that's their problem.
I guess this response must reek of someone who has little patience for fool
Re: (Score:2)
Don't try to differentiate it as "Open Source", because if you do, decisions makers and stakeholders will wonder why you're putting extra effort into justifying it.
Well, why put the extra effort into justifying it, then? What's the real answer? Is it because I have been brainwashed to like it, and must turn everything into OSS just because it's so awesome?
Re: (Score:2)
Consider the scenario:
Product A has technical features X,Y,Z
Product B has technical features X and Y (not Z).... but it's OSS!
Most decision makers will then ask, what's OSS? And when you get into the weeds of explaining nuanced differences in licensing, they'll quickly decide that the features outweigh the license benefits.
Generalize much? (Score:4, Interesting)
Not where I'm working (a giant company). On the contrary, we are rather suspicious of commercial solutions — because their costs tend to run up pretty quickly (we have a large user-base) and their license terms often enough turn out to be rather enslaving (Oracle is particularly scary in this regard, from what little I've overheard from the company lawyers).
Sure enough, free software has its rough edges, but so does the commercial kind. And we have enough bright people to fix the problems (bugs or missing features) in the open-sourced packages, whereas with the proprietary stuff you are usually at the mercy of the vendor. We still use some commercial programs, but, when choosing a software solution, the program being proprietary is a negative, rather than a positive factor.
I wish, it remained possible to get the source for the commercial packages as well, but with modern attitudes towards theft of intellectual property as well as the wide-spread propensity to use the terms "free" and "open source" interchangeably, this is not an option...
Re: (Score:2)
3 Fortune 150 companies, and we always had someone who could get a support ticket opened to major vendor. I had to push a bit to find the contact, since this information is usually kept close to the chest.
Basic vendor rules are:
1) Be running the latest version
2) Be ready to upgrade to the next patch in order to have your bug fixed
3) All of the other patches, improvements, and bugs will be in the next version
These can be very limiting, and I would prefer to have the source even if all I do is submit a diff.
Re: (Score:2)
Of course it's generalised. Why? Because that's what people do, we generalise.
Why is a cheap Chinese product automatically assumed to be worse quality than an expensive USA made product?
Why are cheap games automatically assumed to be garbage compared to $80 titles?
Now given that inherent bias that fuels the many generalisations on cost, why should a free word processor be anywhere near as good as MS Word? It can't be, otherwise it would cost as much as MS Word right? People don't give away something for not
My experience (Score:1, Insightful)
In my experience, showing a side-by-side demonstration of performance followed by the price will get your foot in the door. From then on, deliver and keep foot out of mouth. The low cost of setting up a demonstration of FLOSS makes this fairly simple with no need for a line-item on any budget.
For instance, in one school, I discovered the paid ILS was not working two years after it had been bought. The supplier just didn't bother to fix the problems. I installed KOHA in 15 minutes and showed it to the librar
Cost is irrelevant, support is everything (Score:5, Insightful)
Most managers who have had any dealings with a software rollout know two things:
First is that they won't actually get what they think they have specified
Second is that there will be problems (see point #1), overruns, differences between what's required and what's delivered and that getting the software functional is only a small part of the job. The rest is integration, training the users, supporting the thing for 5+++ years, implementing upgrades and bug-fixes
These managers also know that once a project has been signed off, the money has, just that moment, been spent. Companies don't think of money, they think of budgets - so once you have gone through the approvals process and got your budget and your go-ahead the project is effectively a sunk cost, but one that has not yet delivered anything. As a consequence the manager in charge of the project will be deemed to have failed if he/she needs to go back and ask for more, in order to deliver the project.
So, in their minds they want insurance - and indemnity - above all else. Even above cost savings. They want to know that in return for $<megabucks> that when things start to go wrong, their commercial relationship with "the vendor" entitles them to get support, advice, expertise, fixes, customisations, training, documentation and upgrades. Those will all form part of the cost-case and whoever approves the case will expect, maybe even require, that those items are included and form part of the contract. As they know that there will be the need to call upon those services. If all they get for using "free" software is a pile of code, then that is usually the smallest part of the project and often the least expensive, too. The real cost, over the project lifetime comes with all the extras and services they get from their vendor - but which "free" software is very poor at providing, and absolutely does not guarantee.
If you go to get approval for a project of any significant size, not having included those items will mark you out as, at best, a newby and at worse: completely unsuitable to be managing a project. It's like if you buy a car. The cost of the vehicle is only one aspect. The cost of servicing, fuel, taxes and depreciation are major factors that should be included in the plan. That they aren't is just an indication of how poorly most people approach a major purchase - and why they'd never make a project manager.
Managers read that as... (Score:4, Insightful)
"No support contract."
Thus what they see is the possibility of problems that take days or weeks to resolve, while getting told STFU NEWB on some mailing list.
That's the experience many clients have had with FreeBSD, for example.
MOD PARENT UP! (Score:3, Insightful)
Particularly the STFU NEWB part. This is exactly the reputation open source software has.
Re: (Score:3, Insightful)
Except often it goes like this:
NEWB: I have . How do I solve it? .
List doesn't reply within 10 minutes.
NEWB: Look, I have to have this fixed by Monday. How do I solve it? If you don't solve it for me then I have to move to
List doesn't reply within 10 minutes. NEWB gets angry
NEWB: Its such a simple issue. I can't belive nobody can solve it. (Oh the irony). Bump bump bump.
List: STFU NEWB.
Don't expect support-contract-like behaviour from a list - remember they're volunteers, there's no "SLA" and they do
Re: (Score:2)
Some simple steps for success ...
I agree. Most lists and forums take a dim view of repeated questions, ones that are "obvious" and ones that the small minority of helpful posters feel are irrelevant. As you say, there is no guaranteed response time - if you get any response at all - and no guarantee that the responses you do receive will be correct or even on-topic.
Those are why people pay for support. Those are the factors that companies value and the time (equates very closely to money) taken to both supply the requested information, tr
Re:MOD PARENT UP! (Score:4, Insightful)
You're absolutely right. However on a lot of high profile projects, that won't get you anywhere.
I remember a while back I was using a very high profile/popular data access library which shall remain nameless.
I found a fairly breaking bug in a semi-common scenarios. I poke at the mailing list, not asking for it to be fixed, but simply if it was a known issue, as again, it was a fairly common case, and I could pin point the exact snippet of code in the source where the issue was (but, being unfamiliar with the code base, couldn't easily fix it myself).
Instead of a simple "yes or no", I was more or less told to write a failing unit test or shut it, in not so nice words.
So I write the unit test, after taking several hours to find the exact guidance on how to write it (making a test for a database access framework that stays within the realm of unit test and not integration test differs wildly from project to project), I do so, submit it...all around half a day of work.
In the meantime, I patched up something on my end that worked (but it was a hack, so I couldn't really submit a patch) in a few minutes.
2 _years_ later, I see in my email that my bug report just got rejected because of a small mistake in my unit test (that still didn't change the main code path it was testing), and to this day the bug is still present, and whenever this is raised in on Stack Overflow or whatever, people just say its a scenario that isn't supported, even though you can see in the code that it should be, and its just a naive sort order mistake when looping through some array.
I wish it was an isolated case, but it basically is always like that unless you're inside the project's "clique" or you happen to find a bug that is particularly interesting to fix. Yes, they're just volunteers, but if they don't want their project to be of world class interest, then don't promote it as such.
TL&DR: Big projects with a lot of marketing pushes saying they're great for real production use, then don't support it as such, are far too common.
Re: (Score:2)
A standard support contract with Microsoft is for them to provide security and bug fixes, not to research any random issue. Your issue sounds like a random issue.
If your situation isn't repeatable on different hardware, then it's probably not a Windows bug and certainly isn't a critical bug. If it's repeatable on hardware from the same vendors, then it's probably a bug with the firmware on one of the two pieces of hardware or poor configuration on your part. If it's repeatable on hardware from different
Re: (Score:2)
Well, that's about right, however, that's also the problem. In a professional setting, you expect support, and not just "when and if we feel like it". NEWB in this case may not have ever even heard of a message board or listserv. Someone says "support is here", he goes there, no one answers.
NEWB doesn't know or care about the theory of open software, building relationships with the list members, doing research on the code base, etc. He found a problem and wants it fixed, and wants som
Re: (Score:2)
Ah, the old "bad behavior exists, therefore your example must be of the bad behavior"!
No.
I've (repeatedly) seen people go on to these lists, ask a polite question, and receive STFU NEWB or analogue response very quickly.
Generally, the more difficult the question the more likely it is to receive this response.
Ever wonder why Stack Overflow is so popular? Volunteers there get im
Re: (Score:2)
Particularly the STFU NEWB part. This is exactly the reputation open source software has.
It's kind of understandable though. What if you went poking the Windows Kernel Team with questions like "how do I get this printer to work"? They would say "we don't have the time to help with that". Then you would contact a Microsoft support engineer and his response would instead be "I'm happy to help you, let's get started".
In open source world, commercial distros like Red Hat do have proper customer support in place, but various random open source projects do not have that kind of support options. You c
Zero budget usually helps, plus have a fall-back (Score:1)
- Writing from scratch takes too long, plus the requirements change too late in the game
- Buying off-the-shelf means squeezing blood out of someones stones, and is not customisable
- Evaluating several open source solutions and taking the best, then modifying as needed hits the sweet spot
The only time I really needed to put a strong case forward
link should be retitled to (Score:2)