OpenSolaris is Dead

Oracle just sued Google for patent infringement on the Android system. And now OpenSolaris is dead. Here is a company with an aggressive  business strategy buying and consuming everything in its way. Now it has eaten its way into the very principles of Open Source. Here is an article regarding the OpenSolaris OS.

OpenSolaris is Dead.

via Planet OpenSolaris by Steven Stallion on 8/15/10

What follows is an email sent internally to Oracle Solaris Engineers which describes Oracle's true intentions toward the OpenSolaris project and the future of Oracle Solaris.

This concludes over four years that I (and many other external contributors) have worked on the OpenSolaris project. This is a terrible sendoff for countless hours of work - for quality software which will now ship as an Oracle product that we (the original authors) can no longer obtain on an unrestricted basis.

I can only maintain that the software we worked on was for the betterment of all, not for any one company's bottom line. This is truly a perversion of the open source spirit.

---

Solaris Engineering,

Today we are announcing a set of decisions regarding the path to
Solaris 11, and answering key pending questions on open source, open
development, software and binary licenses, and how developers and
early adopters will be able to use Solaris 11 technology before its
release in 2011.

As you all know, the term "OpenSolaris" has been used colloquially to
refer to any or all of a collection of source code, a development
model, a web site, a logo, a binary release, a source license, a
community, and many other related things. So it's taken a while to go
over each issue from an organizational and business perspective, and
align on the correct next step. Therefore, please take the time to
read all of the detail here carefully. We'll discuss our strategy
first, and then the decisions and changes to our policies and
processes that implement that strategy.

Solaris Strategy
----------------------

Solaris is the #1 Enterprise Operating System. We have the leading
share of business applications on Solaris today, including both SPARC
and x64. We have more than twice the application base of AIX and HP-
UX combined. We have a brand that stands for innovation, quality,
security, and trust, built on our 20-year investment in Solaris
operating system engineering.

From a business perspective, the purpose of our investment in Solaris
engineering is to drive our overall server business, including both
SPARC and x64, and to drive business advantages resulting from
integration of multiple components in the Oracle portfolio. This
includes combining our servers with our storage, our servers with our
switches, Oracle applications with Solaris, and the effectiveness of
the service experience resulting from these combinations. All
together, Solaris drives aggregate business measured in many billions
of dollars, with significant growth potential.

We are increasing investment in Solaris, including hiring operating
system expertise from throughout the industry, as a sign of our
commitment to these goals. Solaris is not something we outsource to
others, it is not the assembly of someone else's technology, and it is
not a sustaining-only product. We expect the top operating systems
engineers in the industry, i.e. all of you, to be creating and
delivering innovations that continue to make Solaris unique,
differentiated, and valuable to our customers, and a unique asset of
our business.

Solaris must stand alone as a best-of-breed technology for Oracle's
enterprise customers. We want all of them to think "If this has to
work, then it runs on Solaris." That's the Solaris brand. That is
where our scalability to more than a few sockets of CPU and gigabytes
of DRAM matters. That is why we reliably deliver millions of IOPS of
storage, networking, and Infiniband. That is why we have unique
properties around file and data management, security and namespace
isolation, fault management, and observability. And we also want our
customers to know that Solaris is and continues to be a source of new
ideas and new technologies-- ones that simplify their business and
optimize their applications. That's what made Solaris 10 the most
innovative operating system release ever. And that is the same focus
that will drive a new set of innovations in Solaris 11.

For Solaris to stand alone as the best-of-breed operating system in
Oracle's complete and open portfolio, it must run well on other server
hardware and execute everyone's applications, while delivering unique
optimizations for our hardware and our applications. That is the
central value proposition of Oracle's complete, open, and integrated
strategy. And these are complementary and not contradictory goals
that we will achieve through proper design and engineering.

The growth opportunity for Solaris has never been greater. As one
example, Solaris is used by about 40% of Oracle's enterprise
customers, which means we have a 60% growth opportunity in our top
customers alone. In absolute numbers, there are 130,000 Oracle
customers in North America alone who don't use our servers and storage
yet, and a global customer base of 350,000 (the prior Sun base was
~35,000). That's a huge opportunity we can go attack as a combined
company that will increase Solaris adoption and the overall Hardware
server revenue. Our success will also increase the amount of effort
ISVs exert optimizing their applications for Solaris.

