I'm not sure if you've all noticed, but petrol is getting more expensive. I'm in the process of driving my car until it falls apart. Which means I will continue to get OK (not great) gas mileage. My almost-daily trip from San Francisco to Menlo Park has helped me rack up close to 110,000 miles on my 6-year-old car. As you can imagine, that's a lot of petrol being used up.

Just as I was contemplating how to work extra days from home or manage to take the train without shirking my responsibilities at home, Sun announces a new shuttle: 2 daily runs between San Francisco and Menlo Park. To top it off, the pick up point is 3 blocks from my house.

So, here I am on the second-ever shuttle from San Francisco to Menlo Park. If I wrote this in a couple of weeks it would have really been live: we'll have WiFi soon. :)

Not everyone lives as close to the Sun office as I do, so I'm not sure how many people will make the journey to the shuttle pick-up point every day. Certainly today's ridership was... low. I'm torn on this point: I don't want the shuttle to be crowded, but I also don't want it to be canceled for lack of interest. I hope that others in the area discover it, and want to ride along -- especially once we get wireless.

Believe it or not, Sun isn't just spending money on a shuttle just to make me happy: Sun is committed to doing its part to help the environment. With so many employees in the Bay Area making the trip to Menlo Park every day, it makes sense for Sun to do what it can to help out. And, clearly, those of us who take the shuttle may be a bit more productive as a result.

Back to work now. This has turned out to be the most productive commute I've had for some time. And once we have WiFi I can even still listen to my usual asinine morning radio show while I do my work. The only question is when I'll be able to get my swearing and honking in for the day? Beep, beep.

Try as we might, we haven't been able to get all of the "good stuff" on opensolaris.org linked from all the right places. Sorry about that... We are trying to make it better, but in the meantime I thought I'd point out a couple of pages that might be of interest and that you might not find on your own:

