Andy Tucker's Weblog

First of all, Good Job! Agree with the diversity and choice part. Models...a recent example is the Fedora project, Red Hat is having teething problems opening up their distribution - there is no public CVS repository yet to which contributors have access. But they are getting there slowly. Theirs is probably closer to your present circumstance, i.e. opening up a previously closed model, than other projects like GNOME and the Linux kernel which started out open. You could probably watch what they are going through to get some idea of what is involved. Specific requests: 1. A bug / issue tracking mechanism that folks can access without needing a support contract. 2. Public, read-only repository with frequent updates for bleeding-edge people rather than milestone releases only. 3. Open mailing lists or forums where the kernel developers intermingle with the unwashed masses and take decisions, bug reports, patches etc. Good luck.

Posted by Sahil on June 20, 2004 at 07:26 PM PDT #

Make the development as open as possible. This is prevents forks, builds community and encourages developers to contribute. Make it Solaris, as opposed to Sun's Solaris. Of course, it can still be Sun's Solaris when it the time comes to sell it as a product. In terms of governance models, just make it sane and as independent as possible from Sun. Look at where it seems to work (e.g. GNOME) and where it doesn't seem to work so well (e.g. Debian).

Posted by Anon on June 21, 2004 at 02:41 AM PDT #

Like (3) above but adminitration view: put in a core team that can actually make decisions and give instant public feedback about directions of "the project". There have been attempts to just relicense software under opensource but not much was returned. That's when the development model is still blackbox style and it is unclear who where why when makes decisions with the results seen only at the next release.

Posted by guidod on June 21, 2004 at 04:20 AM PDT #

on bug/issue tracking, there should be some 'faster' mechanism to link between Sun internal bug database and the public access database. speaking as ex-sun contractor (i used to do localization testing for 3 years, on Solaris, Netscape, Java and OpenOffice.org) there are consirable amount of delay between Sun internal bug database (the one that you need a Sun employee id to use it on Applet), and the public access on (from www.sun.com)). and that delay makes the lost of communication, lost of encouragement. if Sun really wants an open development, the amount of delay should be decrease. people need quick response. (i.e. WONTFIX is fine, but please tell me quick - and why?) go on! :)

Posted by bact' (still a Sun believer) on June 21, 2004 at 04:22 AM PDT #

I am a bit skeptic about opening up Solaris. I have always loved the Solaris OE, and recently joined (march) as an intern. One of the problems I have with this is that a lot of folks have put it in incredible amounts of time working on features that are infact extra-ordinary. By open-sourcing there's a possibility that other companies (perhaps MS) may start to implement these in their own kernels and worse: in a better way. Leaving Sun at a loss. How are we going to deal with that? In my opinion, open sourcing solaris is more of a publicity act that might come back later to bite us in the back. Plus accepting changes from the community will probably lead to a nightmare down the road, given the way ARCs (rightfully) criticize projects. Why can't we pursue something like the Java community process? Sure you would be able to provide changes, but we still have tight control on the source. What are your thoughts on this?

Posted by Shawn Debnath on June 21, 2004 at 08:13 AM PDT #

hmm, Sun might want to open source solaris in baby steps, you don't want lots of kernel vulnerabilities just because now you have lots and lots of eyes looking at the source.... That is probably the biggest danger from a security point of view. Can solaris ideas, design be rolled into Linux now? or will that depend on the licesning?

Posted by Anuj Goyal on June 21, 2004 at 09:22 AM PDT #