We will continue to grow a vibrant developer and system administrator
community for Solaris. Delivery of binary releases, delivery of APIs
in source or binary form, delivery of open source code, delivery of
technical documentation, and engineering of upstream contributions to
common industry technologies (such as Apache, Perl, OFED, and many,
many others) will be part of that activity. But we will also make
specific decisions about why and when we do those things, following
two core principles: (1) We can't do everything. The limiting factor
is our engineering bandwidth measured in people and time. So we have
to ensure our top priority is driving delivery of the #1 Enterprise
Operating System, Solaris 11, to grow our systems business; and (2) We
want the adoption of our technology and intellectual property to
accelerate our overall goals, yet not permit competitors to derive
business advantage (or FUD) from our innovations before we do.

We are using our investment in core Solaris innovation and engineering
to drive multiple businesses, through multiple product lines. This
already includes our Solaris operating system for Enterprise, and our
ZFS Storage product line, and will soon include other Oracle
products. This strategy is all about creating more value from a set
of common software investments: it makes everything you do more
valuable and used by more people worldwide. It also means you as an
individual engineer or manager have an even greater responsibility to
understand the broader business and technical contexts in which your
engineering is deployed.

Solaris Decisions
------------------------

We will continue to use the CDDL license statement in nearly all
Solaris source code files. We will not remove the CDDL from any files
in Solaris to which it already applies, and new source code files that
are created will follow the current policy regarding applying the CDDL
(simply, that usr/src files will have the CDDL, and the very small
minority of files in usr/closed might not have it). Use of other open
licenses in non-ON consolidations (e.g. GPL in the Desktop area) will
also continue. As before, requests to change the license associated
with source code are case-by-case decisions.

We will distribute updates to approved CDDL or other open source-
licensed code following full releases of our enterprise Solaris
operating system. In this manner, new technology innovations will
show up in our releases before anywhere else. We will no longer
distribute source code for the entirety of the Solaris operating
system in real-time while it is developed, on a nightly basis.

Anyone who is consuming Solaris code using the CDDL, whether in pieces
or as a part of the OpenSolaris source distribution or a derivative
thereof, would therefore be able to consume any updates we release at
that time, under the terms of the CDDL, LGPL, or whatever license
applies.

We will have a technology partner program to permit our industry
partners full access to the in-development Solaris source code through
the Oracle Technology Network (OTN). This will include both early
access to code and binaries, as well as contributions to us where that
is appropriate. All such partnerships will be evaluated on a case-by-
case basis, but certainly our core, existing technology partnerships,
such as the one with Intel, are examples of valued participation.

We will encourage and listen to any and all license requests for
Solaris technology, either in part or in whole. All such requests
will be evaluated on a case-by-case basis, but we believe there are
many complementary areas where new partnership opportunities exist to
expand use of our IP.

We will continue active open development, including upstream
contributions, in specific areas that accelerate our overall Solaris
goals. Examples include our activities around Gnome and X11, IPS
packaging, and our work to optimize ecosystems like Apache, OpenSSL,
and Perl on Solaris.

We will deliver technical design information, in the form of
documentation, design documents, and source code descriptions, through
our OTN presence for Solaris. We will no longer post advance
technical descriptions of every single ARC case by default, indicating
what technical innovations might be present in future Solaris
releases. We can at any time make a specific decision to post advance
technical information for any project, when it serves a particular
useful need to do so.

We will have a Solaris 11 binary distribution, called Solaris 11
Express, that will have a free developer RTU license, and an optional
support plan. Solaris 11 Express will debut by the end of this
calendar year, and we will issue updates to it, leading to the full
release of Solaris 11 in 2011.

All of Oracle's efforts on binary distributions of Solaris technology
will be focused on Solaris 11. We will not release any other binary
distributions, such as nightly or bi-weekly builds of Solaris
binaries, or an OpenSolaris 2010.05 or later distribution. We will
determine a simple, cost-effective means of getting enterprise users
of prior OpenSolaris binary releases to migrate to S11 Express.

We will have a Solaris 11 Platinum Customer Program, including direct
engineering involvement and feedback, for customers using our Solaris
11 technology. We will be asking all of you to participate in this
endeavor, bringing with us the benefit of previous Sun Platinum
programs, while utilizing the much larger megaphone that is available
to us now as a combined company.

We look forward to everyone's continued work on Solaris 11. Our goal
is simply to make it the best and most important release of Solaris
ever.

-Mike Shapiro, Bill Nesheim, Chris Armes

 

test

test

Buggy software: Why do we put up with it?

This is a guest post by Michael Kassner via TechRepublic's IT Leadership blog.

During one of the breakout sessions at TechRepublic's Live 2010 Conference this past week, I was questioning why we put up with software that has bugs and vulnerabilities. To IT-security types like me, it's a concern. Eliminate bugs and you shut the door on most malware.

