关于 Opera 是怎么死掉的，大家可以读读这篇 Opera 一个未署名(转载)# Hardware - 计算机硬件
c*f
1 楼
【 以下文字转载自 PDA 讨论区 】
发信人: coolwulf (coolwulf), 信区: PDA
标 题: 关于 Opera 是怎么死掉的，大家可以读读这篇 Opera 一个未署名员工的文章
发信站: BBS 未名空间站 (Mon Feb 22 15:15:51 2016, 美东)
by Anonymous Coward on Tuesday June 24, 2014 @12:53AM (#47303521)
(Disclaimer: I'm an ex-Opera employee; pretty much all of what's below has
been said by others before or can easily be inferred from it.)
Opera ceased selling a web browser to consumer years ago. Opera, having been
ad-free for around nine years, with the exception of a couple of quarters
in the black in 2009/2010, has been pretty profitable; this is well before
any work started on anything based on WebKit or Chromium. Since 2010, Opera
has basically been posting record profits quarter after quarter. You can
find all this in the quarterly reports (as a publicly traded company, this
is all public knowledge). The move to the Chromium Content API and WebKit
and later Blink beneath it was not driven out of lack of resources to
develop Presto; it was driven out of an unwillingness to do so.
In terms of revenue, Google, as the default search engine, have been paying
handsomely, primarily because they wanted to break into markets where Opera
had at the time significant marketshare, especially around the CIS. However,
given Chrome's rise in those markets since, I would be very nervous about
being dependent upon Google for revenue. That said, last I looked, search
affiliation deals were only about 50% of total revenue (for comparison, in
2012, 90% of Mozilla's revenue came from Google!). Considering all the
various acquisitions of advertising networks and related companies, this has
undoubtedly fallen (they will likely soon be the biggest source of revenue
for the company!).
However, it the other side of the business that drove the change to the
company: the B2B side, selling browsers to OEMs for mobile devices and TVs
and set-top boxes, etc. We've gone from a dozen or two platforms on mobile a
decade ago down to half a dozen now; these phones mostly run systems where
high quality web browsers are included by default (hey, look, they don't
just support WAP!).
"WebKit" (in about a million different forks!) has been what all the cool
kids (say, iOS, Android) have been using, and hence many companies not using
OSes including a web browser, whom typically Opera would have got a larger
proportion of the business (we're talking > 50% of the market), essentially
decided they were going to get a WebKit browser and turning either of
consultancy companies around WebKit or building their own teams in-house.
Along with this, iOS and Android's rise has led to a monoculture around
mobile, with many mobile sites practically requiring WebKit, so mobile badly
suffered (this led both the IE and Opera to seriously consider supporting
various things with explicit WebKit prefixes, as the market demanded we
support websites, and websites were unwilling to support anything that wasn'
t WebKit; both IE and Opera have decently sized outreach teams that tried to
get many notable websites to change and utterly failed).
B2B customers either wanting WebKit explicitly or implicitly (i.e.,
requiring support for sites that very much only supported, and were only
willing to support, WebKit) drove the move more than anything else, as far
as I could see. The change of management at the top, going from people who
cared about the web (go look at Opera's vision statement, it's great!) to
people who cared more about quarterly profits, certainly didn't help either.
(If all you care about is quarterly profits, why employ 100 people to
develop a browser engine B2B customers don't want?)
This was all not helped by Presto falling further and further behind the
competition; a number of engineers were let go during the black quarters in
'09/'10, the "Core" department (i.e., that which worked on Presto) let go
about as many as any other at the time. Opera 10.00 looked diabolical when
it came out (Sept '09) in terms of standards support, but this was mainly
systematic of poor development methodology rather than Presto being that far
behind (in reality, the Core department had stable releases of Presto that
already included virtually everything in 10.50 (March '10) by the time it
shipped, that Desktop wasn't shipping it is a failing of process rather than
technical incompetence). The real hurt was that when the company started
posting profits again, Core never began hiring again (only a very few hires
were made before everyone was let go or moved to other departments with the
end of Presto), and certainly not enough to keep up with the rate that MS,
Mozilla, Google, and Apple were hiring people to work on their respective
browser engines; there simply weren't the resources to keep up, yet alone
catch up the slight gap we had in 2010. As a result, Presto ended up fairing
worse and worse to what more and more of our customers wanted. By 2011 it
was inevitable Presto was dead (I know others who'd put that date back as
far as 2009!); the gap had become too large to really be viable to catch up,
even if the resources were forthcoming. That we were heading towards its
inevitable death had been obvious for years; nothing was done about it.
The fact the Presto carried some technical debts didn't help; much of its
current state goes back to the early 2000s. Many within the team then
working on Presto held a strong view that as long as the browser followed
the standards we were sufficing, and the blame for any web compatibility
issues lay with the websites. Of course, this was completely untenable as IE
reached its monumental peak of >95% marketshare. Things started to be added
, reluctantly, to match IE, while avoiding changing others. Many of these
would come back to bite years later as CSS truly became widespread as a
layout tool. A good example of this is rounding of numbers in CSS; Presto
always performed integer arithmetic, everyone else used floats. This
probably was a reasonable implementation choice when it was made over a
decade ago; mobile devices lacked FPUs, hence avoiding floating point led to
notable performance gains, yet as the market progressed, it became clear
that it was hurting Opera (causing all kinds of bizarre layout issues) and
mobile devices gained FPUs. Still, nothing was done about it, as $
shinyNewFeature is more important for marketing purposes than having to
change types that are relatively pervasive across the layout engine.
There was also plenty of wasted engineering work until about a few years ago
. The state of testing was... diabolical, at best. This was really driven by
a view of testing as nothing but a cost (and there are plenty of terrible
releases of Opera!) and something that can be avoided by proper development
process so bugs aren't introduced in the first place (which of course is
nonsense). Regressions were aplenty, typically caught months after the code
was changed (many were only found once the Presto release found its way into
a public Desktop build), by which time nobody knew quite what was going on.
Bugs would often languish for years, eventually get fixed, just to be
reintroduced a year down the line. Thankfully, that was eventually fixed,
but really far, far too late. People only started truly caring about
automated test results in about 2009, when suddenly it became part of the
process, at which time the automated test system was basically formed of
random old scavenged workstations. You can guess how well that system stood
up to the sudden load; it became the bottleneck of merging, well, anything.
Yet there was apparently no budget to buy new hardware for it, so instead
man-years were wasted waiting on the bottleneck and trying to speed the
bottleneck up (spending six man-months for a 25% performance increase is so
much more expensive than just doubling the amount of hardware, and as
designed the system would've scaled horizontally massively beyond where was
and ever did).
Ultimately, Presto died not because of a lack of money, but because the
leadership was weak (it was obvious Presto was going to die if investment
didn't increase in 2009, and yet nothing was done; had the investment been
made in Presto we might not be talking here today, had the decision to move
to WebKit been made in 2010 the two could've been developed in parallel for
a while until the new product was in a far better state than the panicked,
rushed Opera 14/15 was when it shipped). What the Core department achieved
with the staffing levels it had was nothing short of astonishing, and there
are countless examples of really great people in the department who helped
pull that off, yet ultimately, it was all for nought.
发信人: coolwulf (coolwulf), 信区: PDA
标 题: 关于 Opera 是怎么死掉的，大家可以读读这篇 Opera 一个未署名员工的文章
发信站: BBS 未名空间站 (Mon Feb 22 15:15:51 2016, 美东)
by Anonymous Coward on Tuesday June 24, 2014 @12:53AM (#47303521)
(Disclaimer: I'm an ex-Opera employee; pretty much all of what's below has
been said by others before or can easily be inferred from it.)
Opera ceased selling a web browser to consumer years ago. Opera, having been
ad-free for around nine years, with the exception of a couple of quarters
in the black in 2009/2010, has been pretty profitable; this is well before
any work started on anything based on WebKit or Chromium. Since 2010, Opera
has basically been posting record profits quarter after quarter. You can
find all this in the quarterly reports (as a publicly traded company, this
is all public knowledge). The move to the Chromium Content API and WebKit
and later Blink beneath it was not driven out of lack of resources to
develop Presto; it was driven out of an unwillingness to do so.
In terms of revenue, Google, as the default search engine, have been paying
handsomely, primarily because they wanted to break into markets where Opera
had at the time significant marketshare, especially around the CIS. However,
given Chrome's rise in those markets since, I would be very nervous about
being dependent upon Google for revenue. That said, last I looked, search
affiliation deals were only about 50% of total revenue (for comparison, in
2012, 90% of Mozilla's revenue came from Google!). Considering all the
various acquisitions of advertising networks and related companies, this has
undoubtedly fallen (they will likely soon be the biggest source of revenue
for the company!).
However, it the other side of the business that drove the change to the
company: the B2B side, selling browsers to OEMs for mobile devices and TVs
and set-top boxes, etc. We've gone from a dozen or two platforms on mobile a
decade ago down to half a dozen now; these phones mostly run systems where
high quality web browsers are included by default (hey, look, they don't
just support WAP!).
"WebKit" (in about a million different forks!) has been what all the cool
kids (say, iOS, Android) have been using, and hence many companies not using
OSes including a web browser, whom typically Opera would have got a larger
proportion of the business (we're talking > 50% of the market), essentially
decided they were going to get a WebKit browser and turning either of
consultancy companies around WebKit or building their own teams in-house.
Along with this, iOS and Android's rise has led to a monoculture around
mobile, with many mobile sites practically requiring WebKit, so mobile badly
suffered (this led both the IE and Opera to seriously consider supporting
various things with explicit WebKit prefixes, as the market demanded we
support websites, and websites were unwilling to support anything that wasn'
t WebKit; both IE and Opera have decently sized outreach teams that tried to
get many notable websites to change and utterly failed).
B2B customers either wanting WebKit explicitly or implicitly (i.e.,
requiring support for sites that very much only supported, and were only
willing to support, WebKit) drove the move more than anything else, as far
as I could see. The change of management at the top, going from people who
cared about the web (go look at Opera's vision statement, it's great!) to
people who cared more about quarterly profits, certainly didn't help either.
(If all you care about is quarterly profits, why employ 100 people to
develop a browser engine B2B customers don't want?)
This was all not helped by Presto falling further and further behind the
competition; a number of engineers were let go during the black quarters in
'09/'10, the "Core" department (i.e., that which worked on Presto) let go
about as many as any other at the time. Opera 10.00 looked diabolical when
it came out (Sept '09) in terms of standards support, but this was mainly
systematic of poor development methodology rather than Presto being that far
behind (in reality, the Core department had stable releases of Presto that
already included virtually everything in 10.50 (March '10) by the time it
shipped, that Desktop wasn't shipping it is a failing of process rather than
technical incompetence). The real hurt was that when the company started
posting profits again, Core never began hiring again (only a very few hires
were made before everyone was let go or moved to other departments with the
end of Presto), and certainly not enough to keep up with the rate that MS,
Mozilla, Google, and Apple were hiring people to work on their respective
browser engines; there simply weren't the resources to keep up, yet alone
catch up the slight gap we had in 2010. As a result, Presto ended up fairing
worse and worse to what more and more of our customers wanted. By 2011 it
was inevitable Presto was dead (I know others who'd put that date back as
far as 2009!); the gap had become too large to really be viable to catch up,
even if the resources were forthcoming. That we were heading towards its
inevitable death had been obvious for years; nothing was done about it.
The fact the Presto carried some technical debts didn't help; much of its
current state goes back to the early 2000s. Many within the team then
working on Presto held a strong view that as long as the browser followed
the standards we were sufficing, and the blame for any web compatibility
issues lay with the websites. Of course, this was completely untenable as IE
reached its monumental peak of >95% marketshare. Things started to be added
, reluctantly, to match IE, while avoiding changing others. Many of these
would come back to bite years later as CSS truly became widespread as a
layout tool. A good example of this is rounding of numbers in CSS; Presto
always performed integer arithmetic, everyone else used floats. This
probably was a reasonable implementation choice when it was made over a
decade ago; mobile devices lacked FPUs, hence avoiding floating point led to
notable performance gains, yet as the market progressed, it became clear
that it was hurting Opera (causing all kinds of bizarre layout issues) and
mobile devices gained FPUs. Still, nothing was done about it, as $
shinyNewFeature is more important for marketing purposes than having to
change types that are relatively pervasive across the layout engine.
There was also plenty of wasted engineering work until about a few years ago
. The state of testing was... diabolical, at best. This was really driven by
a view of testing as nothing but a cost (and there are plenty of terrible
releases of Opera!) and something that can be avoided by proper development
process so bugs aren't introduced in the first place (which of course is
nonsense). Regressions were aplenty, typically caught months after the code
was changed (many were only found once the Presto release found its way into
a public Desktop build), by which time nobody knew quite what was going on.
Bugs would often languish for years, eventually get fixed, just to be
reintroduced a year down the line. Thankfully, that was eventually fixed,
but really far, far too late. People only started truly caring about
automated test results in about 2009, when suddenly it became part of the
process, at which time the automated test system was basically formed of
random old scavenged workstations. You can guess how well that system stood
up to the sudden load; it became the bottleneck of merging, well, anything.
Yet there was apparently no budget to buy new hardware for it, so instead
man-years were wasted waiting on the bottleneck and trying to speed the
bottleneck up (spending six man-months for a 25% performance increase is so
much more expensive than just doubling the amount of hardware, and as
designed the system would've scaled horizontally massively beyond where was
and ever did).
Ultimately, Presto died not because of a lack of money, but because the
leadership was weak (it was obvious Presto was going to die if investment
didn't increase in 2009, and yet nothing was done; had the investment been
made in Presto we might not be talking here today, had the decision to move
to WebKit been made in 2010 the two could've been developed in parallel for
a while until the new product was in a far better state than the panicked,
rushed Opera 14/15 was when it shipped). What the Core department achieved
with the staffing levels it had was nothing short of astonishing, and there
are countless examples of really great people in the department who helped
pull that off, yet ultimately, it was all for nought.