What is Indiana? No one seems to know. Some people are excited. Some people are confused. Some people are scared and angry. Why?

What is Indiana? The answer is, “Exactly!”

Not clear enough? Okey, let me explain more in depth. In order to do so, we need to break down some concepts so they are clear and then bring them all together, so bear with me.

Part 1: What is Linux? It’s a kernel. But I thought it was a distribution? Er, no, “LInux distributions” are compilations of software which include the Linux kernel, GNU userland, and a bunch of other open source software in order to form a complete OS from this variety of individual peices of software. This is why Richard Stallman pushed for acceptance of the “GNU/Linux” tag, because a minimal installation of a Linux system is made up of the Linux kernel surrounded by dozens or hundreds of GNU programs. Furthermore, GNU software is highly portable and run on every platform imaginable, whether it being *BSD, HP-UX, AIX, Windows, OS X, Solaris, VAX, on and on. Linux needs GNU; GNU doesn’t need Linux.

Part 2: What is a distribution? A gathering of various pieces of software, bundled together to form a complete operating environment. Like building a vehicle, they all are diffrent and have different purposes but require the same basic things, a kernel, userland tools, a windowing environment, network utilities, music player, database, etc. Put all the bits in a bag, shake them up and out comes a different distribution catoring to a different group of people. Solaris is a distribution (which I commonly distinguish as “Solaris GA”), OS X is a distribution, Windows is a distribution, Red Hat Linux is a distribution, SuSE is a distribution, FreeBSD is a distribution. Some use similar bits in a different order (Debian & Ubuntu) others are entirely different (Windows and AIX). The various Linux distributions are great example of how hundreds of projects can all be developing independent of any distribution and yet be gather together as one.

Part 3: What is a “developer”? The Linux community has blurred many lines. One of them is the term “developer”. A “Linux Developer” and “Java Developer” are very different uses of the same word. In the Linux world sysadmins are developers, savvy end-users are developers, hobbiests are developers, anyone who understands the system reasonably well is a developer, whether they contribute code to Linux or not. How many “Linux Developers” are there? Thousands! How many are working on the Linux Kernel right now? Er, not thousands. Okey, so what is this disparity? Anyone who works within the GNU/Linux eco-system is considered a Linux developer, regardless of whether its related to Linux or not. Is a GTK developer a “Linux developer”? Yes. Does he actually develop on Linux or use it? Not necessarily. Therefore, a “Linux Developer” is any person who influences or participates in something that is part of a “Linux Distribution”. More than 95% of the “Linux Developers” aren’t working on Linux (the kernel) at all, they are working on building and improving things that are put together to for the eco-system around it.

Part 4: What is “community”? Websters definition 3 is “an interacting population of various kinds of individuals in a common location”. Individuals are… individual. Everyone has unique viewpoints, unique values, goals and ambitions. But they huddle together because they love the place in which they live, or they simply find it most complimentary to their life. If people don’t like the place or it is no longer complimentary to their life, goals, and ambitions they move. In the free software and open source world we gather around campfires, each throwing one of our sticks (talents) into the fire to help it burn brighter. Quite often because of our diverse personal interests we move periodically from one campfire to another. We may disagree or even dislike our neighbors but we still are compelled to stay in that place because for whatever personal reason we want that fire to burn brightly. Communities grow when people are welcomed, appreciated, and invited to put in their sticks. When they can’t or find it difficult, they find a new fire, a new location, a new community.

Part 5: What is order? What is control? Order and control can be used for the forces of good or evil. They can provide the framework within which you can comfortably exist and thrive without concern about those things that you are uninterested about. Those in “power” are those that we (ideally) trust to manage this framework in a way best suited to those within it, by managing that which requires it and allowing individuals to work freely otherwise. Think of an ideal government, they build the roads, provide protection and security through police and firemen, impose certain rules to ensure safety and non-confrentation (speed limits, drug enforcement, fraud protection, legal infrastructure for despute resolution), etc. What they don’t do (ideally) is control the things on the sides of those roads, they leave that land open for use by individuals. They may define what you can build or how you can build it, but only so that it doesn’t disrupt the community in an adverse way. Order is inforced by those in control, to provide a platform a trust, accountability, and sense of comfort that relieves citizens from unneeded burdens and allows them to focus on their individual needs, goals, and ambitions in the ways in which they see fit.