After that particular breakout session, Toni Bowers, Head Blogs Editor for TR, and I talked about my concerns. She suggested that I pass what I learned on to you. So, here goes. I cajoled the "software savvy" TR writers into answering the following question:

Consumers would never accept a car or other traditional goods that are flawed, yet they are willing to buy software that is. Why do you think that is?

Here are their answers. I hope you find them as interesting as I do:

Chad Perrin

The question of why software vendors produce buggy software and why consumers accept it has no simple answer. The reasons vary from incompetence plus overconfidence to being the dominant business model at the other extreme. Here are some of my thoughts:

• The dominant business model in the software industry is one that creates and relies on otherwise unnecessary complexity. That complexity both creates bugs and hides them from view. Paraphrasing C. A. R. Hoare, there are two ways to build software: Make it so simple that there are obviously no bugs, or make it so complex that there are no obvious bugs. The former is much more difficult and does not lend itself well to enticing people to upgrade to the next version.
• People are so focused on feature marketing that they do not stop to think about bugs until it is too late. After generations of this, and of the problem getting worse all the time, end users have developed a sort of Stockholm Syndrome with regard to buggy software. They believe it is normal, expected, and inescapable.
• Features and bugs act very similarly a lot of the time once software exceeds a particular level of complexity. They do things that are surprising, or at least unexpected. People grow used to this until they become inured to surprise without the surprising behavior being reduced at all — in fact, it only gets worse. "It's a feature, not a bug" starts to sound reasonable and believable.

Chip Camden

Having worked in auto parts for several years, I can tell you that very few cars roll off the assembly line without any flaws. That's why they have a thing called recalls.

Furthermore, a serious flaw in an automobile can cost someone's life. That usually isn't the case with software, and where it is the case (medical, missile guidance, aircraft navigation), then the extra expense of a higher attention to flawlessness is considered worthwhile.

Ultimately, it's market-driven. We could make software that performed to much more exacting tolerances, but it would be much more costly. The buying public is content to pay a near-zero cost for "good enough" rather than putting a dent in their wallets for "flawless." [Editor's note: you can read more from Chip Camden in TechRepublic's IT Consultant blog.]

Erik Eckel

I think the software industry is very different from most any other. Vendors must try writing software that will work on multiple platforms (Linux, Windows, Mac) and be used by a variety of users with greatly differentiated skill levels at companies working in numerous different industries. That's a pretty tall order.

Imagine trying to make a car that could be driven by a 5′4 woman or 6′5″ man that could run on gasoline, diesel, or propane; while also possessing the ability to carry up to eight people or 6,000 pounds of payload. Oh, and it must get 28 miles to the gallon and cost less than $25K and go 100,000 miles between tune-ups.

You couldn't do it!

So, I feel for software manufacturers. The Intuits, Microsofts, Apples, and Symantecs of the world have a wide constituency to satisfy. Someone's always going to be complaining.

I think the 37signals guys may have it best. In their current best-seller ReWork, they note that one of the keys to their success is saying no to customers and limiting the amount of features they include in their software programs.

I think there's a lesson there for all of us. [Editor's note: You can read more from Erik in TechRepublic's Macs in Business blog.]

Jack Wallen

The answer is very simple: Marketing. If you ask the average consumer (those who buy the bulk of computers) if they knew there was an operating system out there far superior, safer, and more reliable than the one they used AND it was free, they would react with surprise. Their first question might be "Why didn't we know about that?" The reason is because Microsoft is a HUGE company with a HUGE PR budget and the ability to shove advertising down the throats of the consumers.

To continue with your analogy:

Tesla has a roadster that is 100% electric, can go over 300 miles on a single charge, can go from 0 to 60 in 3.7 seconds — yet the majority of people don't know about it. Why? Marketing. If one Linux company could start to produce witty, well-done television commercials things would quickly change.

But think about this: Linux has done fairly well for itself without having to spend a penny on advertising (relatively speaking). Word of mouth has been a powerful alley to the Linux operating system. However, in order to raise it to a higher level, PR and marketing will have to be used. [Editor's note: You can read more by Jack Wallen in TechRepublic's Linux and Open Source blog.]

Justin James

Some thoughts that come to mind (as someone struggling with a phone heralded by others and the media as a "miracle phone," but it is plagued with problems):

