Related
We're offering Paypal checkout as a way to purchase items on our website, and offer our goods internationally. Our problem is that when a user selects Paypal there's no easy way to set a shipping cost based on their location...
For instance if a user is from the USA, his/her shipping cost will be $3.85
If a user is from the UK, his/her shipping cost will be $5
Aside from having users pre-select their country (which seems pretty flimsy because they could just select domestic, then change their address to something international) is there a way for Paypal to adjust shipping based on user's shipping address??
Does https://www.paypal.com/cgi-bin/webscr?cmd=xpt/shipping/EasyCalculateShipAndTax-outside help at all? It describes a way to (within PayPal's interface) pre-set shipping costs for different destination countries.
It looks like this article and thread may have fallen into the abyss but I thought I might chime in and give my two sense.
The challenges I have struggled with around international sales are really two parts.
First, and I won't dive too deeply as its more related to the merchant service and credit card processing side of the business, but merchant services and payment gateways have yet to deploy a system that roots out fraud. The unfortunate fact is that assuming a customer abroad uses a fraudulent credit card it will almost certainly slide through the gateway and merchant services as a good sale, then deposited into the retailer bank account, only to be identified as suspicious weeks later. Naturally the banks reach in and extract the fraudulent funds and leave the retailer holding the bag.
The other side of it the logistics, and more precisely the competitive or noncompetitive pricing leading to sales.
Amazon.com has been a steamroller throughout the marketplace and many would argue the vast benefits it has brought with it byway of competitive forces. Amazon has been a God send to many particularly small businesses who without the Amazon marketing advantage would be little more than a doodle on the back of a napkin at the looking drinking hole. They are great at reaching a domestic consumer and their impact in the larger international space is growing fast.
But for those of us who try to sell through our own website, foregoing the massive commissions paid to the behemoth, it can be a little daunting to tackle the international shipping.
First, the rates. Getting rates that compete is tough. Have you seen the retail rates from Fedex, DHL, or TNT? They are insanely expensive and unrealistic for a retailer. I negotiated rates with UPS, TNT, and DHL, but the results were not good. Not enough volume to drive real discounts. This is when competing with Amazon makes you feel really really small.
I'm measuring the percentage of lost business against incremental increases to shipping rates and its extreme.
Frankly, as a seller who has evolved through the past decade of Amazon ups and downs I've learned through heartache and loosing lots of money, whether through BiG Bank Merchant Services who take no prisioners or the hefty costs for international shipping. Where I have moved my inventories is away from Amazon and FBA and into fulfillment centers capable of handling all my logistics issues.
For instance, reverse logistics. For those of you who may be new to the term, it refers to the process of returning merchandise from end consumer to merchant. Managing this with international customers can be complex. Additionally, fulfillment centers offer volume rates I'm not able to get on my own with the aforementioned carriers; UPS, FEDEX, DHL, TNT. Rather, the fulfillment operations I work with tend to be flexible and understand the cost correlation associated with international sales.
The fulfillment companies I have used are:
Good - Amazon FBA
Better - Shipwire
Best - Newgistics
I won't ooze over any of them, but I'll say that as my requirements have evolved FBA was incapable of keeping pace. With the other solutions I have full EDI integration by and between me and all my distribution partners. Partners that make life a lot more manageable.
As for international shipping rates that beat retail published rates, check out these international shipping calculators:
USPS
DHL
MyUS
American eBox
``
These will at the very least send you in a direction that makes sense.
I hope this personal recount provides help to those who are transitioning through differing stages of growth.
I'm a CS student, just exploring the SCM space. While doing my own research I came across many different hosted solutions (GitHub obviously, Lighthouse, YouTrack, TeamCity, etc.) - do you think it is actually reasonable to try to host a (commercial, closed source) project entirely in the cloud?
Let's say I'd host code on GitHub, use Jira or Lighthouse for issue tracking, God knows what other hosted PM solution (Basecamp?) and build using EC2 (I can put Hudson or TeamCity on it and use appropriate EC2 plugins for these products to get more computing power when needed).
Is the EC2 bill going to kill me (compared to self-hosted solutions)? Do you think "the cloud" it's still not reliable enough?
This is the way we work at our company. Version control system (git) + agile planning + ticket system/bugtracker + wiki are hosted at http://www.assembla.com for 49$/month for 40 users, private repositories ( https://www.assembla.com/plans ) and we have a micro instance on amazon aws ec2 where jenkins, nexus, sonar and some internals tools are running for free the first year and then you should consider spending like 80$/month for the same service.
So it costs 129$/month for a full cloud solution for a small company (40 users max): reliable, with a good release train of new features by our service providers and with a low maintenance footprint for us.
Compared to self hosted it's not really expensive considering the following costs :
- price of your server (lets say 1000$)
- electricity bills (lets say 30$/month for 100% uptime)
- cost of configuration (to get the same quality as assembla for exemple) and maintenance (lets say 0.5day man per month at 500$/day in france)
The cost is : 363$/month
This should look a bit biased, but finally it's what we experienced.
Regards,
Xavier
There is no problem to use the cloud for hosting, and many large companies do so already. I think NetFlix recently moved solely to EC2. Our whole business runs on EC2, and it's been relatively good so far.
The EC2 bill is up to you to manage -- cloud is all about granular billing for services, and the more you consume the more you pay (we sell a tool that helps with cost controls: http://LabSlice.com). Your biggest cost will usually be CPU power, so stick to the Micro/Small instances until you've got a handle on costs.
It's interesting that people question the reliability of cloud, as the underlying premise is actually to provide more reliability to businesses then they could afford themselves (high scalability, immediate availability of hardware, monitoring, load balancing etc.)
You can make use of AWS Free Account and host your application. If you exceed Free Account Usage limit,you will be charged for whatever extra you have utilized.
Regarding reliability about Cloud, every big firm is moving towards Cloud like Amazon,Microsoft,IBM,HP etc because they found cloud reliable,cost effective and green.
Given your a student and assuming your looking to spend little money, a lot of Git and SVN hosting providers offer free hosting for students or free accounts if your a small team with minimal storage requirements. Check out Codesion's student offering for example (disclaimer, I work for Codesion). This plan also comes with Trac / Bugzilla for your PM requirements. I wouldn't be concerned with security and reliability for the same reason that Simon points out above.
As for CI on EC2 - this is probably your best bet since you pay by the hour each instance is running. I'd recommend using Amazons API to fire up an instance each time Hudson needs to perform a build, store the results of the build on more permanent storage, and shut the instance down when finished. If your doing a lot of CI builds, it might be better to just keep the instance running, but this will cost you more of course.
Related question: What is the most efficient way to break up a centralised database?
I'm going to try and make this question fairly general so it will benefit others.
About 3 years ago, I implemented an integrated CRM and website. Because I wanted to impress the customer, I implemented the cheapest architecture I could think of, which was to host the central database and website on the web server. I created a desktop application which communicates with the web server via a web service (this application runs from their main office).
In hindsight this was rather foolish, as now that the company has grown, their internet connection becomes slower and slower each month. Now, because of the speed issues, the desktop software times out on a regular basis, the customer is left with 3 options:
Purchase a faster internet connection.
Move the database (and website) to an in-house server.
Re-design the architecture so that the CRM and web databases are separate.
The first option is the "easiest", but certainly not the cheapest long term. Second option; if we move the website to in-house hosting, the client has to combat issues like overloaded/poor/offline internet connection, loss of power, etc. And the final option; the client is loathed to pay a whole whack of cash for me to re-design and re-code the architecture, and I can't afford to do this for free (I need to eat).
Is there any way to recover from when you've screwed up the design of a distributed system so bad, that none of the options work? Or is it a case of cutting your losses and just learning from the mistake? I feel terrible that there's no quick fix for this problem.
You didn't screw up. The customer wanted the cheapest option, you gave it to them, this is the cost that they put off. I hope you haven't assumed blame with your customer. If they're blaming you, it's a classic case of them paying for a Chevy while wanting a Mercedes.
Pursuant to that:
Your customer needs to make a business decision about what to do. Your job is to explain to them the consequences of each of the choices in as honest and professional a way as possible and leave the choice up to them.
Just remember, you didn't screw up! You provided for them a solution that served their needs for years, and they were happy with it until they exceeded the system's design basis. If they don't want to have to maintain the system's scalability again three years from now, they're going to have to be willing to pay for it now. Software isn't magic.
I wouldn't call it a screw up unless:
It was known how much traffic or performance requirements would grow. And
You deliberately designed the system to under-perform. And
You deliberately designed the system to be rigid and non adaptable to change.
A screw up would have been to over-engineer a highly complex system costing more than what the scale at the time demanded.
In fact it is good practice to only invest as much as can currently be leveraged by the business, using growth to fund further investment in scalability, should it be required. It is simple risk management.
Surely as the business has grown over time, presumably with the help of your software, they have also set aside something for the next level up. They should be thanking you for helping grow their business beyond expectations, and throwing money at you so you can help them carry through to the next level of growth.
All of those three options could be good. Which one is the best depends on cost benefits analysis, ROI etc. It is partially a technical decision but mostly a business one.
Congratulations on helping build a growing business up til now, and on to the future.
Are you sure that the cause of the timeouts is the internet connection, and not some performance issues in the web service / CRM system? By timeout I'm going to assume you mean something like ~30 seconds, in which case:
Either the internet connection is to blame and so you would see these sorts of timeouts to other websites (e.g. google), which is clearly unacceptable and so sorting the internet is your only real option.
Or the timeout is caused either by the desktop application, the web serice, or due to exessively large amounts of information being passed backwards and forwards, in which case you should either address the performance issue how you might any other bug, or look into ways of optimising the Desktop application so that less information is passed backwards and forwards.
In sort: the architecture that you currently have seems (fundamentally) fine to me, on the basis that (performance problems aside) access for the company to the CRM system should be comparable to accesss for the public to the system - as long as your customers have reasonable response times, so should the company.
Install a copy of the database on the local network. Then let the client software communicate with the local copy and let the database software do the synchronization between the local database server and the database on the webserver. It depends on which database you use, but some of them have tools to make that work. In MSSQL it is called replication.
First things first how much of the code do you really have to throw away? What language did you use for the Desktop client? Something .NET and you may be able to salvage a good chuck of the logic of the system and only need to redo the UI and some of the connections.
My thoughts are that 1 and 2 are out of the question, while 1 might be a good idea it doesn't solve the real problem. And we as engineers should try and build solutions not dependent on the client when ever possible. And 2 makes them get into something they aren't experts at and it is better to keep the hosting else where.
Also since you mention a web service is all you are really losing the UI? You can alway reuse the webservices for the web server interface.
Lastly you could look at using a framework to help provide a simple web based CRUD to start and then expand from there.
Are you sure the connection is saturated? You could be hitting all sorts of network, I/O and database problems... Unless you've already done so, use wireshark to analyze the traffic; measure the throughput and share the results with us.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm currently a developer at my first job right out of college. I work for a large company, and the trend I notice with them is that they tend to go with more expensive, closed source software about 99% of the time, while there are perfectly good open source alternatives that are available, most of which are vastly superior to their closed-source counterparts. For example, we use this absolutely awful source control software that cost a ton of money, while there are quite a few open source and/or free options that in my experience, albiet limited, are much better and offer basically the exact same functionality.
I guess my question is: How would an experienced developer approach management about using more free software?
It appears there is another question very similar to this that did not show up when I made this one: How can I convince IT that F/OSS software isn't evil?
EDIT: Just come clarification. I'm not necessarily trying to change the company's procedure, I'm looking for advice on how to approach management about the subject.
Start using it in small utilities and things which are throwaway and don't need management buyin. This can prove the worth of an open source solution and put a crack in
the door for using it in other
projects.
Present articles from trade magazines showing that other people are using the open source solution.
Go with products which have commercial support options, such as MySQL, which enterprises seem to have an easier time swallowing.
Pick your battles carefully. Wait until they are suffering. If they are happy with what they have, they will not switch, no matter how much cheaper or superior the alternative is. You need to catch them while they're trying to think of ways to save money, or while they're disgusted with the problems of the current system.
Be very careful with what you refer to as free. There is a very large corpus of products that would be perfectly valid for a student to use without paying that an enterprise would have to pay for. Also never forget Total Cost of Ownership (TCO). A lot of relatively expensive software is expensive because you get things like configuration and help support for them whereas that may not be the case for free software.
I think you are not asking the right question. To me, the challenge is to have my Big Corp to buy the BEST softwares for me, be it free softwares or not.
Paying for Windows or paying for Linux is not important (what is 100 $ for a Big Corp ?).
But having things done better is really important.
I think that your request to your boss should not be : "Hey, it's free and it's as good as XYZ, why are we using XYZ ?"
Why you boss would risk something trying the product you told when XYZ seems to be ok ?
It would be much more better to ask : "Hey, here is what I cannot do with XYZ : (your list). With my product, I would be able to do that and much more so fast than I would have a lot of spare time to test our own software !".
Small money is usually not a show stopper. Being able to work faster in order to do much more testing (or any other things that could help your boss have a better image) is definitely an excellent argument !
Best wishes,
Sylvain.
I work in a big company that has recently moved into being more enthusiastic about open source solutions. There have been a few big hurdles:
Customer won't support it - we're defense contractors. We do almost nothing without customer say-so. As the customer's opinions have changed we've been able to change our architectures and tool usage. That said, there are still scenarios were open source is unacceptable and we don't use it.
No tech support = scary - in several cases, it's been possible to make the point that open source may not have a single point of company tech support, but it does have huge communities that will support questios for free, and that there are consultants available as needed for the really hard stuff. Plus many, many releases of new versions for bug fixes. And, several competing expensive products have not been able to service tech support needs. Being able to point to specific internal examples with long. well documented, histories of support problems, has been key.
Fear of security issues - we had to develop a process for scrutinizing and controlling every peice of open source introduced. We've managed to find criteria for what we deem risky, versus what we deem relatively benign based on info-sec policy.
Fear of lawsuit - Being large, and profitable, we fear lawsuits, we're great targets. We now have a process for the legal team to scrutinize every open source license. This has proved to be a win - since the legal team now has briefings on every major version of the typical open source licenses, and they can quickly review most stuff.
Version control - fear that if those wacky developers can just download anything they like the world will self destruct. OK, well, practically speaking, the concept of "how do we know what's in a given product" - being able to show a FOSS version control process that is managed internally has been important.
It was definitely a slow process - small projects proved profitable and customers started encouraging it in proposals. That made it useful for executive management. It's helped that those that support it have been williing to put in some extra time to making the business case in terms of efficiency/cost savings, and have been willing to negotiate repeatedly with various parts of the corporate infrastructure.
Making open source work has taken the effort of IT, the info security folks, the legal team, the procurement team, and technical management. Knowing that before you talk to your manager is probably a key to success.
There's also some political savy - for a first project, don't encroach on any sacred cows - ie, those projects that may not be successful, but are high profile and owned by someone with lots of political power. Instead, choose some wacky new thing that isn't available right now and prove the cost savings in a way that is unlikely to provoke a defensive reaction.
When you try to introduce open source software to a big company (or even a small one, in many cases), the biggest counter-argument you're going to hear is "There's no tech support." Companies tend to be wary of using software that's supported by the community, because there's no guarantee (or in some cases, service agreement) that questions about the software will be answered within a reasonable time frame, or at all. In many cases, you can find a company that will provide support for the open-source package you want to use (for example, Red Hat does this for its Linux distribution, even though the contents of the distribution is mainly open source). Showing management a business entity that can support the software will often go a long way.
The other counter-argument to using open source software that I've heard the most often is "Open source software is buggy." This is a tough one; this opinion is pretty ingrained in some corporate cultures. Two possible responses are "The open-source community fixes bugs quickly" and "Since we have the source code, our engineers can fix bugs"--but that's often not what managers want to hear.
So, in essence, it depends on the company, their attitudes, and how much they trust you to make business-critical recommendations. I've used all of the arguments above with different levels of success in different companies.
Of course, in these economic times, the "free" part may go a long way. :-)
"Free software" doesn't necessarily mean your company is going to get software for free. Many successful open-source projects are also offered with licenses and services that cost real money and are geared to organizations that want or need to be assured of good support. MySQL is an example
The reason for a lot of big companies using closed software is that they can call support and the vendor will issue a hotfix, patch or cumulative update
Changing a large company's habits are often like turning an Oil tanker around... it takes a long time and uses a lot of energy.
If the company were in the process of evaluating the purchase of new software for a specific task, Then I would make sure to write a concise opinion memo about why my choice is better.
If the software is something I would use personally and not a server product that multiple developers are forced to use, then I would just ask my manager to use it.
If the software is in place, does the job (even if I don't like the way it does it), i'd learn as much as I can about it to give it as much chance of work for me, or at least make my life easier. If it still sucks really bad, I probably wouldn't try to change it until it was time for the company to pay for an upgrade.
If the software works but is just annoying... I'd do as above, learning all there is to know about it just to make my life easier and then deal with it.
You're probably right that the system you'd recommend is better than the one currently in place. But like some other posters said, choose your battles, especially when this is your first job out in the real world. You may become expendable quickly.
It's not really so much a matter of what's better, even if your way IS better, it's a matter of the culture and the way things are done and the cost of switching. Even if, hypothetically, their system can be magically transported to your OSS system, with no loss of data, dates, records, or anything, you're still going to have people who say "I liked the old way better."
Remember: Experience is what you get when you don't get what you want. I know it may sound glamorous to be "the new guy who recommended a great new versioning system that everybody loved", but you also could just as easily become "that hotshot who insisted on a new versioning system that everybody hated." It's a much smarter career move to just play by the rules at least for a little while until you have some clout and can make some recommendations. In the meantime you may even learn why the old system is preferred, or learn to like it more the more you use it.
I know what you mean. It took us years to convince our managers that everything would be okay if we moved away from using Interbase (a commercial Relational DB) to it's opensource counterpart Firebird. Mostly it was fear of no support that blocked the move. I think the factors which changed their mind were:
tests showing better performance
that there are companies that provide and charge for supporting the OS alternative
constant pushing of the argument by passionate developers
I think cost savings would have played a part if our company were paying for the site licenses but in fact our customers were.
I look at this question like this. I work with the .NET framework. I could ask my employer to migrate to PHP. This is a disadvantage to me, as well as my company, for many reasons. Let's start with the obvious.
1.) I know PHP, but can do much more, and a lot faster, with .NET.
2.) Paying for a service, usually ensures a better experience. The Visual Studio IDE is second to NONE when developing an application.
3.) I can develop an application much faster in VS than hard-coding PHP.
4.) This is the most important one. If I work with a big company, I want my programmers to develop my app faster, and I expect it to run faster. PHP (an example Open Source language) is fast, and reliable, but if I can spend the money, I'll deploy ASP.NET.
Basically, big business, or even small business, wants to spend their money, as long as it's for a good reason. Your best bet is to say, 'Hey, if you want to deploy ASP.NET (or whatever), send me for some training. Then I'll be able to develop OUR application to my best ability'.
not to sound totally cynical, but:
an experienced developer probably would not approach management about something like this, unless he/she was already an expert with the open source package. Companies like to have a phone number to call and someone to blame when things don't work. Free open source packages do not provide this kind of 'accountability' (yes we know it's a joke, but management doesn't)
it is unlikely that management is going to listen to someone fresh out of college about any major purchasing or technology decision. You have to learn the business and earn everyone's respect first. [sorry!]
Same problem everywhere. Once an organization gets beyond a certain size (e.g., the Dunbar number) it starts to show a certain woodenheaded quality that will confound you. Lots of history, people, agendas that you aren't aware of. And getting everyone to agree on your solution is difficult.
Best to start locally. See if you can persuade your manager or PM to use SVN or CVS or GIT locally for a project and then get it to diffuse.
But that situation is true where I work as well. I use SVN locally for myself, but a commercial product for integrating with others.
Companies will use whatever will ultimately make them the most money. That means whatever software will make their employees more productive. If there is a particular piece of open source software you think they should use then when the time comes to purchase the software to do job X then as long as you can prove it will make the employees more productive and they are able to get reliable support just a phone call away as with commercial software then they will use it.
Big companies need to hire support staff for stuff like that. When they purchase software from a company, they are guaranteed support with the contract. Open source projects can die off a lot easier, whereas a large software vendor can be held responsible for much greater periods of time.
Every company has a culture, and fighting the culture can be something of an uphill battle. But if you're willing to try:
you'll likely have more luck getting BSD and BSD-like projects approved (MIT license, Apache, Boost, etc.); and it doesn't matter if most of the arguments against GPL and LGPL are mainly FUD
you should refer to the projects as "royalty-free"
you should make sure things are approved by somebody that can approve them (your direct manager) because putting the company in a bind -- especially when you're new -- (even if the "bind" is only in their head) is not conducive to long-term employment
you can probably go a long way by simply asking what the procedure is to choose a library or tool
From a configuration management perspective, having developers add free software stuff willy nilly whenever they feel like is a serious PITA to manage.
I've worked at companies where you were allowed to do it whenever you wanted and others where you could never do it.
There's definitely a balance to be found but if you're in a larger company with multiple projects, you do have to keep in mind that each time you add a new 'tool' it complicates the build process.
I work for an R&D company in the energy business. We've developed some successful products, but now seem to be spending all our time fixing issues relating to those products. We don't seem to have any time to work on developing new products.
Does anyone have any good ideas on how to both handle problems arising with the existing products but still have the time and resources to develop new products as well?
TY,
Fred
If you have a successful product, and are staffed to handle either development OR maintenance then the solution seems to point at hiring. Perhaps bring in some new blood/fresh grads to "grow" them into the more mission critical side of the R&D company? Thus the new blood would gain experience on existing products (with guidance from the more senior staff) and grow into great devs for the R&D side!
I would suggest the best method is to have a group/person dedicated to new development. They should be available for questions, but... The only problem would probably be some jealousy, but a good manager should be able to figure out how to handle that.
Why do you need all manpower for the existing products?
Was the staff reduced after completion? - Hire new guys
Are the products -ahem- very defective? - Fix your process, and fix your bugs first (sorry)
Did you develop many products, with more and more time going into maintenance, and now no development is left? - Cancel support for old products, hire new guys, or make clients pay dearly for maintenance (i.e. let them cancel support)
Are you frantically adding new features to the products? - sorry, you are doing new stuff. New features need to be balanced
Does the comany require more "R"? Many R&D companies end up M&F - Maintenance and Features. Are the other guys happy? If so, maybe you need to look for a position better suited to you.
I am not sure about your position - are you doing inhouse development, or is your company selling the software? In any case, there must be some room for new development, to remain healthy. Make clear to your management that, if the job consists purely of maintenance, the best people will leave.
Don't expect to much, though - especially if you are on inhouse development. It is estimated that 80% of all positions are maintenance (I wish I could find a reference).
Have management come up with a list of fixes that need to be done.
Engineering assigns an estimate of hours for each fix.
Decide which fixes get in and which get pushed out. Some may be "fixed" in documentation (work-around, known issues, etc.)
If you can afford to, hire someone to handle support and maintenance to free up resources for research.
If you cannot, you need to reduce your marginal cost per customer. Keep track of all manual labor and support requests and prioritize new features that will reduce these to a minimum.
"time-management"
try Getting Things Done by David Allen
Be very careful of this. I've seen a few companies do this where the support of the active products (the ones making money) became secondary. The "Support" function is minimized because support income counts against you in an IPO situation.
The next thing you know, your company isn't making any money, the support staff that are trying to make a little are treated like crap (and fired when the money runs out), and the "New product" team isn't required to release anything (no customer demand) so they succumb to feature-creep and multi-year long release dates.
This leads to a refocus where 2/3 of the companies staff is cut and the remainder all work on support and a token few on the "Next generation" that's always around the corner--which works until the bank calls in the loan for the money you borrowed to hire the marketing people before you even had a "new" product to market.
It doesn't have to happen this way--just be careful.