0. Fix your blog comments to allow paragraphs! ;-) 1. Don't make up yet another ridiculous licence. Use whichever one of the standard troika (GPL, LGPL, BSD ) makes sense for any particular part. Dual licence is fine, but as soon as you are GPL incompatible.... IBM managed it with eclipse but thats about it. You know this from OpenOffice. 2. Accept that you might be going to lose "value-add" . A good example of this is DTrace. This is being talked up as a solaris selling point, but if its going to be open source, people will be able to port it. Accept this - don't resist it. People will just fork it otherwise, and if the licence is broken, just functionally clone it. Allow patches to support other OSes in the whole of userland. 3. The only similar projects are the BSDs. (kernel + basic userland + distribution of third party apps). To be honest, none of them have "great" community involvement - FreeBSD being the best of the bunch in that aspect. There are many flamewars about why this is... You are probably better off running these things as separate projects, but with good communication channels. 4. The only *really* successful distributions with community involvement have no corporate controller. Gentoo, Debian, FreeBSD to some extent. So look long and hard at what Redhat went through with Fedora.... which after growing pains is going very nicely. 5. Cooperate. Get really stuck into projects that would like to interface with Solaris - eg freedesktop hal & xorg projects, gnome, kde, rather than waiting in the sidelines and porting/forking in private. 6. Solaris won't be open source if large bits of userland rely on proprietary Java. Think this over.... do you really want to give this much publicity to GCJ, when someone releases a GCJ "Truly Free" version of solaris?

Posted by Robert Wittams on June 21, 2004 at 09:46 AM PDT #

If the goal is to open source the OS to allow people to contribute, and Sun maintained control over what got into the code base, I would favor that (especially if the userland tools got upgraded to the GNU versions --/usr/bin/awk is gawk versus awk -- and yes, I am aware of the freeware "add ons"). I have been frustrated on numerous occassions when an upgrade to a newer Linux kernel (2.4.17 -> 2.4.22) broke old functionality. I want to ensure that updates from outside Sun wouldn't impact the stability we have grown to enjoy with Solaris. I love Solaris, and think it is tied with OS X for the best OS out. ;) Just my .02 - Ryan

Posted by Ryan on June 21, 2004 at 10:14 AM PDT #

Robert, I couldn't agree more with your comments, however, got a question: How are we going to make money if all our *cool* features are ported/cloned/forked into other systems. Revenue from support is merely not enough to put Sun back into profit. I would completely agree with you if Sun was focusing only on hardware sales. However, our focus is different. We are giving away hardware if you purchase our software subscription plan. On the other side, I do agree, instead of working on GNOME privately, help out the GNOME developers better integrate with Solaris. Perhaps we wouldn't still be running 2.0x on our workstations but something more appealing like the 2.6x.

Posted by Shawn Debnath on June 21, 2004 at 10:16 AM PDT #

Something I haven't heard anyone mention is the fact that UNIX(tm) [ie: SCO IP] code is in Solaris. Sun pays out big bucks to license it. Just based on this alone it would seem that Sun can't really open source Solaris, at least not all of it. And even putting that aside, I consider myself an open source zealot, but I can't see any real gain for Solaris by open sourcing it. As a customer it would be nice having the code if I wanted it, sure, but I can't see Sun opening the codebase and developers flocking to it, certainly not like Linux. Sun gets a small temporary boost in PR out of it, but what then. Solaris10 is doing so much moving and shaking right now that I don't see a reason to open Solaris... except maybe to pick up some decent display drivers on X86. :)

Posted by benr on June 21, 2004 at 10:40 AM PDT #

Robert, I couldn't agree more with your comments, however, got a question: How are we going to make money if all our *cool* features are ported/cloned/forked into other systems. Revenue from support is merely not enough to put Sun back into profit. I would completely agree with you if Sun was focusing only on hardware sales. However, our focus is different. We are giving away hardware if you purchase our software subscription plan. On the other side, I do agree, instead of working on GNOME privately, help out the GNOME developers better integrate with Solaris. Perhaps we wouldn't still be running 2.0x on our workstations but something more appealing like the 2.6x.

Posted by Shawn Debnath on June 21, 2004 at 10:44 AM PDT #

Strange...it posted the old comment twice ;) Ben, you hit it right on target!

Posted by Shawn Debnath on June 21, 2004 at 10:46 AM PDT #