• Community code contributions table (http://www.opensolaris.org/os/bug_reports/request_sponsor/): This table lists all code contributions offered to OpenSolaris, mostly through the 'request-sponsor' process/mail list (find out more about how this works on the Participation page or check with individual projects or communities about how they take contributions). This page lists the community code contributions and their status. At the time of this posting, there are 188 contributions submitted, and 102 of those have been integrated. Fantastic!
  
• Requesting ARC cases (http://www.opensolaris.org/os/community/arc/arc-faq/arc-publish-historical-checklist/): Eric Boutilier and John Plocher have published a process for requesting materials for historical ARC cases, and they've even got a ARC request tracking table so people can see the status of their requests. I know at least one person asked how they would know which ARC cases to request. I like the idea Stephen Hahn put forth to me on this topic: any time you see an ARC case referenced -- in the code, email, or other ARC case materials -- submit a request for it. Why not? If it can't be published, we'll figure that out and let everyone know. So, go for it.
  
• OpenSolaris distributions (http://www.opensolaris.org/os/about/distributions/): We've written up a page with short summaries and links for each of the 5 OpenSolaris distributions: BeleniX, marTux, NexentaOS, SchilliX, and Solaris Express Community Release.
  
• OSS bite-sized bugs (http://www.opensolaris.org/os/bug_reports/oss_bite_size/): This table has a list of small, self-contained bugs -- identified with the bug Keyword 'oss-bite-size' -- that are available for anyone to fix. The table is updated every couple of days with the latest status from the bug database. There is also a table (updated at the same frequency) with the list of oss-bite-size bugs that are no longer available at (http://www.opensolaris.org/os/bug_reports/fixed_oss_bite_size/). Hopefully these pages will help people find bugs to work on. Currently there are 163 oss-bite-size bugs available, and I'm hoping there are even more on the way...
  
• Community bugs (http://www.opensolaris.org/os/bug_reports/boo_list/): We also have a table for all bugs filed through opensolaris.org. The table is updated at least once a week and gives a more detailed status than what is visible on bugs.opensolaris.org. This list is a compilation of all bugs with the Keyword 'opensoalris' included in the bug -- which is automatically inserted into all bugs filed through the website.
  
• Becoming a sponsor (http://www.opensolaris.org/os/community/onnv/crt/becoming-a-sponsor/): This page provides details about how someone becomes a sponsor for community code contributions. Because the OpenSolaris source tree and other development tools are not yet available on opensolaris.org, only Sun engineers can be a sponsor at this point. As soon as we have the necessary tools and infrastructure moved to opensolaris.org, the sponsor requirements will be open beyond Sun employees. There are requirements for people to become sponsors, so please do read this page and the links provided on it (e.g., Sponsor Tasks).
  
• Sun Contributor Agreement (http://www.opensolaris.org/os/about/sun_contributor_agreement/): This agreement helps ensure that the code in OpenSolaris can be used by anyone without restriction. A contributor only has to sign this agreement once for all of their contributions, and the signed agreement applies to any Sun-led open source project contribution. The link I provided here explains what the agreement is for, the process for submitting it, and a link to the document itself.

I'll probably try to get more mileage out of this idea by posting additional blog entries with pointers when I think of them. In the meantime, I thought it would be useful to post this rather than just continuing to talk about it like so many other subjects that didn't turn into blog entries. (How is that "blog talk" entry coming along, Sara?)

By the way, please send suggestions for improving opensolaris.org to website-discuss AT opensolaris DOT org.

Anyway, I hope this is useful because I wrote this when I should have been online doing many other things for OpenSolaris...

P.S. In your face non-DJ AM!

tag: OpenSolaris

If you haven't noticed (or don't remember), it is the 1st birthday (or 1-year anniversary) of OpenSolaris today! We've got lots going on at http://www.opensolaris.org/os/, so please check it out.

Exactly 1 year (really 364 days) after we launched the OpenSolaris project, we have 100 community code contributions integrated into OpenSolaris so far -- not counting the numerous code contributions into the active Projects and the consistent non-code contributions from just about everyone in the community! I'm excessively proud and a bit awed by it all.

I'm happy to admit it, but I was wrong. I didn't think it was reasonable to have an goal of 100 community code contributions integrated into OpenSolaris within a year. I didn't have any doubts about the abilities or willingness of the code contributors or sponsors, but I thought it was an overly ambitious goal for our first year.

I was wrong.

I've learned so much since I started working on the OpenSolaris project 2 1/2 years ago, and much of that since the launch.

For the most part, though, the OpenSolaris community has just reaffirmed what I already knew to be true: OpenSolaris has a vibrant and active community of people who are excited about participating in every way they can. There are countless examples of everyone in the community working together to get something done. It is not perfect, but it's not dysfunctional. I would love to point out specific examples, but that feels too exclusionary. You should check out the OpenSolaris Community Awards (OSCAs) Nominees, though because the community has done a good job of identifying some of the key contributors from this past year.

Looking forward to next year, the OpenSolaris engineering/program/marketing team is going to work diligently with the community to get more code released, refine development processes, make building and testing easier, initiate and continue to drive adoption and evangelize OpenSolaris, revamp the web site, and provide more tools for development. It should be an even more exciting year than this one for improving OpenSolaris as a community and source base. We look forward to everyone's help to make it happen.

P.S. For those of you local to the San Francisco Bay Area, some of us are getting together to have a drink at the Oasis Beer Garden in Menlo Park starting at 6pm today. Hope to see you there! Those of you in other areas of the world should check in with community members in your area to see if thye plan to have a local gathering. Or better yet, plan one yourself!

The OpenSolaris community has so much to look forward to today that I was a bit worried about some of it getting lost.

To start off with, there is (of course) the availability of ZFS. The Solaris Express Community Release of build 27 is available for download as is the source for onnv_27, and I'm sure you all read the available blogs on the subject throughout the day.

I think most people would agree that having ZFS available is more than enough excitement for one day, but the OpenSolaris and tools teams also worked hard to add the following downloads to opensolaris.org:

• The source browser we use on opensolaris.org (OpenGrok) has been released under CDDL. Chandan put a lot of effort into OpenGrok and the project pages, and it definitely shows. I know I appreciate all of his efforts, and I'm sure the community appreciates them even more.
• Binaries with redistribution rights: sccs and make along with the packaging tools. Releasing these tools, along with libm, is will help distributions like SchilliX.

But wait... You don't just get ZFS, OpenGrok, and binaries for additional tools today. If you act now you also get the Solaris 10 University Challenge. This program is a great opportunity to contribute ideas and code to OpenSolaris and potentially make a bit of cash in the process.

All in all, it's a good day (and not in the Ice Cube way).

I had a pretty interesting weekend. Birthday dinners for friends on Friday and Saturday nights and a crew setting up to film a (potential) TV show in our apartment for a few days. That's more than we usually have going on over the weekend, but that isn't the interesting part.

Anyone who has been to my condo knows that the building is very close to the Bay Bridge, and our loft overlooks the Harrison Street offramp. Until CalTrans closed the offramp recently, the significance of this fact was limited to friends waving from their cars as they exited the bridge. This weekend the offramp was demolished.

Now before you get excited, I should say that they don't seem to use explosives for demolition around here. They didn't even use them when tearing down the Bank of America building (you know, the white one with the digital clock in San Francisco) recently. I would have been really excited to see an old-school-Vegas-casino style demolition, but this was still pretty cool.

Last week there was lots of middle-of-the-night prep work which was fairly disruptive, but that was nothing to the giant jackhammer machines that ran 7am-10pm Saturday and Sunday. It turns out that it doesn't take very long to get a headache from that kind of constant noise.

Other than the noise, it was so cool to have a front-row seat. You may write off my fascination as me being weird (which is fair enough), but I saw plenty of picture-taking and ogling from the neighboring buildings.

While I'm sure that the Bay Bridge retrofit project is sorely needed -- and our building will definitely be a lot better off once it is done -- watching the machines do their work got us wondering how severe an earthquake would have to be in order to bring that structure down. The operators really knew what they were doing: they seemed to have a well-developed process for bringing these things down, and it was fun to watch.

No exaggeration, I think we watched those machines for ~5 hours over the course of the weekend. Watching the jackhammers break through 3 feet of concrete like it was cardboard was better than TV. Which is why I had a headache all weekend...

To be fair, most of the heavy demolition work was done on Saturday, so the noise wasn't nearly as bad on Sunday. Though there was still enough noise to freak the setup crew out on Sunday.

All in all, I wouldn't have missed this for the world. I mean, how often do you get to see something like that from such a close distance. I can't say that I'm looking forward to CalTrans tearing down the entire western approach next year, though. The hallway overlooks that, and there will be way too much noise without the benefits of not leaving the couch. I think we'll plan a trip out of town that week.

Unfortunately, I don't have any "before" pictures of the offramp, but here are some of the shots we took through the weekend.

Today 20 people involved with OpenSolaris were honored with an internal award: the Software People's Choice Award. As the name implies, this is an award for people working in the Software organization at Sun, and anyone can nominate individuals and teams. Four people/teams are given the award each quarter, so I really do feel honored to be on a team that won. It isn't the nobel prize, but...

I do have some mixed feelings about the team being recognized with this award.

These 20 members of the team worked extremely hard, and (I think) should be singled out, but we aren't the only people who worked hard to make the launch happen. Many engineers sacrificed several evenings, weekends and other project work to help us get ready to release. Without them we wouldn't have gotten to opening day, had the blog launch or as vibrant a community.

So many people deserve credit for making OpenSolaris a reality, and it is difficult to draw the line in the right place: rewarding the extraordinary effort of the "core" team while acknowleging the valuable contributions of so many other people who helped make OpenSolaris viable. I suppose awards are just inherently exclusive, but my hope is that this one won't have an impact on the overall teamwork I admire so much on this project.

Anyway, I just wanted to take a moment to thank all of the people inside and outside of Sun who helped get OpenSolaris off the ground and continue to make it successful, and I know the rest of the team feels the same way.

We're now entering the next phase of OpenSolaris. It's been a long time coming -- and we're not done yet -- but the availability of this much code is a huge step in the process.

It has been an enormous undertaking, and I am constantly impressed with what we've accomplished to date:

• We've created a new license that we think is business friendly and will help us build a thriving community and an even better product.


• We've created a website that helps us start an ongoing conversation with members of the community.


• We've started to drive cultural change within the engineering team. The entire engineering team needs to be part of the community, and they are helping everyone get there as quickly as possible.

I probably haven't said enough to convey how big an effort this has been, but I'm not sure I have the words to express how much everyone has done. I can say that we're just getting warmed up, though...

Our Pilot community has been so helpful and dedicated, but there was only so much they could do to build a community in an NDA-constrained program. It was definitely time to move to the next phase and do our first big code release. We've made countless priority calls to get to this point, so you may need to check back to see if your code/feature/forum is available after launch.

You aren't going to agree with all of the priority calls we've made for this release. I don't agree with some of them, but I stand behind every one of them. More importantly, I am the person who will take all of the blame and none of the credit for making these decisions. With this launch everyone has the opportunity to provide input on what our priorities should be going forward.

I should probably focus on all the positive things we've done for the launch, but I'd rather do some 'splainin' about areas you may find frustrating:

• Having only the core kernel, networking, libraries, and utilities code available
  We had to start somewhere, and our (admittedly biased) opinion was that the core was the best place to begin. We have lots of evaluation to do of our current, internal delivery mechanisms for all the other areas of Solaris, and you'll want us to do that before dumping lots more code into your laps.


• The amount and type of core code being released in binary-only form
  This is a starting point, and we're working as quickly as possible to make more code available. I know it seems straightforward, but the level of complexity involved here makes my head hurt. Thank goodness Bonnie keeps it all straight, and I hope she'll soon have time to tell you more about it in her own blog.


• A daunting development process/model
  While we absolutely want to make our development processes more "community friendly," we don't want to just throw away our current processes. Good, bad, or indifferent these processes have helped us manage 1,000+ developers delivering to a single code base. Having sat through the meetings, I'm sure Al Hopper will confirm that there is actually some thought that was put into each step. I don't think anyone would say that there isn't room for improvement, though.


• Limited website functionality
  We want to build something truly great with the website, and want to be sure that the tools we use match our development processes rather than the other way around. We need your input to help define the way the tools should work.


• Lack of historical technical information
  You'll see more and more historical information available over time. We need to scrub documents and other historical information for confidential materials before we can make them available. I certainly wish we could have people in the community help with this, but this is one of the areas that someone within Sun needs to do the work. You can certainly help us prioritize by asking for specific documents/information. We are already prioritizing documents for scrubbing, and your input will be helpful.

I may not have convinced you, but I hope you have a sense that we do "get" open source. The choices we made, imperfect as they may be, have the best of intentions behind them. We aren't trying to hide features, code, or our decisions, though sometimes we have legal reasons for holding back.

I know most of the team would have liked this initial release to be even more complete, but (again) this is just the next step. My belief is that releasing this portion of code now will help us get to the next steps.

Thanks to all the amazing people inside and outside of Sun that made this launch possible. It really has been a team effort, and I'm proud to be part of it.

You're probably wondering who the hell I am at this point, since I haven't written a weblog entry before. I'm the engineering manager for the OpenSolaris project. I work directly with Jim Grisanzio, Keith Wesolowski, Mike Kupfer, Stephen Harpster, and (of course) the larger Solaris development organization. Before that I was a program manager in the Solaris kernel group. The last project I managed was Zones -- working with David Comay, Dan Price, and many other engineers. Before then I worked on Solaris Resource Management projects working with engineers like Stephen Hahn, Andrei Dororfeev, Liane Praza, Joost Pronk, and many others.

Words can't express how amazing this group is. With OpenSolaris, you'll get to find out for yourself.