Fifteen years ago today, March 29, 1999, I showed up at Sun’s MPK29
building for my first day of work as a student intern. I was off-cycle from
the normal summer interns, since I wasn’t enrolled Spring semester but was
going to finish my last two credits (English & Math) during the Summer
Session at Berkeley. A friend from school convinced his manager at Sun to
give me a chance, and after interviewing me, they offered to bring me on
board for 3 months full-time, then dropping down to half-time when classes
started.
I joined the Release Engineering team as a tools developer and backup RE
in what was then the Power Client Desktop Software organization
(to differentiate it from the Thin Client group) in the Workstation Products
Group of Sun’s hardware arm. The organization delivered the X Window System, OpenWindows, and CDE into Solaris,
and was in the midst of two big projects for the Solaris 7 8/99 & 11/99
releases: a project called “SolarEZ” to make the CDE desktop more usable
and to add support for syncing CDE calendar & mail apps with Palm Pilot PDAs;
and the project to merge the features from X11R6.1 through X11R6.4
(including Xinerama, Display Power Management, Xprint, and LBX) into
Sun’s proprietary X11 fork, which was still based on the X11R6.0 release.
I started out with some simple bug fixes to learn the various build
systems, before starting to try to write the scripts they wanted to
simplify the builds. My first bug was to find out why every time they
did a full build of Sun’s X gate they printed a copy of the specs.
(To save trees, they’d implemented a temporary workaround of setting
the default printer queue on the build machines to one not connected to
a printer, but then they had to go delete all the queued jobs every
few days to free disk space.) After a couple days of digging, and
learning far too much about Imake for my own good, I found the cause
was a merge error in the Imake configuration specs. The TroffCmd
setting for how to convert troff documents to PostScript had been
resynced to the upstream setting of psroff, but the flags were still
the ones for Sun’s troff. These flags to Sun’s troff generated a
PostScript file on disk, while they made psroff send the PostScript to
the printer - switching TroffCmd back to Solaris troff solved the
issue, so I filed Sun bug 4227466 and made my first commit to the
Solaris X11 code base.
Six months later, at the end of my internship, diploma in hand, Sun offered
to convert my position to a regular full-time employee, and I signed on.
(This is why I always get my anniversary recognition in September, since they
don’t count the internship.) Six months after that, the X11R6.4 project
was finishing up and several of the X11 engineers decided to move on, making
an opening for me to switch to the X11 engineering team as a developer.
Like many junior developers joining new teams, I started out doing a lot of
bug fixes, and some RFE’s, such as integrating Xvfb & Xnest into Solaris 9.
A couple years in, Sun’s attempts to reach agreement amongst all of the CDE
co-owners to open source CDE had failed, resulting only in the
not-really-open-source release of OpenMotif, so Sun chose to move on once
again, to the GNOME Desktop.
This required us to provide a lot of infrastructure in the X server and
libraries that GNOME clients needed, and I got to take on some more
challenging projects such as trying to port the Render extension from
XFree86 to Xsun, assisting on the STSF font rendering project, adding wheel mouse support to Xsun,
and working to ensure Xsun had the underlying support needed by GNOME’s
accessibility projects. Unfortunately, the results of some of those
projects were not that good, but we learned a lot about how hard it was to
retrofit Xsun with the newly reinvigorated X11 development work and how
maintaining our own fork of all the shared code was simply slowing us down.
Then one fateful day in 2004, our manager was on vacation, so I got a call
from the director of the Solaris x86 platform team, who had been meeting with
video card vendors to decide what graphics to include in Sun’s upcoming AMD64
workstations. The one consistent answer they’d gotten was that the time and
cost to produce Solaris drivers went up and the feature set went down if they
had to port to Xsun as well, instead of being able to reuse the XFree86 driver
code they were already shipping for Linux. He asked what it would take to
ship XFree86 on Solaris instead, and we discussed the options, then I talked
with the other X engineers, and soon I was the lead of a project to replace
the Solaris X server.
This was right at the time XFree86 was starting to come apart while the
old X.Org industry consortium was trying to move X11 to an open development
model, resulting in the formation of the X.Org Foundation. We chose to just
go straight to Xorg, not XFree86, and not to fork as we’d done with
Xsun, but instead to just apply any necessary changes as patches, and try to
limit those to not changing core areas, so it was easier to keep up with new
releases.
Thus, right at the end of the Solaris 10 development cycle we integrated the
Xorg 6.8 X server for x86 platforms, and even made it the default for that
release. We had no SPARC drivers ported yet, just all the upstream x86 drivers,
so only provided Xsun in the SPARC release. The SPARC port, along with a
64-bit build for x64 systems, came in later Solaris 10 update releases.
This worked out much better than our attempts to retrofit Xsun ever did.
Along with the Solaris 10 release, Sun announced that Solaris was going to
be open sourced, and eventually as much of the OS source as we could release
would be. But for the Solaris 10 release we only had time to add the Xorg
server and the few libraries we needed for the new extensions. Most of the
libraries and clients were still using the code from Sun’s old X11R6 fork,
and we needed to figure out which changes we could publish and/or contribute
back upstream. We weren’t ready to do this yet on the opening day of
OpenSolaris.org, but I put together a plan for us to do so
going forward, combing the tasks of migrating from our fork to a patched
upstream code base, and the work of excising proprietary bits so it could
be released as fully open source.
Due to my work with the X.Org open source community, my participation in the
existing Solaris communities on Usenet and Yahoo Groups, and interest in X
from the initial OpenSolaris participants, I was pulled into the larger
OpenSolaris effort, culminating in serving 2 years on the OpenSolaris Governing
Board. When the OpenSolaris distro effort (“Project Indiana”) kicked off, I
got involved in it to figure out how to integrate the X11 packages to it. Between
driving the source tree changes and the distro integration work for X, I became
the Tech Lead for the Solaris X Window System for the Solaris 11 release.
Of course, the best laid plans are always beset by changes in the surrounding
world, and these were no different. While we finished the migration to a
pure open-source X code base in November 2009, it was shortly followed
by the closing of Oracle’s acquisition of Sun, which eventually led to the
shutdown of the OpenSolaris project. Since the X11 code is still open source
and mostly external sources, it is still published on solaris-x11.java.net, alongside other open source code included in Solaris. So when Solaris 11
was released in November 2011, while the core OS code was closed again, it
included the open source X11 code with the culmination of our efforts.
Solaris 11 also included a few bug fixes I’d found via experimenting with theParfait static analysis tool created by Sun Labs. Since shortly
after starting in the X11 group, I’d been handling the security bugs in X.
Having tools to help find those seemed like a good idea, and that was
reinforced when we used Coverity to find a privilege escalation bug in Xorg. When the Sun Labs team came to demo parfait to us, I decided to
try it out, and found and fixed a number of bugs in X with it (though not in
security sensitive areas, just places that could cause memory leaks or
crashes in code not running with raised privileges).
After the Oracle acquisition, part of adopting Oracle’s security assurance
policies was using static analysis on our code base. With my
experience in using static analyzers on X, I helped create the overall
Solaris plan for using static analysis tools on our entire code base.
This plan was accepted and I was asked to take on the role of leading our
security assurance efforts across Solaris.
Another part of integrating Sun into Oracle was migrating all the bugs from
Sun’s bug database into Oracle’s, so we could have a unified system, allowing
our Engineered Systems teams to work together more productively, tracking bugs
from the hardware through the OS up to the database & application level in a
single system. Valerie Fenwick & Scott Rotondo had managed the Solaris bug
tracking for years, and I’d worked with them, representing both the X11 and
larger Desktop software teams. When Scott decided to move to the Oracle
Database Security team, Valerie asked me to replace him, just as the effort
to migrate the bugs was beginning. That turned into 2 years of planning,
mapping, updating tools and processes, coordinating changes across the
organization, traveling to multiple sites to train our engineers on the
Oracle tools, and lots of communication to prepare our teams for the changes.
As we looked to the finish line of that work, planning was beginning for the
Solaris 12 release. All of the above experiences led to me being named as the
Technical Lead for the Solaris 12 release as a whole, covering the entire OS,
coordinating and working with the tech leads for the individual consolidations.
We’re two years into that now, and while I can’t really say much more yet thanthe official roadmap, I think we’ve got some solid plans in place
for the OS.
So here it is now 15 years after starting at Sun, 14 after joining the X11
team. I still do a little work on X in my spare time (especially around the
area of X security bugs), and officially am still in the X11 group, but most
of my day is spent on the rest of Solaris now, between planning Solaris 12,
managing our bug tracking, and ensuring our software is secure.
In those 15 years, I’ve learned a lot, accomplished a bit, and made a lot of
friends. I’ve also:
- filed 2572 bugs & enhancement requests in the Sun/Oracle bug database, and fixed or closed 2155, assuming I got the bug queries correct.
- worked under 3 CEO’s (Scott, Jonathan, Larry), and 4 managers, but more VP’s and Directors than I can count thanks to Sun’s love of regular reorgs.
- been part of the Workstation Products Group, the Webtop Applications group, the Software Globalization group, the User Experience Engineering group, the x64 Platform group, the Solaris Open Source group, and a few I’ve forgotten, again thanks to Sun’s love of regular reorgs.
- been seen by my co-workers in a suit exactly 4 times (my initial job interview, and funerals for 3 colleagues we’ve lost over the years).
Where will I be in 15 more years? Hard to guess, but I bet it involves making
sure everything is ready for Y2038, so I can retire in peace when
that arrives.
For now, I offer my heartfelt thanks to everyone whose help made the last
15 years possible - none of it was done alone, and I couldn't have got here
without a lot of you.
![image[7][2][2][2]](http://soacommunity.files.wordpress.com/2013/04/image7222.png?w=20&h=20&h=20 "image[7][2][2][2]")
![clip_image002[8][4][2][2][2]](http://soacommunity.files.wordpress.com/2013/04/clip_image00284222.jpg?w=26&h=23&h=23 "clip_image002[8][4][2][2][2]")
Oracle’s
BPM offering is one of the market leaders, and Oracle BPM Suite 11g is
the latest generation of Oracle’s portfolio of business process
management (BPM) technologies, bringing a number of the company’s BPM
products together as an integrated suite. Oracle has done a good job of
the integration, and can now boast one of the most complete BPM
offerings in the marketplace. Other notable elements to the suite
include the provision of a common runtime platform (which acts as an
execution environment for BPMN and BPEL models, as well as business
rules) and the introduction of Process Composer, a web-based environment
intended as a tool for business analysts. In the latest release of the
suite, Oracle has added adaptive case management capabilities.
Developer
Leads, Managers and Architects - come learn about developing Web,
Mobile and beyond based Oracle applications. This virtual event provides
sessions that range from introductory to deep dive, covering Oracle’s
strategic framework for developing multi-channel enterprise applications
for the Oracle platforms. Multiple tracks cover every interest and
every level. 