Side-note one: yes, I'd like paragraph breaks in comments too, particularly since I'm going to do a large post in an hour or two. Side-note two: the "remember information?" option doesn't seem to work. With regards to SCO, I remember Jonathan Schwartz saying that Sun has rights "equivalent to ownership". I also remember it being said (though I forget who) that no original Sys-V code remains. With regards to copying code, I think it would be technically very challenging in many cases - kernals are very different. With porting time, testing, release cycles etc, they'd still be years behind Sun I'd think. I'm sure the Linux guys wouldn't copy it even it was GPLd - they're rather re-invent it. Similar for others. There's also things that could be done with patents and licenses to make things "interesting".

Posted by Chris Rijk on June 21, 2004 at 11:33 AM PDT #

Here's some thoughts: (*) First - "do no harm". It would be unfortunate if open-sourcing Solaris added lots of extra work or red tape to Sun's engineers. If it was done badly, it could hurt development of Solaris, which would not be good for anyone. (*) If you haven't already, I suggest talking to people in the OpenOffice.org project, like Danese Cooper. Learn from their experiance with regards to licensing, and concerns contributors have. (*) Don't have to be perfect from the start. For example, the Java Community Process has gone through a number of revisions (not that I'm suggesting Solaris should be done like JCP). Still, the better the initial (public) roll-out, the more interest and contributions you'd get. I'd suggest doing a fairly private "beta" test, for at least a month or two, before launching publically. (*) I'm not particularly concerned about which license you choose. I don't think OSI compatible is requirement, but would help. Whatever Sun choose, there will be criticism from some groups or other. I think it is important to explain why the final choice was made - ie what were the trade-offs and considerations. I also think that people who are most hard-core about OSI or GPL are the least likely to contribute anyway. What's most important is what likely contributors to Solaris actually want, not what the open source community in general wants. (*) It's not just about programmers - whatever website and programs you have relating to running an open sourced Solaris program should not be only aimed at programmers. People who may not have the skill or time can contribute ideas and testing. There's also documentation, styling, translations, guides, maybe even benchmarking. I'd also recommend doing something like the bug-parade and RFE (Request for Enhancement) stuff in Java - where members can vote on what bugs or enhancements they particularly want. (*) I think it's quite reasonable to have a "private" site for the project (or at least, mostly private) - ie requiring registration and so on. However, the registration process should be simple. For example, a lot of people might be interested in reading docs, and contributing to discussions, but would not want to have to fill out a huge detailed form. (*) I think it would help to make availble some Solaris systems that contributors can use for some testing or experimentation - with Solaris Zones, this should be pretty practical for simpler stuff. I'd suggest at least one Xeon box, one Opteron box and one SPARC box. (*) As for how third parties could actually get the code and get changes added: I think the best thing would to have a CVS repository which can be acccessed remotely, which is a *copy* of whatever Sun have internally (very safe). With updates copied over automatically (daily or something). Basically only Sun employees can submit changes to the root system (though maybe this could get opened up a bit in the future, particularly for non kernel stuff or documentation). I think it would be reasonable that anyone wanting to either submit a patch or enhancement should first mention this to the relevant people at Sun. I think the best way to do that is to have lots and lots of discussion forums, one per group of engineers / module / group of code. (or maybe two per group - one purely for discussion, one just for announcements of changes to the code). So say you want to make a change to the Dtrace code, you go to the Dtrace forum, say what you want to fix, and why, quoting bug-id (or getting one submitted), and getting feedback on whether it's already being worked on or whatever. Changes can then be commited to CVS, and then commited to the internal system once it has been checked over and tested. I think that would be reasonable for kernel code - certainly need a fair amount of paranoia for that. (*) What would be best for someone wanting to create a whole new module I dunno. Ditto for ISVs wanting to do major changes. I'd expect most submitted changes to be relatively minor though. (*) I think it would be good to have a web forum (with good searchable archives). For that, please have a forum with threaded posts. After all, Solaris is the king of threading ^-^

Posted by Chris Rijk on June 21, 2004 at 03:19 PM PDT #

It would still make better sense for Sun to open Java than Solaris. But as to the OS, I agree with those that suggest letting it out in pieces. That would be easier and less painful than trying to push the whole thing out. I also agree with the "stick to a core open license". Making another one would more work, especially on the management/legal side. Lastly, I hope that Sun will finally come to terms with the fact that they are a hardware company and proceed accordingly. Make good SPARC systems and sell them with whatever OS the customer wants. Linux, Solaris, NetBSD... Make the HW more affordable, take the software licensing costs out of the mix and you'd see a definite turn around in SPARC sales. But you better start on this soon. The window of oppertunity is closing fast.

Posted by Joe Klemmer on June 21, 2004 at 03:57 PM PDT #

[Trackback] From Andy Tucker's Weblog: on opening up solaris (link via ongoing � Sunbeams, Father’s Day Edition) a good post asking for input into how to get Solaris to open source. I like the questions and the attitude. As a Linux

Posted by 42 on June 21, 2004 at 04:50 PM PDT #

some of these: -kernel released with an existing gpl-compatible license, or directly gpl -an apt-get on solaris (or ports/portage. the important bit is cooperating with an existing package database, ie fink on osx) -a debian/solaris just like there is a debian/kfreebsd|knetbsd|hurd The more Solaris interacts with existing projects, the better; i don't think that revenue from Solaris will ever put Sun back into profit. but obviously, a truly opensource java endorsed by sun is much much more important than an opensource solaris. "Why can't we pursue something like the Java community process? Sure you would be able to provide changes, but we still have tight control on the source. What are your thoughts on this?" maybe because you just need to control something less, for example the java brand/name. why with that tight control on the source there are a dozen of independent jvm out there? somewhere on an old planet.gnome.org blog entry i read that at oracle they ended up reimplementing internally a jvm because of the "tight control on the source". is this the kind of central-development-with-no-fragmentation that the tight control on the source by the Java community process wants to achieve?

Posted by tapeworm on June 21, 2004 at 06:03 PM PDT #

Why bother? There's nothing to gain aside from some geek PR and hipness and trash sites like slashdot.

Posted by Joseph X on June 21, 2004 at 11:56 PM PDT #

This is a terrible idea. Sun will probably not license under GPL of policital reasons, and the freer licenses are inappropriate for this. Microsoft would love to embrace and extend and eat your business before lunchtime.

Posted by jb on June 22, 2004 at 02:19 AM PDT #

Shawn, Sun really aren't going to be able to rely on OS-level products or features to keep afloat. The only way this would happen is if they could create a radically better OS than tired old Unix and its clones(nt), eg a capability based OS - and get real momentum behind it. Doubtful. They know this, and are focusing on hardware, services, and software components "higher up the stack". The useful OS level stuff in solaris will be cloned if its not transplanted - remember IBM is working on Linux now, its not as if they don't have the resource. TBH, I see solaris and linux becoming more and more compatible / interchangeable as time goes on. I see no reason for Sun not to GPL (as they have with OO.o ) . And I agree with others that Open source java is a lot more important to the users of Java than open source Solaris is to the users of Solaris.

Posted by Robert Wittams on June 22, 2004 at 03:14 AM PDT #

releasing solaris under the GPL is basicly giving you IP away. Red Hat would adopt Solaris and start selling support for it .. ehhh.. GPLing is a horrible idea for companies. its better for communists, the all ANTI business crap the GNU had long time ago and all the anti corporate software crap they spread. ohh maybe they changed but their license didn't still can't close it.

Posted by uh on June 22, 2004 at 10:50 AM PDT #

I'm a Linux user, and I don't feel threatened by this at all. This can only be a good thing: having another open-source operating system, and (from what I hear) a fairly advanced one. I don't feel that FreeBSD is "attacking" Linux, and I don't see why this would be any different. I do wonder if this will be useful in the SCO case, either as (a) evidence / prior art / etc. that Linux hasn't "stolen" code, or (b) a backup plan, so on the slight chance that SCO wins in court all us Linux users will have something else to switch over to. (Yeah, so we already have a couple of BSDs ...) The hardcore optimist in me says "When SCO sees that even shutting down the Linux kernel won't do any good for SCO, they'll give up and go home." (Of course, then the realist in me slaps my face to wake me up.)

Posted by X on June 22, 2004 at 03:22 PM PDT #

As others have suggested, it would be much better for Sun to spend its effort doing several things (mostly related to Java): 1) Make the Java Compatibility Kit more freely available. Sure you forego licensing revenues (which are probably small in the scheme of things) but this would allow the Sun Java VM, IBM VM, and gcj to be more drop-in replaceable (they aren't at the moment - not just because gcj/Classpath is incomplete). Something has to be done to reduce the growing threat of the C#/.NET lock-in otherwise Java will be reduced to a niche. I think Sun's Java is open sourced enough (you can unpack the source jar if you like) and Sun has granted permission for independent implementations (eg. gcj, kaffe, SableVM etc.) - which is good. But make that compatibility kit available without cost. 2) Make sure Solaris stays the best platform for Java. Not by crippling the Sun Java VM on other platforms, but my making sure Solaris is designed to help the VM. When Java is clearly the best development platform (which isn't yet as its *client-side* performance has only become usable in Java 1.4.2 and the 1.5 betas) then businesses will buy Solaris (and the Sparcs to go with it). 3) Tell the Java boys to cache the Java objects produced by the JIT, not just for the Core classes (ie. ahead-of-time compilation). Something has to be done to improve the start-up time of Java on the *client* platform. If Sun doesn't get this right then C# will take over the client and then move to the development space on the server now taken by Java (at which point Sun will be buggered in terms of developer mindshare). 4) Improve compatibility with the GNU/Linux libraries, even if they are inferior compared to Suns. If 'native/C/C++' apps don't compile first off then only a few hardcore coders will be bothered tweaking to get ordinary applications to run. Ok, so the above was a bit off topic, but I think open sourcing Solaris will not draw many more developers to it unless you are going to give Solaris away as well (in which case Solaris becomes 'Sun's implementation of Linux'). Better use of Sun's resources is to permit more use of the Java compatibility kit to enhance Java, and thereby Solaris. Fingers crossed Sun would get some sales out of this as the best platform for Java.

Posted by Mike Reid on June 22, 2004 at 03:41 PM PDT #

Opensourcing Solaris has sense if you aren't making big bucks from licenses but instead you are making a ton of money from support and you see that CLOSED-Source Solaris is going to be EOL in 5/10 years. Opensourcing Solaris could extend that life even beyond 2030. Anyway I don't believe that current companies who base themselves on Linux or on FreeBSD today will switch on 3rd party Solaris support. Switching from a Linux knowledge-base to a Solaris one costs. Moving engineers on porting features from Solaris costs. The shops that will be helped majorly will be the ones that are already Solaris licensees or resellers. In the long run SUN will lose technical advantage, but SUN herself will gain competitivity since its ground will expand itself to reach new customers, admins and markets. The biggest possibility from a GPLd Solaris (IMHO) would simply be to enlarge the Unix userbase both on workstation-class desktops (oh, I really would like a 100% supported Unix desktop that recognizes all my cool hardware a-la MacOS X) and on servers since "opensource hardware drivers" would simply become the new standard of distributing drivers.

Posted by Davide Inglima - limaCAT on June 22, 2004 at 04:20 PM PDT #

"since "opensource hardware drivers" would simply become the new standard of distributing drivers" I don't believe that. Solaris had a solid driver ABI for years. Opensourcing the kernel wouldn't change that.

Posted by Anonymous on June 23, 2004 at 12:38 PM PDT #

Unfortunately, the decision seems to have been made regarding this issue and there's very little we can do about it now. So there is no point bickering about this topic, and hope (I pray) that Sun will attain the goals it has set for itself by open-sourcing Solaris. Time to accept the drastic new ways of cutting costs and embrace the new software development model...I suppose. Signing off..Shawn

Posted by Shawn Debnath on June 24, 2004 at 10:34 PM PDT #

In reguard to Roberts comment... I want to disagree on your feeling that Solaris technologies (namely DTrace, as you mentioned) will be ported to other OS's. DTrace, Zones, etc, are so entrenched into the kernel that they aren't things you can simply yank and port to a kernel like Solaris; you'd have to completely re-implement them. Thats something you could do now, today, by taking the Linux source, adding a crapload of probes into the code and then writting an interface that is similar to DTrace's scripting interface. Frankly, I doubt such a patch wuold even be accepted the first time around since it involves adding code to so many critical places in the kernel, and certainly not untill the 2.7.x branch opens for business. Maybe it's just me, but I don't see much opertunity for other systems to take Sun open sourced code and start pumping it into other projects. Now, certainly I can see Sun code being carefully researched for ideas into how to make Linux as rock solid as Solaris (don't bother debating it) but thats about it. That said, I still think that Sun has almost nothing to gain by open sourcing Solaris... Sun has proved time and again, starting with NFS in 1984 that they are 100% behind open standards and aren't stingey with code or ideas. And unless you think there are folks out there willing to hack on Solaris at 1am on a work night, there isn't a big benifit that isn't already there. Frankly, I hope this is just a big PR stunt.

Posted by benr on June 27, 2004 at 03:09 AM PDT #

[Trackback] As well as the discussions going on in Andy Tucker's blog , the following is a list of news items that have shown up with regard to Sun Open Sourcing Solaris. June 29 Sources: Sun Plans to Open Nearly All of Solaris Source Code June ...

Posted by Alan Hargreaves' Weblog on July 02, 2004 at 04:17 AM PDT #

We're wrestling with similar but different issues with TinyOS. Although it's always been open source, it's generally had a pretty closed development team. There are a few rare cases where the TinyOS developers incorporated external code, but they are, well rare. The problem we're trying to figure out is how to build a user community/contribution model. At a recent retreat, we had four people talk about four different approaches: Kirk McKusick for FreeBSD, Matt Welsh for Linux, Deborah Estrin for the IETF, and Wei Hong for Postres. We're still trying to figure it out.

Posted by Philip Levis on July 13, 2004 at 06:17 PM PDT #

As far as drivers go, just opening up the source is a horrible, horrible thing. 'cause I know personally, that there is a good chunk of undisciplined code in some solaris drivers! Having unexperience driver coders take that stuff and proliferate it, would be a very bad thing.

FIRST you need to document and publish more kernel APIs. THEN you need to mandate that existing drivers get rewritten to STICK to the APIs. THEN you should start possibly releasing source code to the compliant drivers that are good examples for people to follow.

Posted by Philip Brown on August 09, 2004 at 01:23 PM PDT #

Probably nothing good is going to come of open- sourcing Solaris. Most likely all of Solaris' great ideas and work will simply be taken by Linux (and the Linux types will rewrite history and make out that they did it as they did/do with Unix). Solaris will never be accepted in the Linux/GPL world as it carries the taint of "proprietary" software. Sun is seen more as an enemy among the Slashdot crowd more than anything else.

Posted by Kent on September 15, 2004 at 10:34 PM PDT #

Contrary to some of the other comments, please don't open it in pieces or in "baby steps". This would only create the impression that Sun isn't serious about making the code available and discourage outsiders from taking it seriously. When the code is ready (technically, legally, etc.) and if you have decided to provide it under an open-source licence, it should be released as a package, something that can be downloaded, installed, rebuilt from the sources. Often, open-source licences provide that any modified distribution of the code must state prominently that it is a modified version, refer to the original and be renamed (in this case not called "Solaris"). This or a similar range of provisions would be useful in providing assurance that anything called "Solaris" is a genuine release, without precluding other distributions contrary to free/open-source principles. From what I have read, open development helps to foster community contributions, with decisions, with open planning on mailing lists, open bug databases, open access to developmental code, etc. Obviously there would need to be a clear process for accepting contributions, among other reasons to ensure that the would-be contributor holds the copyright to those changes, with quality review of the submitted code by highly experienced developers before it is accepted.

Posted by Jason White on September 18, 2004 at 08:21 PM PDT #

Java Community Process: - pro: the product became monotonically better. - con: a number of people don't like Sun (or any one company, presumably) controlling it It's like the US in Iraq: you need to lead and still get others to cooperate with you.

Posted by Mark Francis Villa on September 27, 2004 at 03:29 PM PDT #