• "No warranty, express or implied" is attached to every piece of software ever made and is enforceable. Consumers know that they have zero rights, so they feel happy when it works.
• "Gadget lust" blinds people to issues. People don't want to admit that they bought a piece of junk, so they just deal with the problems and tell everyone how much they love the software/device/etc.
• In corporate environments, the people who live with the bad software are often the people who do not pick it. Those who did select it sweep the problems under the rug because it makes them look bad, or they feel it's a question of "stupid users" who "just don't get it."
• Too many problems do not appear until whatever initial return period of contract cancellation period is over.
• People expect to have problems.
• People assume that the problems are their own fault ("I'm too dumb to use this right!").
• In corporate environments, many products require a lengthy and expensive integration process; there is no way to accurately judge their quality until that is done, and afterward, it is often not clear if the base product or the integration work is the root cause of problems. To make matters worse, once you dump, say, $150,000 into customizing a $200,000 package that you spent $50,000 on hardware to support, do you really want to say, "gee, it looked good when we started, but this is a dud, let's dump it"?

Overall, it's a combination of people feeling helpless on the user end of things, and the decision makers being unwilling or unable to do anything about it once a commitment is made. [Editor's note: You can read more by Justin James in TechRepublic's Programming and Development blog.]

Patrick Gray

I think there are two factors at work that would cause me to question your premise:

Perceptions of software "flaws" are often based more on market saturation than technical elegance.

Most mainstream technical products (hardware and software) seem to have a higher incidence of flaws because they have a higher user base. This is the classic "Windows is buggy versus [a more obscure OS]" argument.

I don't think Windows is inferior, it's just a mass-market product and thus gets used and abused by the highest percentage of the population. Because Mac OS X has gained traction, it's now getting hit with malware as more people use the software rather than due to some inherent flaw.

There are considerations that outweigh flawed products, mostly getting valuable features early.

I think technical elegance often becomes second fiddle to other concerns at both a corporate and personal level. Why? We want new features and are willing to put up with partially baked software. This extends to your automotive analogy as well.

I bought a new motorcycle from BMW in its first model year (ever hear the old bromide never to buy the first model year vehicle?). The bike has had four recalls, including replacing the front axle (a front axle failure at 80 mph would be bad). Despite this product having flaws, the trade-off of having an extra year's riding was worth it to me.

If we all wanted perfect and bug-free code, first and foremost, we'd probably all be running MS DOS or a text-based Linux that hadn't had any features added in a decade. [Editor's note: You can read more by Patrick Gray in TechRepublic's IT Leadership blog.]

Rick Vanover

While software quality should be the first priority in whether or not we implement something, many times IT customers have their hands tied. Simply forgoing a piece of software if all offerings will not meet their needs will not be an option.

The natural alternative is to develop something in-house, but that too, may be cost prohibitive. This is an age-old battle of having our hands tied in a way to get pushed along to new products, and history has done nothing but continually confirm this for us.

One example is the file server market, Novell NetWare is still a superior file server product to Windows NT, 2000, 2003, or 2008; yet we all know which way the market and broader supported configurations went. There is no simple answer on how we can address this, in my opinion. [Editor's note: You can read more by Rick in TechRepublic's Network Administrator blog.]

Final thoughts

It seems we the users want the latest and greatest software, even if it means accepting buggy code. Do you agree with the TR gurus? I know we all are anxious to learn your opinions, so let them fly.

Chad Perrin wanted me to mention that he has a lot more to say about this subject. Please look for his article in the IT Security blog of TechRepublic.

Excerpted from Buggy software: Why do we put up with it? ZDNet

Parent Child Relationships in VBCs - BC User Property : "Populate Child Data"

Virtual Business Components provide for a nice way of presenting data via WebServices. Each time the VBC is loaded/refreshed in the UI, the integration is triggered behind it, and resulting response appears in the UI. But what if there is a parent child relationship in the data being returned and the requirement is to present each set of the hierarchy in a separate applet ? In normal BCs, the data is pulled from the tables, and if links are provided, the child BC gets refreshed when the parent BC is changed. How can we achieve the same in VBCs ? There is a little unknown BC userproperty “Populate Child Data”, which can be used to achieve this nice effect, without scripting, or repeatedly invoking the webservice. Here is what you do.

 

·         Create the two VBCs and the two applets for them. Also created the BO and View based on the BO.

·         Both the VBCs must refer the same IO,either via the BC userpoperty “Outgoing Integration Object Name”, or the IO name gets hardcoded in the WF.

·         The IO should have two ICs, one for parent level and one for child level in response data. The external names must be correctly populated with the BC names created.

·         Link must be created between parent and child BCs. This BC has to be added in the BO.

 

