Is a closed source solution with good APIs a better approach than an Open Source solution?
Curious to hear from the people who really understands the benefits of Open Source solution.
Would you rank a "closed source" solution with a great set of easy to use APIs on the same level as a good Open Source solution?
So for example, lets say your company needed a blog. You could go and download any number of Open Source blogs and customize it to your companies needs, or you might spend money on a proprietary blog system that forces you to do things a certain way, or would you rather a closed source (still a proprietary) solution that "out of the box" had you do things a certain way but also offered APIs that allowed you to build you own interface or feed your blog to another solution?
From a business consumption perspective, is a closed source solution that has a great set of APIs to interact with a better approach for companies than Open Source? Putting the vendor on the hook for patches and security yet giving you the leverage to customize how its used.
For the record: I still side with Open Source. The ability to find bugs, integrate with the application, and the whole learn from others approach is invaluable to me.
Answers (9)
Sounds to me like this the 'hosted vs. SaaS' debate. The answer to this will really depend on the goals of your business, and of course, the expertise and resource you have available.
Having access to the source code is fantastic, since it gives you a great way to - in theory - take matters into your own hands and diagnose any issue, and extend with any feature, you so wish. If you're in a large corporate environment and you need to build in a custom extension to make it acceptable to your users (eg. integrate with your company's proprietary SSO solution) then this can be invaluable.
The question you need to ask yourself though, is - am I REALLY likely to be doing this? Will I have the time to learn how the application is structured, and how to extend it? Do I have the time and expertise in my role/team to dig around and diagnose, much less patch, test and deploy fixes for, issues? Or would I rather just pick up the phone, wave an SLA at the development team who originally built the thing, and have them fix it? Will I have time to continually upgrade and patch the software to deal with security fixes? Do I have the infrastructure to manage all of this? Oh, and you do have to host the damn thing too (although judging by your job title this probably doesn't concern you too much :)
Also, to make all of the above happen - are you relying on the enthusiasm of one or two people in your team? And if so, what happens when they're not around and something goes wrong?
Of course there's no 'right approach' it's a judgment call, and based largely on the skills of you and your team. And it depends on the capabilities of the product you're actually working with - not all APIs are created equally and if your vendor is offering one, it pays to go over it with a fine toothed comb to make sure it's really offering true data portability and not a walled garden.
Asa B
Director, Systems Engineering at Send Word Now
Best Answers in: Computers and Software (4), Computer Networking (2), Internet Marketing (1), Web Development (1)
It has been my experience that the issue of open source vs closed + api has always come down to technical experience of the IT team.
If you can support the open source solution inside and out with no problem with your existing IT staff then its a no brainier, open source is usually chosen.
If you IT staff has limit experience with the product, then a closed source solution with a good API is chosen.
I will give you two examples:
We needed a bug tracking system, one we could customize to our business model and flow.
Instant top of the list product is Bugzilla. We had lots of IT staff but in the end we had no PHP skills. We didn't have the right people to support a Bugzilla we customized up.
In the end we went for a Paid product with a good API. An extension of our help desk system.
Recently I needed a visitor sign-in system / software for my data center, our log book was just out of date and hard to read during an audit.
All the paid products were very nice but really expensive for what I needed. The cheapest being $300
I looked for open source products, there were none really. In the end I customized a plug in on a virtual appliance TWiki called commenter into a visitor sign in application. Easy to support and free. Did everything I needed.
I think most times the decision will come down to supporting the application and overall cost. Sometimes bigger business needs to have an expert to call when things go south. In smaller businesses, sometimes you wing it.
Each solution has its place. You just have to make that decision in the best interests of your business and your goals.
Its not a question of open or closed and its definitely not a question of Hosted versus SaaS. Its about whether the solution is component based, tailored, scalable and replaceable.
For instance if you opt for a closed solution with really great APIs - that works so long as everything you need to do has been anticipated by the API provider. Unless you use a standardized api (like open-social) or an api that is so dominant that the market provides good adapters to standards (like Facebook ) you will always be dependent upon the development and deployment plan of the closed system you've selected.
That's the obvious drawback, but 9 times out of ten, if you've selected carefully, you don't really need more than they've provided.
The drawback to an open model is that not only CAN you modify it or adapt it internally, you are usually EXPECTED to, which means that you can't really count on just dropping it into your framework and having it function off the bat with your existing system.
my final answer: In my opinion "It depends". Use what works, anticipate the likelihood that you may need to customize the implementation, and if that's high, go with code you can modify, or at least with an api where you can replace the closed solution later if you need to. On the other hand, if all the features you anticipate needing are provided, and you trust the closed source solution provider to grow with the market and demand and provide "new" "hot" features, then fit your project to the "great" closed APIs (although, its kind of like looking for the White Stag).
A very interesting case study is Apache or MS IIS. 90% of users could probably use either one. Almost all users ever need to do is change configuration, its a VERY small percentage of users that need to custom compile apache, and as far as I know, you can't customize the IIS implementation. If you need something very special done, you build an ISAPI extension (dll).
Links:
If a closed source solution is within your budget, and closely fits your needs then it is usually the safe bet. That said, if extensibility is a major requirement then do not expect that the closed-source solution will provide superior benefits in terms of support. Either way pay close attention to the license model.
I think you actually answered the question yourself, Eric. In my experience, the answer to this always comes down to the two main points you mentioned. Do you NEED the flexibility of an OSS solution? If you have the resources, and the need for true customization, then OSS is always a great option.
Regarding patches and security, a well maintained OSS project with an active community and a wide install base is generally going to be ahead of the curve when it comes to bug fixes, etc.
As I said, it really comes down to evaluating your resources, determining your needs, and finding the solution that best fits.
Hope that helps!
Jon.
Istvan N
Technical Lead & Information Technology Services Consultant - linkedin2istvan at gmail dot com
Hi Eric,
i think the main question is, whether you would need support to your application developed by the API. Some of the interfaces are really closed, and like windows help, they are long, but not helpful.
On the other hand, if you have open source, you should also have the right people with you, because then YOU should decide, what possibilities your app could have.
i think, bugs are also there if you buy the solution, and not have it as open source. The main difference -as i see it- relies on the support on this particular software to be developed.
hope that helps.
Cheers,
Istvan
From an enterprise perspective:
I would opt for a "closed source" solution that offered well documented and broad APIs. While I do support Open Source efforts, purchasing a solution puts the burden of maintenance on their staff and giving me "experts" to call at 1AM in the morning. So if I can put a purchased software in place, tie the software into the necessary systems, create a customized user experience, and then let perpetual motion take over - all the better.
Now my answer would flip if an expert programmer, etc. was on staff.
-Michael
Tim H
VP, Engineering at The Gaming Krib
Best Answers in: Software Development (4), Staffing and Recruiting (3), Web Development (3), Enterprise Software (2), Computers and Software (2), Education and Schools (1), Job Search (1), Product Design (1), Career Management (1), Information Storage (1)
Speaking as a expert programmer who's experienced both, I'd give a qualified "no" to the closed source solution.
The main reason being that most major closed-source products aren't supported all that well. Unless you're taking something like z/OS, support these days even on big-name products is often an exchange of emails with someone twelve timezones away who's barely comprehensible in written English and has almost as little direct contact with the developers as I do.
Last time I had to resort the vendor support, the way the problem was finally resolved was by realizing that the vendor kept asking the same oddly-phrased question over and over and that the answer had to do with basic assumptions that were wrong. The actual support person never did catch on.
Open-source support can be spotty - although just as in commercial software, the more popular the product, the more people are likely to be supporting it. However, if an apache module misbehaves I do at least have the consolation that I can run it through a debugger while waiting for an answer.
To echo some of the other responses here, your analysis should focus on cost.
Assuming that both solutions meet initial requirements equally and initial costs of both are comparable (unlikely but let's assume it), the decision should be guided by "cost of change" of the system. As you find defects and/or need enhancements, the cost of fixing defects or developing enhancements is different in the two options.
What you'll find is that for the right open source based solutions, the cost of change is dramatically smaller because the community behind the open source project fixes defects faster and is developing enhancements almost before you need them (because others in the community are driving them). This is not true for all OSS solutions but for the select right ones. The trick is to know which ones.
Hope this helps,
Gautam