Part 6: What is transparency? Transparency is working without walls, allowing other interested parties to look in and see what is being done without hiding or distorting the truth. Are each of us expected to Twitter our ever move and decision in order to allow others to see it? No, but it means that when a decision you make has implications for others, good or bad, that you disclose that information into the public domain. When working within a group (community), this takes on a new element of “transparent communication”, that is, information is shared between group members openly so that all other members of the group are privy to it. When private communication occurs a sense of distrust and bitterness creeps in and the group become less and less effective. This is particularly tricky when not all members of the group communicate via the same medium. For instance, if some mebers of the group meet for drinks, discuss and decide something and then bring it back to the group there has been no transparency in decision, and simply sharing it publicly has already excluded others from the initial discision, even if they later overturn it. Transparency is about putting everyone on level ground, giving everyone a voice, and collaborating as equals across the board.

Part 7: Solaris is a distribution. OpenSolaris is a community built around the code that makes up that distribution. Understand the separation here! Within the OpenSolaris Community (place in which we live) we have various sub-communities (campfires around which we gather and contribute); while we have influence over the parts that make up Solaris, the distribution, we do not have the ability to influence the distribution itself. You can contribute to ON, our kernel and base system, or JDS, the desktop environment, but you have no control over the eco-system which constitutes Solaris GA.

Lets go into this last point a bit further. One of the greatest strengths of Solaris is its continuity and stability, it doesn’t change in any way that isn’t backward compatible with prior releases. Sun prides itself on the ability to run SunOS 4.x applications unmodified on the latest releases. You can copy an install of Oracle on Solaris 2.6 to a Solaris 10 system without skipping a beat and thats a real business advantage. In fact, install Solaris 2.6 and Solaris 10 side by side, not much has changed. The underlying technology has evolved by leaps and bounds in each new release, particularly in Solaris 10, but while the underlying technology has evolved it has been constrained by the absolute requirement of backward compatibility, standards compliance, and an eco-system (file formats, paths, interfaces, etc) that won’t rock the boat. It is our greatest strength and our greatest weakness. Times have changed, but we’ve been unwilling (if you judge it a strength) or unable (if you judge it a weakness) to capitalize on them.

To both move forward while not loosing backward compatibility a number of strange things have had to happen, compromises. Many wonder there are multiple versions of the same binary stuffed into strange locations, such as /usr/ucb (SunOS 4.x BSD compatability), /usr/ccs (C Compiler Support), /usr/xpg4 (XPG4 Standards Compliance), /usr/sfw (Sun FreeWare, this year changed to /usr/gnu), etc, all in addition to the normal locations of /usr/bin, /usr/sbin, and /sbin. To maintain the legacy, you can’t replace, only supplement. There are crufty bits that exist for no real reason that most people can gather (SAC?) but must remain. This is all compounded by the Solaris installer which doesn’t allow you to select packages individually, but rather insists on using very widely defined Meta-Clusters; and because these Meta-Clusters aren’t well understood (a secure network install didn’t install SSH at one point) most people simply install everything despite only needing a 10th of what they installed.

To keep anything from rocking the boat an elaborate (by F/OSS standards) set of processes and standards were devised and improved over time. The best example of this is the ARC Process (Architecture Review Commitee), whereby as a developer you go through a long series of hoops, paperwork, and meetings to ensure quality, compatibility, and standards compliance. While these processes have been the foundation that has provided us with such unswerving compatibility and integrity, it translates poorly into the F/OSS world of progress by iteration; by driving forward based on action rather than committee review and debate. Within the context of OpenSolaris, this traversing of the hoops can only be accomplished by using the buddy system (peer review is yet another long held part of the process) whereby an internal developer familiar with this maze sponsors you, after having signed your Contributer Agreement, to move toward the ultimate and extraordinary goal of integrating into (a “putback”, similar to a CVS commit) the mainline ON repository where it will eventually find its way into a Solaris release for that given component.