Now if everything is correctly configured, compile everything and fire up the client application. Navigating to the view will bring the data correctly in the two applets, correctly maintaining the parent child relationship between them. Moving to the next record at parent level will refresh the child level data, as the link is in context.

 

Now go ahead and check out the integration logs for this integration. There is a nice tutorial here.

 

You will find that the webservice integration was actually triggered twice, once for each level of hierarchy. The same request goes out and the same response comes back, so it means double the work. Now :

 

·         Go to the child BC you created. Add a new BC userproperty :

·         In the name column, provide : “Populate Child Data”

·         In the value column, provide : “Y”

 

Compile the BC and load the view again. Data still comes as expected in the UI alright, but if you check the integration logs, you will see that the web service was invoked only once.

 

BC user property “Populate Child Data” doesn’t look documented in bookshelf or supportweb. If you are not happy with this approach, there is a scripting alternative suggested on supportweb here.

 

 

 

Nice process, but what about the engineering bits?

Nice process, but what about the engineering bits?

via http://ayende.com/Blog/Default.aspx by Ayende Rahien on 2/19/10

Software processes has always been a popular topic of discussion in our industry. Those can get quite heated, with advocates of the "stable / stale" Waterfall method pointing fingers toward "rapid / rabid" Agile methods, with the CMMI people throwing documents around and Lean people standing on the sidelines muttering about Waste.

This isn't a post about a specific software process, I'll defer that to another day. Instead, I want to focus on a flaw in the basic building blocks in many* software building processes.

They ignore the actual building the software.

That may sound ridiculous on the face of it, after all, how can a software process ignore the act of building software. But take a look at the following diagrams:

If you'll pay attention, you'll notice that those processes talk about everything except how to actually build software. They talk about people, about requirements, about managing customers, about a whole lot of things, but not about the part where you have people sitting down and writing code. In most of those, in fact, that part is usually defined as one of those:

Why is that a problem? After all, isn't there a big distinction between software engineering (we know what to do, now let us do it) and project management (getting to know what we need to do, and verifying that we did it right). Those processes deal primarily with project management and leave the engineering part to be defined in a way that fit that particular project. Surely that is better, right? In theory, it might be. But there is a big problem when you have a software process that ignore the software engineering aspects of building software.

The problem is that that in many cases, there are hidden assumptions that are going to hammer you down the road if you use a certain process with engineering practices that doesn't fit it. Take a look at the following chart, showing a team velocity over time, does this look familiar?

The term I heard used for this is Scrum Wall, but I have seen similar results in other processes as well. The best description for that is Allan Kelly's:

You hit the Scrum wall when you adopt Scrum and everything goes well, then, after a few Sprints things don't work any more - to use an English expression, they go pear shaped. You can't keep your commitments, you can't release software, your customers get annoyed and angry, it looks like Scrum is broken.

This is what happens when you adopt Scrum without technical practices such as Test Driven Development, continuous integration and refectoring. When teams adopt the Scrum process, they go faster, show progress, things look good... and then the quality becomes a problem. Now the team are fighting through quick sand.

The code quality is poor and developers are expected to continue to make progress. Maybe the Scrum Master/Project Manager reverts to past behavior and demands overtime and weekend working. Maybe the team start busting a gut to keep their commitments. Either way the team is heading for burn-out.

The major issue is in focusing so much effort and time on project management with what amounts to willful ignorance of the technical and engineering practices will inevitably leads to disaster. The process of building software is intractably linked to the engineering practices involved in building the software. Moreover, some technical practices are actively harmful in some scenarios and life savers in others.

Many Agile and post-Agile processes focus on short cycles, each of them producing something with a distinct value to the customer. That may be an iteration, a commit or a feature, where the goal is to increase the velocity over time so we can provide as much value to the customer in as short a time as possible. What those processes ignore are things like technical debt, large scale refactoring and non functional efforts. Oh, you see those things mentioned on the edge, but they aren't something that is dealt with heads on, as a core issue to consider.

There is a bit more to that, actually. The software engineering practices and the project management strategies are linked and of paramount importance when the time comes to decide how the software should actually be built. No, this is not tautology. We just need to take into account Conway's law and expand on it a bit.

Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure.

Part of the design process of a project should include design the team(s) structure, the project management strategy and the software engineering practices in order to align the end result with what is desired. Ignoring this leads to imbalance in the project, and if that imbalance is big enough, and goes on for long enough, the project is going to rip itself apart.

* Nitpicker corner: I said many, not all. Don't bother to list me software process that deals with it. I had a reason to explicitly list the processes that I did.