The article makes a great case that Motorola is the real winner.
The buyout can't have been solely for the patents, because Motorola are losing patent battles. It's unlikely that it was just to own a phone manufacturer, because why buy a 3rd rate one at a 60% premium? So why? Because Motorola had Google by the balls and could have further fucked Android up for everyone else.
It's a shame how every discussion of a Daring Fireball article here collapses into 'Gruber is a fanboy', but it's particularly frustrating when it's an insightful article like this one. If he's half as bad as some of you make out, it should be easy to argue the points without resorting to attacking the man.
Has the documentation situation improved much in the last year? I tinkered around with it a few times and it really felt close to being great. But... aside from the 2 or 3 intro tutorials, I found the docs really lacking. I only made actual progress by reading the framework code.
You will probably still have to look at the API docs (and read some source) from time to time, but the core team is taking documentation a lot more seriously now.
Other factors like Facebook finding and removing spam accounts, users enabling privacy features, etc. seem like a much more likely cause.
I could see people getting bored / busy and not bothering to use it any more, but it's unbelievable that 1.5 million would delete their accounts in one month.
On this "Apple should buy / copy Dropbox" thing...
Dropbox is wonderful. I love it. But Apple is slowly moving away from exposing the filesystem to the user, so if they do anything, I don't think it'll look or work like Dropbox. For example, Dropbox's solution to syncing conflicting versions is to let you browse revisions on the website. I don't see Apple doing it that way.
I would foresee an SDK level feature with each app responsible for integrating and syncing its own data. This is possible now, if the app maker is willing to host a server but the overheads of running a server long term discourage it.
Who really thinks Apple is going to build it and give it away though? Sure, there'll be efficiencies in terms of code reuse and scale if Apple provide it, but it'll cost the developer somehow (and there'll probably be another storm in a teacup when they announce it. but that's another day's work.)
tl; dr's rarely do justice but I think that's a bit snipey.
The point I took from it was in the organisational culture in the team that looked after the reactor. A macho attitude celebrating exposure to radiation does not inspire confidence.
To be honest I think there were two seperate things there; the macho attitude to radiation exposure, and the mistake (understandably) made by a new team member.
The former is just a defence mechanism, probably related to them being in the forces where the alternative (expressing concern or fear) doesn't fit. But I don't think it would translate into "go on, lean out over there and you'll be top of the chart this month!!"
I'm struggling to see the jokey and macho competition described as anything more than camaraderie, certainly not an extreme or uncommon attitude. I don't think it means they are ignoring the radiation, just enjoying (rather than dwelling) on the risk associated with their chosen career.
The story conflates these two different incidents, but really they are unrelated. And if the takeaway you have is that they were blase about the risks, well, that isn't at all how I read it. Indeed, it was clear that it was taken seriously.
Steve just didn't have the same attitude and so quit, that is all :)
Perhaps I'm mistaken but "They would celebrate whoever got the highest dose of the week by making them buy the beer for the rest." seems like very good culture. The policy uses free beer to incentivize low radiation exposure.
It actually sounds like a fairly effective way to encourage everyone to pay attention.
In my (admittedly limited) experience with managed risks (hospital staff dealing with infected patients and rock climbing being the two biggies, I guess), I'm not sure that what gets interpreted as macho attitudes is a flippant dismissal of risk. I think it's a much more complex interplay including elements of having to re-assure others that even though they may be scared, the situation is under control, as well as playing the same mind game with yourself.
Arguably, the concept that ties major releases with major purchases is old and broken. It discourages companies from making major updates to software between such releases, as it will actually make it harder for them to make new revenue off the next major release. So you get point releases that are mostly minor bug fixes, and then a huge release every year or two that the maker hopes will squeeze you into opening your wallet, even if you're mostly happy with the last release.
Web apps are clearly going to break this version treadmill. Even if you're downloading a package to the desktop, modeling software more as a service - you pay for the right to use software for a period including all updates, rather than for a perpetual license that in reality will expire and need to be re-purchased as soon as the next major version hits.
Pay as you go is better for both users and developers. It means you can charge less up front, spend less on marketing (since the cost of trialing the software drops) and focus on delivering the _best_ experience to all your users rather than denying some features to existing customers in order to create a future revenue event.
That assumes a series of minor improvements equals a major release, but that isn't always the case. Sometimes something might need a year's work because it is a change to the core of the programme(and old features have to be re-added in a different way for the new core and users are never happy about losing features) but with your system that gets completely disincentivised and minor improvements get prioritised. All the incentives point to bloatware, you create an expectation of constant releases that update or add features so you have to fulfil them, but you never have long enough to change the core and get back to where you started feature wise. That or they cheat and don't meet expectations of what version changes are and instead of point releases that are "mostly minor bug fixes" you get version changes that are so and then they need a new way of marketing that "huge release every year or two".
"...the maker hopes will squeeze you into opening your wallet, even if you're mostly happy with the last release."
I don't understand, what is the problem with that? They can hope all they want, if you're happy with the last release you don't need to update in the "old fashioned" system, it's yours forever. In the "new" subscription system you could be perfectly happy with the product as it is but you are forced to keep paying for updates just to use it.
"Changing the core" isn't generally any more encouraged by either system, if it doesn't result in marketable features.
The idea of the "complete overhaul" is something engineers love to dream about, business managers hate to do and end users generally just don't care that much about. That's why they happen so seldom - and usually only if the existing package is a pile of unmaintainable crap.
The shrink-wrap model encourages chasing adding more bullet points to the outside of the new box over actually improving the day-to-day user experience. The service model encourages making your actual customers happy with their product AFTER the purchase, so they keep buying.
The whole concept of a large, up-front fee is driven by traditional mass-media marketing strategy: spend a bunch of money making something sound really great to buy, sell it for a bunch of money up front so you can get a return on your advertising spend. Don't worry about what happens after that.
"I don't understand, what is the problem with that?"
The problem with that is if there is some small feature change that would really improve the current product (say supporting an additional new file format on import) there is little reason for the maker to add it to the old release. Instead, they lump it in with the new version and hope it forces you to buy a whole new license. So a feature that might only add a small marginal cost but would make current users happy for longer doesn't get released to them.
Firstly I said nothing of "complete overhaul", core changes are for example, the internet moving to IPv6, OSes moving from 32-bit to 64-bit.
Anything that is constantly updated with anything more than bug-fixes will become "a pile of unmaintainable crap", or just obsolete if the core isn't changed. Core changes normally happen before that point though. That is if business managers' incentives aren't all wrong. An example of that fairly recently was twitteriffic for iOS, they felt it was heading towards being a pile of crap so they had to stop and go back to the core.(even though it meant unhappy current customers)
Users not caring about it unless it immediately comes with new features or at least all the old features is exactly my point! And if what the user is paying for is updates they are absolutely not going to accept losing any features(and not going to be happy with not updating since that is the whole reason that they are paying in your method). If the user owns a version and sees that the next version doesn't have features they need they'll stick with the old version until the new version has those features. In your model they have already paid for that update.
"So a feature that might only add a small marginal cost but would make current users happy"
Prices aren't just based on costs, they are usually(in the IT sector) based on how much more they "make users happy", in some cases they are almost entirely based on that, clothes, shoes and apple products being the most obvious examples. Which to repeat in another way is the problem with core updates in your system, they are high "cost" but they only prevent the programme from going to shit so they don't "make current users happy"(just prevent future unhappiness).
That's not to say that your model doesn't work in some cases, anti-virus programmes need constant updates but very seldom core changes.(although oddly enough at least for norton it's much cheaper to buy the newer version in amazon or a shop and get continued subscription that way then to update a subscription) And you mentioned GPS apps the same applies to them, no core changes needed.
Angry Birds on iOS is absolutely not a case of it though, you don't pay for new levels, new levels are free and are an example of the opposite of what you're saying happening, you pay upfront and they have continued adding levels way beyond a point where it would have been reasonable for them to make an Angry Birds 2 and putting the new levels in that. It is a special case but it is the traditional model just with a new attitude (on iOS, on android it's the ad revenue model which is different again).
Sounds great but I am never going to pay a subscription for my IDE, or my FTP program or my Twitter client. Relationships require trust and effort from both parties and it's simply not a perfect model for every piece of software.
I don't want a relationship with a company. For most apps I want to buy and own a thing as it is now.
This "old and broken" model persists because it's something that customers get instantly and can commit to knowing in advance what their full investment will be.
With Android apps (and iPhone I presume), it seems that you pay once and automatically get any available updates. I'd guess that would work reasonably well for small utilities, so long as they continue to get new customers.
That hasn't always held true for some of the major iPhone apps, at least - when there's a major version release, they sometimes require a new purchase.
Also, iPhone and Android apps have the potential for ongoing in-app purchases by users. So you buy the GPS app once for a very low price (or free) but you have to keep buying the data updates if you're using it. Or new levels for Angry Birds.
I don't mind faster releases if they're doing things we traditionally associated with minor version numbers, such as performance improvements or slightly UI tweaks.
I really hope they don't change any rendering components at the same pace, though. I already have to strike any contractual obligation to test/support Chrome in commercial web development projects, because it's a moving target and Google do release breaking changes. If Mozilla browsers go the same way, then I really will start coding for the nice, stable, standards-friendly world of IE -- and that's never a statement I thought I would write on a serious forum with a straight face!
Recently I worked on a website with a lot of forms, and decided to use HTML5 form validation to make my life easier, with a JS fallback for older browsers. It turns out that Webkit added support for HTML5 form validation, then found a problem, so they switched off the implementation without switching off the exposed API. So every JS fallback that tests for the presence of the HTML5 methods on form elements will assume that HTML5 form validation is implemented, and leave the validation up to the browser... which doesn't actually do it at all.
That means server-side validation, which of course one needs to do anyway. But it's not to hard to imagine somebody making a site during the brief window when Chrome supported HTML5 form validation, and then discovering their site broken in Chrome a few months later.
They didn't "switch it off" they merely turned off form submission blocking when the form was invalid. It's back on in chrome now because they have the error notification bubble. The constraint validition API, the error pseudo-classes and the extra attributes all work in Safari.
If the answer to "are the contents of this form valid" is always "yes", I don't really care how much of the validation API the browser supports; it's effectively going to waste.
I'm glad to hear it's turned back on; I hope the form-validation interface is as sleek and professional-looking as the one in Firefox 4.
I wonder about that. I view our (lack of) reaction as mature, not passive. People died in Greece and they burned all kinds of things. They still have a huge debt to pay back. We're taking it like grown ups and having an election.
If you have to choose between a mature reaction that keeps you in debt and an immature reaction that leads to reversing the bad decisions that have been made at the citizens' expense, I would take the latter. But most Irish seem too concerned about their precious "international reputation" to do that - I hear this refrain all the time. Many people seem more concerned with the effect of the crisis on Ireland's reputation abroad than with the impact on current and future generations. "Taking it like a grown up", as you put it, is not the highest aspiration one can have in this situation - you could simply refuse to accept the situation and create such a stink that nothing can happen in the country until some of these devastating economic decisions have been reversed. If Iceland can get away with it, Ireland can too.
My argument is that violent protests would do very little to help. We're having an election that will throw the ruling party out. The next government are campaigning on the basis that they'll get a better deal. I doubt they will succeed, but rioting on the assumption that the problems can be decided away won't make it any more likely.
One fundamental problem we have in Ireland is the way in which we elect our Dáil (parliament).
There's a 4 minute section in this video (43m45s onwards ) http://www.rte.ie/player/#v=1090239 which explains better than I can, but here goes:
In short:
1. There are multiple seats (often with a few candidates running from the same party) per constituency.
2. It doesn't take many votes to get elected (Any more than 8,000 votes got you elected in my constituency of 86,000 people).
Politicians don't compete on the differences between their parties because they're also competing against another locally running party member. Instead, they wage very local personality based campaigns. Since they only need a few thousand votes, they can and do call door-to-door to chat with everyone they can. Pothole need filling? Let your local candidates know and by god it'll be fixed immediately.
This means that the people who end up making important decisions on whether or not to take on 100s of billions of euros worth of debt are the people who came across best on a few thousand house calls.
this seem similar to the system we had in italy up to some years ago. It was changed so that the party decides who is running, and people cannot vote on the person.
The result is, of course, that people who would be ineligible because of obvious incapacity (or any other reason) still get elected when people vote for the color instead of the person, and the parliament is full of lackeys who don't dare to disagree with the leaders for fear of not being put on the safe list the next time around.
Be careful when you wish for a better system, you may end up with a worse one :)
There's a great book written by a civil servant in Ireland's foreign ministry in the 80s.
He said he had two maps on his wall, one of the eastern bloc enemy and a bigger one of his minister's constituency - a crisis (eg a pothole) in the constituency was the priority.
Ha! That doesn't surprise me at all. What's the book called?
There is an appetite to reform this stuff now, but it's hard to imagine the winners of the game when played by those rules deciding to change it dramatically.
The buyout can't have been solely for the patents, because Motorola are losing patent battles. It's unlikely that it was just to own a phone manufacturer, because why buy a 3rd rate one at a 60% premium? So why? Because Motorola had Google by the balls and could have further fucked Android up for everyone else.
It's a shame how every discussion of a Daring Fireball article here collapses into 'Gruber is a fanboy', but it's particularly frustrating when it's an insightful article like this one. If he's half as bad as some of you make out, it should be easy to argue the points without resorting to attacking the man.