While those processes and standards have served us (customers, developers, enthusiasts, etc) well for years they are a significant barrier to code contribution. And, as discussed earlier, the vast majority of “developers” are interested in contributing to the eco-system. Will KDE ever be in Solaris 10/11? No. Will Enlightenment (BEST WM EVER!) ever be in Solaris 10/11? No. Will GNU Make ever be the default? No. Solaris installations are already bloated with things you think you need but don’t, and require you to look elsewhere for the things you want. Enter Blastwave or SunFreeWare.com, which add yet another add on location (/opt/csw, /opt/sfw, etc.)

What is Project Indiana? Ambiguity where there is none. Possibility where there is constraint. Openness where there is little or none. A fresh start, on a clean sheet, whereby we can explore the full potential of what Solaris could be, can be, and should be. Its shaking off the shackles that have bound the eco-system, ushering in a new age of contribution, innovation, and possibilities.

Does that mean we forsake our heritage? Absolutely not! As we discussed before with distributions, the same core technology developed independently can be combined together in a variety of ways. ON isn’t the problem, the way that its packaged into an eco-system and distributed is! We have the best core technology in the industry and best engineers to boot. But its like we started with a Ford Pinto, and we re-designed and re-engineered and innovated in every part of that car such that not even a Ferrari would challange it…. but it still looked like a damned Pinto! And even though there is a 800BHP engine under the hood, we still slaved to ensure that it continued to drive like a Pinto to avoid confusing Grandma when she goes for groceries. Now consider how people look at us! They want ZFS, but not Solaris. They want our engine but aren’t interested in driving a frickin’ Pinto. And so I ask you, why are we shocked that there isn’t a faster uptake?

What the hell is Indiana? What I want it to be. What you want it to be. What we want it to be. What will it look like? Whatever we want. Its taking our core technology, all that we’ve learned and created, and putting all those pieces out on the floor of the garage and saying to ourselves: What can we do with this? And then, with a genius grin, building something the likes of which no one has seen before. Oh sure, if someone is really intent on having one of souped up Pinto’s we can put all the pieces back into that configuration, they are still a hot commodity, but why in the hell would we ever allow ourselves to think that that is all we can create.

Indiana is re-invigorating the fire of innovation outside of the core technology. Tearing down convention and embracing the future head on. The walls between GNU/Linux and Solaris are paper thin, we only need to have the courage to rip that mother down. It requires faith, vision, and a burning desire to succeed. It reminds me of the old business wisdom in which the fear of firing a bad employee might have a detrimental effect on the company, and always, in hindsight, the executive wonders why they never had the courage to do it sooner.

And is this need for change a surprise to anyone? No! Everyone but everyone (especially engineers at Sun!) has at least 5 things they want changed in Solaris. And so why haven’t they? Politics, zealotry, fear… they have worn and worn and worn people into submission; they don’t care, its not worth it. And we stagnate, and a little part of us dies. Moral suffers. Complacency creeps a little further in. And where is the voice of change?

We should be ashamed of the fact that it took Ian Murdock to show us what we already knew. Just like in life and in marriages, we hit a road block and it wasn’t until an outsider pointed towards a better path that we could gather our courage and make an attempt for change. Who is to blame? All of us, engineers, executives, developers, sysadmins, customers… we all have our fair share of the blame. But the time for blame, finger pointing, and FUD is over; Ian had the audacity to push us, kicking and screaming, towards a better tomorow which new found hope and possibilities, and an eco-system that encourages contribution over convention, customization over constraint.

And if after all that your not convinced, not sure of what this thing called Indiana is, ask yourself this: What will Solaris look like in 2017. Will it look like it does today? Now look back at whats changed outside of our fabulous core technology, at the Solaris distribution, in the last 10 years. Ask yourself, in that context, is there a better way… and is that way just possibly called Indiana.