Free-market software development
Enabled by thousands of software-as-a-service providers, internal teams are evermore competing against external markets for their colleague's business.
Here's some notes after a few years in working in this environment.
The last few projects I've worked on have broadly followed the mechanics of free-market economy, where teams are allowed and encouraged to pick the best value tools for the job at hand, be they things developed and supported by internal teams or external to the company.
At The Guardian we picked AWS hosting over a nascent internally built cloud platform along with a host of supporting services (Cloudwatch, Pingdom, PagerDuty etc.) to get the project delivered efficiently.
In my current role at Financial Times we've thought hard about everything from programming language, CI, CDNs, hosting and all the other things a happy bit of software needs, some of which are internally sourced, some not.
The emphasis of these projects has been to move quickly and, costs aside, the choice to decide who is going to provide service is typically around ease of use (for the team), readiness, and self-sufficiency, rather than the being too concerned about the politics of vertical integration across the company.
The upside of this is teams, left to their own devices, and trusted to make responsible decisions will choose what is best for themselves and the business in the long-term.
Where they make a mistake or find some requirement that is better matched elsewhere they simply swap service providers, as one might do when a better laundrette opens up across the road. For example, our current project has swapped continuous integration providers three times over the last six months as our requirements evolved.
The healthiest thing about this environment is that I see teams looking out for solutions to their local problems and others graduating towards their good decisions teams rather than sticking with centrally controlled bad ones or waiting for a centrally organised thing to be found, debated, standarised, built, rolled-out etc.
It can be terrible for morale to work on a project where you've been made to stick with a bad decision of your own making, or a decision from elsewhere that was made for the benefit of another team , or simply a decision that was forced upon you. The latter often being an example of a monopoly. 
This free-market-esque model solves the problem by effectively saying, "Got a problem with something? Well go and find a measurably better solution."
As a provider of software or platforms to other teams at first it's easy to see this situation as a threat, or at least a source of disappointment or even annoyance.
Consider the scenario ...Let's say I'm leading a (hypothetical) team of DBA's in an organisation, looking after all the database needs of the company and doing a decent job of it.
Suddenly I see everyone from software giants to dozens of smaller vendors around the world producing reasonably priced hosted databases - some generic, some niche. Most have beautifully crafted APIs, helpful sales teams, seductive free-tier introductory offers, the promise of scaling to your teams needs and so on.
I see the internal teams (my ex-clientele!) shifting away from internal solutions towards these outside providers.
The planned economy of yesterday has turned in to a chaotic free-market, my once guaranteed customers are now window shoppers.
While I agree this is perhaps at first a little disconcerting, I can also see the advantage of introducing competition in to a governed environment.
For my current team it's fixed problems around skills shortages , and meant we could deliver our project without waiting on other teams around us to deliver things.
Quite a few things we've picked off the shelf, gone against the organisational norm, or written ourselves, because we thought they met our needs better. This is a testament to competition. The providers who bend over backwards to find you and win you over will gain a greater market share.
More importantly I think this approach has started encourage internal teams to behave more like service providers in order to compete. And internal teams have many advantages over external ones so should be able to compete well.
They should be better informed about the year ahead, the organisation's pain, and have unprecedented access to their colleagues thoughts (from strategic presentations by the CTO to chance conversations in the canteen) to better understand what they can do to help.
Internal systems offer a personal service, whereas external one often jettison this in the chase for growth and scale.
The nature of many SaaS systems is they are one stepped removed from all of this knowledge, providing generalised solutions to the masses. What could be more useful that sitting across the room from the person who wrote the code you are struggling with or being able influence what the next release contains to suit your needs?
So, what makes a good service?
Fundamentally if there's not a functional product that does what it says and fills a need in your market then there's not a lot of hope of success in the free-market model. 
But taking that as a given, it's fairly straightforward to spot the trends in SaaS providers and apply them to your own teams.
The landing page
The first view of your service is probably a lasting one.
Here's the landing page from Keen.io. It explains what it does in plain English. It looks pretty, engendering some trust, and provides a clear call-to-action to get started.
Remember that your audience may not just be other developers - perhaps product managers, the CTO, contractors and other folk who may need a explanation and context of what it is your team actually does.
Likewise the FT's own Origami framework (a competitor of Bootstrap, perhaps) does a great job of introducing anyone to it's purpose and goals.
Yes, this is marketing and not software development.
Many internal services are provided gratis, so no accounts needed. Conversely, with SaaS providers, the conversion of anonymous users in to free-tier subscribers is one of the key metrics. Want to try it out? Sign-up. Want to see the API docs? Sign up etc. etc.
Upon signing-up I typically get a welcome email from the founder or 'VP of Community Outreach', which is of course usually canned, but sometimes personally written. Sometimes they will follow it up with a phone call a few weeks later asking why I've stopped using it or ask if they can be any help.
Identifying your customers, treating them to a basic customer service experience will win them over, so asking them to register gives you this relationship with them in a way that simply asking people to anonymously clone a git repo doesn't.
Yes, again, this is not software development. It's forming a relationship with the people using your code.
Most places I've worked have operated a internal market - or at least had a project budget from which direct costs are taken from.
Allowing teams to project their future costs allows simple decision making around the value of the service.
Often with internal services the costs are swallowed in to departmental budgets, so things appear essentially free. Likewise the true cost of external services can be swallowed by a VC's deep pockets, so I'm not sure there's much difference.
Perhaps in charging a nominal fee (for bandwidth, cpu etc, if not for the product itself) the service owners can distinguish between the free-loaders and the potential long-term paying customers? This seems a useful distinction to make for any service.
Many services reduce the getting started to a exercise in brevity - the quicker someone can see some output the better they can understand what's going on, the quicker they will like the service and convinced to stick around.
People are impatient, and most will eagerly take a copy and paste sample as their first interaction with your service in to their terminal.
In a competitive market, projects with a 15-step README, in which steps 3 and 9 involve waiting for the IT support desk to grant a permission, and step 5 involve upgrading your operating system, are likely to lose out.
Self-service is the way to go here.
There's lots of aspects to support.
The most obvious being a point of contact - typically in person, by email, chat room, and so on.
Services need up-to-date, well written documentation in order to be understood.
This is a grab from the FT's excellent platform APIs, written with Swagger.
Some go to the extent of providing client-libraries and SDKs, the really good ones actually have nice APIs or advertise community provided libraries.
More subtly the quality of feedback you get from a service is a good measure of it's maturity. Oblique error messages and the like cause many hours of lost time and can take many months of usage to iron out of freshly built software, but it only takes a handful of wasted afternoons for teams to start looking elsewhere.
I recently spend a couple of days adding tracing to a system I was building due to several complaints about messages going AWOL.
What's impressed me about internal teams offering services in this way is the emphasis on communication. FT's Origami team offer monthly introductory workshops. The Guardian's Ophan team constantly run explainer sessions (for technical and non-technical staff) and made dashboards for display on monitors around the office.
Elsewhere, quite often something like this will drop in to my inbox promoting new features that have been built.
Communication may also just be telling people when something has gone wrong.
Here's the FT's polyfill service status page, but every useful service has some form of this. The good teams give you the confidence that outages are taken seriously by publishing their incident port mortems in public.
And there's plenty more things that I could talk about - from the name of your service (please, not 'sub-system_foo_v3'), to a published roadmap so people can plan around your future features.
Teams as services
The point isn't that every last bit of software you write needs to be spun in to a slick marketing campaign or that every project you work on needs to become a public SaaS provider in order to succeed.
As hosted service providers grow in number, get smarter about what businesses need and become more cost effective then internal teams will need to compete harder to convince people that their service is the one to go with.
But we can learn a lot from SaaS, copy what they do, and provide services tailored for our organisation's internal markets using our natural advantage of being a lot closer to the business.
 Looking back these seem trivial decisions, but back in 2011, to go against the whole organisation for the benefit of your team was quite an ordeal and the source of several arguments.
 Thinking back, at BBC News the whole platform used Maven and RPM to package and distribute the software, which was a constant source of WTF for non-Java developers.
 Depending on your political persuasion monopolies aren't inherently a bad thing, or at least some form of protectionism. But it can turn sour. I think of Tom Maslen's anguished blog post about the BBC's design-as-a-service mentality - an effective internal monopoloy. I'd argue a service isn't a service if your customers can't shop elsewhere.
 I've no particular desire to run and maintain, say, a Redis cluster 24/7 when I can click a button and pay someone $200 p/month for a service that meets my needs.
 Yes, there are plenty of businesses without well defined markets and barely functioning products that I'm sure get by OK.
Thanks to Kaelig for his thoughts and sub-editing.