Slashdot Mirror

Sun do get it (though it took a while) - Jini http://jini.org/ has been opensource under ASLv2 for a while now.

I have had the pleasure to read the SCSL a few times, to enjoy its full literary value. Some of the provisions in the SCSL are very interesting attempts to extend copyright without regard for copyrightability, others are pretty bold attempts to grab patent-like protection without going through the patent process. That may have been just funny back in 1999. These days, after SCO has shown how much expensive mess a rogue 'copyright holder' can do without even owning copyrights, and having such privileges written down in their licenses, I think it's justifiable to call licenses explicitely grabbing such wide privileges dangerous, or more mildly, 'bogus'.

I really don't get this attitude to Sun. Stuff that they have released like OOo have been vital for the acceptance of Linux on the desktop. They have done so much good for the IT industry over the years.

Sun is a respected member of free software community, and does a lot of things that are just plain great. They also do a few things that are not that great. That's understandable, it's a company after all, it's not a charity.

Sun's choice of licensing their Java technology implementations is their own business. A critique of some of Sun's licensing choices does not imply critique of Sun's other actions.

For example, JCP is a great idea. The execution is not that great though, the specifications coming out of it in the J2SE area have over the years decreased in quality, in my opinion. The JLS3 has stil not been released as a final specification, *years* after the assert keyword was added to the language.

As a Sun Java user, you may chose to interpret that as an attack on Sun, without undertaking the effort to validate my assertion against facts, instead validating them against your beliefs. That's fine. It's a human, emotional response. But as you may have noticed during the course of our discussion, I have made several assertions that you believed to be untrue, that have in fact turned out to be somewhat contrary to your initial beliefs.

There is a difference between what you believe to be true, and what is true. I call SCSL cooperation unfriendly not because I have a bad attitude towards Sun, but because Sun themselves are changing away from the SCSL for JINI, another 'crown jewel' technology in Sun's crown, in order to encourage further adoption, remove restrictions on user code licensing, and to fix issues with commercial multi-tiered distribution. See http://community.jini.org/servlets/ReadMsg?list=di scuss&msgNo=1182 They are switching to ASL2.0, btw. See http://community.jini.org/servlets/ReadMsg?list=di scuss&msgNo=1404 for details.

cheers, dalibor topic

I have had the pleasure to read the SCSL a few times, to enjoy its full literary value. Some of the provisions in the SCSL are very interesting attempts to extend copyright without regard for copyrightability, others are pretty bold attempts to grab patent-like protection without going through the patent process. That may have been just funny back in 1999. These days, after SCO has shown how much expensive mess a rogue 'copyright holder' can do without even owning copyrights, and having such privileges written down in their licenses, I think it's justifiable to call licenses explicitely grabbing such wide privileges dangerous, or more mildly, 'bogus'.

I really don't get this attitude to Sun. Stuff that they have released like OOo have been vital for the acceptance of Linux on the desktop. They have done so much good for the IT industry over the years.

Sun is a respected member of free software community, and does a lot of things that are just plain great. They also do a few things that are not that great. That's understandable, it's a company after all, it's not a charity.

Sun's choice of licensing their Java technology implementations is their own business. A critique of some of Sun's licensing choices does not imply critique of Sun's other actions.

For example, JCP is a great idea. The execution is not that great though, the specifications coming out of it in the J2SE area have over the years decreased in quality, in my opinion. The JLS3 has stil not been released as a final specification, *years* after the assert keyword was added to the language.

As a Sun Java user, you may chose to interpret that as an attack on Sun, without undertaking the effort to validate my assertion against facts, instead validating them against your beliefs. That's fine. It's a human, emotional response. But as you may have noticed during the course of our discussion, I have made several assertions that you believed to be untrue, that have in fact turned out to be somewhat contrary to your initial beliefs.

There is a difference between what you believe to be true, and what is true. I call SCSL cooperation unfriendly not because I have a bad attitude towards Sun, but because Sun themselves are changing away from the SCSL for JINI, another 'crown jewel' technology in Sun's crown, in order to encourage further adoption, remove restrictions on user code licensing, and to fix issues with commercial multi-tiered distribution. See http://community.jini.org/servlets/ReadMsg?list=di scuss&msgNo=1182 They are switching to ASL2.0, btw. See http://community.jini.org/servlets/ReadMsg?list=di scuss&msgNo=1404 for details.

cheers, dalibor topic

Using Jini, two devices running Java will be able to understand each other. The idea is that devices that need to be controlled expose not only their API, but their user interface. Thus, if you had a Jini-enabled remote, and it found a stereo on your bluetooth network, it would download the UI for the stereo from the stereo and display it on the remote. Since the UI would be made by the stereo manufacturer, it would allow you to control all its features. Java's security model allows this to be done in a secure fashion.

Check this out before you embarass yourself.

For the first time ever, I recently came up with a problem that could be solved rather nicely with something like Jini or Rendezvous. Until now, Rendezvous meant "OS X only", and obviously would be much less usable in the real-world than Jini, which is Java-based.

I think it will be interesting to see if Rendezvous can really fly (I would like to see it succeed). I doubt we'll see apps like Hydra (Rendezvous-enabled text editor) on any OS other than OS X, but maybe we'll see other cool apps that leverage the flexible networking technology of Rendezvous.

Check out Jim Waldo's presentation about this.

Jim Waldo recently spoke at the 7th Jini Community Meeting about the uses of these very same types of devices. Here are the slides to the presentation.

I am afraid you are under the wrong impression of what Jini is or does.

Jini is a distributed services platform. It distributes those services in a certain way, based on a Service Oriented Architecture and mobile code. That's it. Jini provides some core services, but the creation of services is up to the developer.

Take Javaspaces, for instance. Not only is it a spec, it is also an example of a Jini Service.

If you want a distributed file storage, go to www.jini.org and find one. Not there? Start one. Jini is not a protocol, it is protocol independant. Use any protocol you want in your service.

Ironic that here on /. that someone would be complaining that they have to take part in a community process to get what they want!

You may want to check it out now.

BTW, read the spec and implement Jini yourself if you think thestarter kit is "crappy". You even get the source code to refactor, if you like.

Ohh, touchy.

Well, I never claimed that Sun "invented" mobile code with Jini, just that the ideas espoused by Obje have been done before and are currently available for anyone to download from www.jini.org .

So, seriously, what other past implementations of this have there been? I am really curious.

As for your cracks about the real problem being a Java-based implementation, I will take it you are one of those "if it ain't GPL it ain't free" zealots. So please, provide links to the C++ version of a Jini-like framework. Or the Ruby version. Or the Python. Or C. Anything as long as it is OSS certified. While your at it, point me to the one that has the default sand-box for running the mobile code, making it more secure - other than a Java implementation.

My idea of giving "props" was because the referenced article mentions that "Obje can be built on top of mobile-code frameworks like Jini"...and Jini has historically been "ignored" even within Sun.

Or did you not bother with the formality of actually reading the article?

Hmmm?

And if Jini and Obje address different problems, perhaps you can enlighten me just what problems they each address that is so different, 'cuz it looks pretty identical to this Jini programer.

Uhm, try going here and see how "dead" Jini is...

'Cuz it's not. Not even close

Glad to see PARC is using the idea of mobile code from Jini. The Jini Community has been doing this for over 5 years now. And it's not just for devices. Quite a few companies have used it as a platform for enterprise computing - in many ways it even competes with J2EE/EJB in this area.

Jini is a great Service Oriented Architecture (SOA) that is VERY secure yet still involves mobile code rather than just RPC calls.

It is a Java-based solution, but is opening up to other languages through the Surrogate Architecture...

Anyway, if we get excited about something new from PARC, we should investigate a fairly mature technology that it is built on top of.

If you think Obje is cool, check out RIO. Not just dynamic networking and mobile code, but dynamic provisioning and Quality of Service...

"Let's see .Net do that!" :)

Glad to see PARC is using the idea of mobile code from Jini. The Jini Community has been doing this for over 5 years now. And it's not just for devices. Quite a few companies have used it as a platform for enterprise computing - in many ways it even competes with J2EE/EJB in this area.

Jini is a great Service Oriented Architecture (SOA) that is VERY secure yet still involves mobile code rather than just RPC calls.

It is a Java-based solution, but is opening up to other languages through the Surrogate Architecture...

Anyway, if we get excited about something new from PARC, we should investigate a fairly mature technology that it is built on top of.

If you think Obje is cool, check out RIO. Not just dynamic networking and mobile code, but dynamic provisioning and Quality of Service...

"Let's see .Net do that!" :)

Kind of like JINI?

Jini and JavaSpaces are being used in a variety of organizations to build large, distributed, reliable, scalable systems that integrate a wide variety of existing systems, including those written in languages other than Java. The technology seems a good match for this problem.

Patrick

StrangeBerry is involved in a lot of networking projects, including UPnP and Java Port of ZeroConf.

Obviously this is going to allow for some level of interaction between your TiVo and equipment on your LAN, be it your router, your PC and/or your Mac. This could lead to an interface betweeen your TiVo and iTunes using Java. Maybe it is about pulling down content over broadband to your TiVo, though DRM concerns immediately come to mind. Maybe it is both.

Only time will tell.

I agree with you and there already is a Java sub-culture doing just that - the Jini and JavaSpaces community. Highly distributed, self-healing, self-forming federations of services and distributed shared memory realms. Combine it with say Java WebStart for distribution and/or RIO for dynamic provisioning and you have one hell of a powerful distributed computing platform. And, because of the Java sandbox and the new Jini 2.0 security features, on that can be make sharing mobile code relatively safe. Throw in the Jini Surrogate Architecture and perhaps JXTA and you have services that can be accesses by any client in any language....

Sounds intriguing, no?

As for you speed issues, try using the j2sdk 1.4.x (currently 1.4.2_03). Not only to do get peppy speed, but the latest version allows for full screen mode, so yes, you can make screen savers....

I agree with you and there already is a Java sub-culture doing just that - the Jini and JavaSpaces community. Highly distributed, self-healing, self-forming federations of services and distributed shared memory realms. Combine it with say Java WebStart for distribution and/or RIO for dynamic provisioning and you have one hell of a powerful distributed computing platform. And, because of the Java sandbox and the new Jini 2.0 security features, on that can be make sharing mobile code relatively safe. Throw in the Jini Surrogate Architecture and perhaps JXTA and you have services that can be accesses by any client in any language....

Sounds intriguing, no?

As for you speed issues, try using the j2sdk 1.4.x (currently 1.4.2_03). Not only to do get peppy speed, but the latest version allows for full screen mode, so yes, you can make screen savers....

I agree with you and there already is a Java sub-culture doing just that - the Jini and JavaSpaces community. Highly distributed, self-healing, self-forming federations of services and distributed shared memory realms. Combine it with say Java WebStart for distribution and/or RIO for dynamic provisioning and you have one hell of a powerful distributed computing platform. And, because of the Java sandbox and the new Jini 2.0 security features, on that can be make sharing mobile code relatively safe. Throw in the Jini Surrogate Architecture and perhaps JXTA and you have services that can be accesses by any client in any language....

Sounds intriguing, no?

As for you speed issues, try using the j2sdk 1.4.x (currently 1.4.2_03). Not only to do get peppy speed, but the latest version allows for full screen mode, so yes, you can make screen savers....

I put together a small team of people I knew who were also interested in the same general thing, and who were all fleeing like lemmings from the boo.com meltdown, and we thrashed out a rough design and worked out a budget and, issues of funding and business admin aside - sheesh startups - we built a bespoke sattelite reinsurance exchange based on cocoon, tomcat, apache server, outrigger and the jini1.0 stuff. we built it in three layers. the first, as the end result was to be a web app, was in retrospect not dissimilar to apache struts but tied cocoon to the javaspace (you can see more detail on this at O'Reilly's OnJava site) and used xsl to render the pages. The little bit of bespoke code we wrote to shuffle objects between cocoon and the space we dubbed Crudlet and declared it to be open source targeted, and registered crudlet.org. The package name was org.crudlet. The next layer provided the generic b2b exchange and negotiation layer. We called it tennis because it represented a series of exchanges across a net. It too provided very generic functions and so was also open source targeted as org.curdlet.tennis as it builds on crudlet. The final layer contains the actual business knowledge - What is an offer of capacity on M$300 worth of Ariane 5 launch. What's the launch schedule for the next few years etc etc. What's a reinsurer? These things all went into a com.risk2risk package that extended the classes in tennis and crudlet and was considered to be proprietary to the company.

We recruited developers from the various OSS projects we used when we could, and made ot very clear to new recurits how the code layers were structured. We also got complete approval from the Board of Directors to pursue this strategy. The fact that I was one of three like-minded technical directors also helped of course. But we were well outnumbered by the suits who were very sceptical at first. A further project grew out of the team - a kind of javasapce backed version of hibernate or castor - called javastore but it never really went anywhere.

Much of what we open sourced was rapidly superceeded by things like Struts and Hibernate and Karajan (which grew out of crudlet) and when the whole reinsurance industry melted down post Sept 11 2001 and the whole project was put on ice by the investors, the only code that was really iced was the proprietary layer. The developers showed incredible loyalty, committing bug fixes on their very last day of work that kind of thing, and I still keep in touch with many of them.

The business arguments were all around costs. OSS == cheaper. Developers will work for less if they get to keep their code after the project is done. Developers can be excited by things other than money. As long as the basic rate is comfortable for them, and that's always a subjective matter. Sure there are other good reasons for OSS, security, corporate tranparancy and accounability, due dilligence etc, but the bottom line with investors is always the bottom line. Anything else is just woolly for most of these people. Also the ethos of open source permeated the team - everyone worked on the inside of a huge oval shaped ring of desks. lots of power mac g4s running osx, a nice rack with some great hardware in it, a groovy office in soho, cvs servers, a network admin who loved his job. and everyone being paid to write code 90% of which they would get to keep afterwards.

So not true. That was a demo - not actual functionality. Rendezvous does not 'just work'; try it sometime. If you have a split network (ie some people on wifi and some on ethernet for example, or as is the case here, my mac is on wifi to the neighbour and shares a network out to the rest of the house via ethernet - naughty but nice!) and even iConquer games can't automagically see each other on my network. I have seen iChats fail to see each other in a similar set up. It's a great idea and i'm sure will get there soon, but it is not really there now.

Want to change your printer configuration wirelessly? Apple's speedy new Safari browser will let you do that if your printer is Rendezvous-compatible -- without your having to hunt down a specific IP (Internet protocol) address.

why is this specific to Safari? I understood once rendesvous has announced my printer to my mac then anything capable of using the print cener would be able to use that printer. what sarafi does do is list web servers that have announced themselves via rendesvous in the bookmarks list.

As promised last summer, most of the major printer makers have upgraded their machines to support Rendezvous.

no they havn't, they have announced that they will be doing so however.

This routine normally involves wading through dozens of folders in search of the proper IP addresses for our office printers, a confusing process that has resulted in more than one call to the help desk.

I'm sorry but this is just FUD. Sure it can be a pain to get a printer hooked up to some windoze machines, just as it can be a pain to get some printers to talk to the mac. some printers are just rubbish. now getting Linux to talk to a printer - that can be hard work.

Add enough of these simplifications together, and it becomes hard to refute that running an office network using Rendezvous-equipped Macs will end up costing less than comparable Windows software -- because there really isn't any.

I'm sorry what was that? in proper english sentences this time? was the author paid for this article? do they have any editors working there?

With Windows, you still need a file server and a print server, with Rendezvous and Apple you don't.

riiiight.... - puts pinkie in corner of mouth.

... the software will have the ability to check CPU (central processing unit) usage on other Rendezvous-enabled machines around the office -- and send intensive tasks to the computer currently handling the lightest workload. ... That's a use for Rendezvous no one had thought of before.

no for sure no-one ever thought to distribute computing load seamlessly across a network. no-one. ever. not ever, nope. just never occured to anyone before. idiot.

Apple has even obligingly offered the Rendezvous software in Windows code. In fact, Apple has open-sourced Rendezvous and released source code for versions designed to work on Linux machines as well.

It's called 'written in C' I believe.

If more Rendezvous-enabled pieces of Windows software start hitting the shelves, slowly but surely, Apple will start to break down the obstacles to switching platforms from Bill's boxes to Steve's elegant machines.

aside from the obvious frothing at the mouth editorialising here, i think it is in apple's interests to let other people do the work of making windows and linux software. apple sell computers and software, M$ sell software and video games consols. should apple just offer to rewrite MS office et al for bill?

it's hard to decide if this article is sh1t or fuçking shit.

ps: If you want a list of software that is Rendezvous compatable, check version tracker.

Also:rmi
offers rpc plus the ability to dynamically load code over a netowrk and execute it locally. This is a major advantage over CORBA/SOAP implementations and goes with the platform-portability, you can do some very cool stuff like jini this way.

talk, wall etc were all in non-windowed. xtalk and lots of others were windows. The "unique" element is being able to see who is online before you talk to them.

We used to achieve this by use of the advanced commands

"who" which gave you a list of who was on the server. This refreshed every few minutes (sys admins didn't like the number being too low) then you could just use write. Everyone specified a write terminal and you just used that.

Now when we got TWO servers we had to modify the script to use rwho and unfortunately there wasn't an rwrite (is there now?) which was okay because we got X displays anyway.

So in X you start ONE instance of the application, and when people log-on you send a request to the main server (i.e. you send a special email) which fires up a window on your display. The email contained the name of the person, you could then do lots of things including writing to each other.

Oh and the application was called Emacs and we were trying to do a group project.

Pity we didn't realise that we could patent "Open on New Display".

So if its single server using thin clients then there is lots of prior art, if its multiple applications being aware when new people join there is, for me, and even better one.

Jini is all about joining federations, annoucing you are there, requesting services, starting conversations et al. This is surely proof that it fails the "not obvious" test as someone has written a whole environment that can do, in effect, IM between people, computers, printers, machines, PDAs etc etc etc.

I've now just decided to patent syntax highlighting.

No.

It sounds like Jini to me.

I'm envisioning a unified interface for connecting these various devices...There would also be a need for a standardized, extensible, secure set of protocols for these devices to interact.

Oh, you mean Sun Microsystem's Jini(tm), or how about Microsoft's Universal Plug and Play (tm)?

As for using something other than ethernet for connectivity for consumer electronics, isn't that what Firewire / IEEE1394 was supposed to deliver on? Or, if you're talking about using the existing phone wiring in the home, how about something like this thingee from D-Link?

Now... There are a few examples of tech we have right now , basically. So why aren't we using them more? Various reasons I don't feel like going into, but basically they're being slow to adopt.

Meanwhile, more and more homes are being outfitted with Cable Modem and DSL broadband equipment, which for the most part means ethernet. Which is making it a growing defacto standard for home networking. Many of the things that the hardcore geeks are tinkering with now (home hubs and routers) will be common commodity in a few short years.

So, while there might be something more appropriate for the home than ethernet... I'd rather see internet appliances now with an ethernet module, and maybe the option for a pluggable NewHomeAutomationBusFastNetThing in the future. As for TCP/IP, again there might be something better, but that's what's showing up as the transport of choice in broadband homes across the world.

So again, great blue sky vision. But we have cable modems, DSL, ethernet, and TCP/IP in the home now. Give us more appliances ready for this growing market. (I mean, I don't have to shut off the fridge when I want to use the microwave, why should I have to shut off the IPad when I want to use my Dreamcast online?!)

At University, I am working on a protocol extension to Jini to bring Jini to non-Java capable devices, e.g. embedded CPUs. Back when I began, we thought that we should find a cool hardware device to try the new protocol on. The Axis camera is a great product (I knew from several job-related projects) and it is hands-down the coolest device out there that combines an embedded microcontroller, an ethernet connector and a restricted hardware environment. Perfect to demonstrate my project of native Jini support without the need for a Java Virtual Machine.

October last year, long before I actually started working on my thesis, I requested developer information from Axis about their network camera. It took me four requests to get any response from them in the first place. Finally, after writing a polite complaint to Axis HQ Sweden, I got to an overly enthusiastic marketing drone from Axis Germany.

He told me that my project is a great thing, that Axis was very interested in it and that he would do everything he could do to help me.

He just noted that the formerly close-source firmware of the Axis camera will be changed to a port of the Linux kernel very soon and that I should wait for the new Linux version, due out in November.

"Isn't that great?" he told me "you don't even have to sign an NDA, we will provide you with the complete source of the firmware and one or two free demo units. All you have to do to get the demo units is sign a research agreement with us." I have an email from him lying around somewhere where he confirms this offer.

Oh, you can imagine how happy I was. Just a few weeks to get a demo unit with full firmware source and it's a cool product, too!

Well, weeks passed. Months passed. My contact person was always happy, bright and optimistic when I called him and asked about the progress of the product. No matter when I called him, the camera was due to be released "in two or three weeks" and "yes, you will get your demo unit with firmware source from us."

Strange that one time he asked me specifically not to contact the firmware developers at Axis Sweden before the release of the camera, since is "going to cause problems" for him...

Well, the camera was finally released in late Februar for CeBIT. There, I met an actual developer from Axis Sweden. He had never heard of my continuous requests.

"Interesting. It would have been nice to know this a few months back so that we could have looked into this project during our development." Yeah, but I told Axis about it four months ago.

The bottom line: There will be no freely available firmware source of the camera until "the end of the year". The developers' superiour has no interest in my thesis project, so that even with an NDA I will not be allowed to modify the camera's firmware now. (I could wait another year, but hey, one day I do want to finish University...)

I would have been nice to know this four months ago. Of course, because of the continouing promises and full confirmations by Axis Germany, I did not look into alternative hardware.

Anyway, if you're interested, see http://developer.jini.org:80/exc hange/users/hanno/ for more information about my protocol extension. You'll need a Jini developer account.

------------------

At University, I am working on a protocol extension to Jini to bring Jini to non-Java capable devices, e.g. embedded CPUs. Back when I began, we thought that we should find a cool hardware device to try the new protocol on. The Axis camera is a great product (I knew from several job-related projects) and it is hands-down the coolest device out there that combines an embedded microcontroller, an ethernet connector and a restricted hardware environment. Perfect to demonstrate my project of native Jini support without the need for a Java Virtual Machine.

October last year, long before I actually started working on my thesis, I requested developer information from Axis about their network camera. It took me four requests to get any response from them in the first place. Finally, after writing a polite complaint to Axis HQ Sweden, I got to an overly enthusiastic marketing drone from Axis Germany.

He told me that my project is a great thing, that Axis was very interested in it and that he would do everything he could do to help me.

He just noted that the formerly close-source firmware of the Axis camera will be changed to a port of the Linux kernel very soon and that I should wait for the new Linux version, due out in November.

"Isn't that great?" he told me "you don't even have to sign an NDA, we will provide you with the complete source of the firmware and one or two free demo units. All you have to do to get the demo units is sign a research agreement with us." I have an email from him lying around somewhere where he confirms this offer.

Oh, you can imagine how happy I was. Just a few weeks to get a demo unit with full firmware source and it's a cool product, too!

Well, weeks passed. Months passed. My contact person was always happy, bright and optimistic when I called him and asked about the progress of the product. No matter when I called him, the camera was due to be released "in two or three weeks" and "yes, you will get your demo unit with firmware source from us."

Strange that one time he asked me specifically not to contact the firmware developers at Axis Sweden before the release of the camera, since is "going to cause problems" for him...

Well, the camera was finally released in late Februar for CeBIT. There, I met an actual developer from Axis Sweden. He had never heard of my continuous requests.

"Interesting. It would have been nice to know this a few months back so that we could have looked into this project during our development." Yeah, but I told Axis about it four months ago.

The bottom line: There will be no freely available firmware source of the camera until "the end of the year". The developers' superiour has no interest in my thesis project, so that even with an NDA I will not be allowed to modify the camera's firmware now. (I could wait another year, but hey, one day I do want to finish University...)

I would have been nice to know this four months ago. Of course, because of the continouing promises and full confirmations by Axis Germany, I did not look into alternative hardware.

Anyway, if you're interested, see http://developer.jini.org:80/exc hange/users/hanno/ for more information about my protocol extension. You'll need a Jini developer account.

------------------

It's mostly software now. The only hardware I'm aware of that you can play around with is a Jini interface with X-10 hardware, called Jade. You can find it at jini.org, I think.

I just saw a great talk by Ted Schlien, a partner at Kleiner Perkins Caufield & Byers, a top VC firm which has launched such juggernauts as Sun and Excite. Note that Ted is also on the board of LinuxCare. This was at the Second Jini Community Meeting (www.jini.org) and I believe that his slides will be online in a few days. I don't have my notes with me but I will write down what I can remember:

Ted's advice was very straightforward. First, you e-mail a VC partner a 2-3 page executive summary. If you are then asked for one, you present a business plan. The shorter the business plan, the better. The first meeting will consist of about an hour -- 15-20 slides MAX! -- where you try to sell your idea. He suggested that if the VC asks about what percentage in the company you are willing to sell for VC help, you say something vague like "we'll let the market determine that".

Pitching your idea to multiple VCs is good as you can get them to compete for what percentage of your company they will own -- and of course you should be shopping around for VCs that will actually contribute value to your venture rather than add value. Ted's main point was that firms like KP put a lot of work into helping you launch the company, recruit executives, strategize, and so forth. Other VC firms only "manage portfolios" of companies and may not be there for you if you start to run into trouble.

I wouldn't worry about your idea being stolen in this way. It belongs to you. You can't get VC money unless you can put all of your cards on the table, and I believe that you retain all rights to the IP even after delivering the pitch. It sounds like you are at the perfect stage to approach VCs -- not too far along with your ideas, but not totally green either.

I took the opportunity to ask Ted what he thought of the Linux market, since he's funding LinuxCare. His comment was that Linux looks great for the server market and even better for embedded systems -- but he personally doesn't see it making a lot of impact on the desktop. It's up to us to prove him wrong, of course, but what this means is that there's a lot of good opportunity to push Linux into the server and embedded space. Note also that Ted doesn't think that selling Linux distributions is going to be as important as services based on Linux -- which is what LinuxCare is providing.

Good luck!
Matt Welsh, UC Berkeley

I think it's important to realize what Tim's point is here: that Linux versus Windows versus anybody else isn't the point here. It's all about building an open platform upon which to deploy the next generation of Internet applications.

In ten years, desktop operating systems will be an endangered species. We won't care about GNOME versus KDE, or even Linux versus Windows. We'll be far too busy connecting to the universal information applications with wireless appliances, handhelds, and other "pervasive" forms of computing. Everybody's going to have a different "net widget" in their hands or on their desks. We're already seeing this today -- can't everyone use the Web regardless of whether they use Linux, Windows, or an iMac?

The question is this: In such a heterogeneous computing landscape, how can we deploy services which are universally accessible?

Tim's point is a very good one: That we sure can't get there if everything's closed and proprietary. We need an open platform on which to base the next generation of networked information access. Windows ain't gonna do it. Linux (alone) ain't gonna do it, either. So it's important to chart out the space of platforms which will support the new applications. And Open Source is a fantastic way to ensure that the platform remains open itself.

For those who don't believe it, go read up on some technologies like Jini, Ninja, and e-Speak. The wave is coming.

Matt Welsh

They haven't outright and clear said so yet, but there are very strong hints that they plan to make most, and perhaps eventually, all of their software "community source".

At the JavaOne developer conference recently, this is what Bill Joy said:

• Finally, in order to get all of this to work, we've been searching ever since we started Sun almost 20 years ago now for finding ways to work with you all. The JavaOne conference is an incredible example of a community of people getting together and doing great things. We originally started with the idea of "open systems", which means that we'd publish APIs and sell implementations, but that many people could produce implementations of those APIs.

  Next there's this idea for the Java platform. We tried to create a community and protect it from a predatory company that we were aware of that was likely to try to attack us with contract law, and discovered that contracts sometimes aren't enough to protect us because not everyone thinks they apply to them.

  So what we've decided to do going forward is to try to work from a notion of community. You've seen the Java Community Process (JCP). The JCP allows stakeholders in the different areas, like the people who care about realtime to define the realtime stuff, and that's a really good thing.

  More recently we've done Community Source, which is an attempt to blend the best things about open source and proprietary models together with the added benefit from open source that when you take a Community Source license, you're allowed to make proprietary enhancements to it. We still insist that you leave the APIs open, but you can take large chunks of commercial money and make commercial investments. This works for companies.

  The open source model works for other communities, and for them it's great. But we wanted to come up with a model that would work for traditional companies as well, so that we could quickly move into Community Source as much of our intellectual property as possible, and hopefully all of it going forward. But we insist also that people remain compatible.

  So Community Source has an additional right and an additional responsibility relative to open source. We've done this with a lot of our technology already, including picoJava, and Java and Jini technologies. We'll be doing it with more.

I think they way they're going with Jini is pretty good. They could do better for Java though. They're being kinda closed about what they're going to open though, and have only dropped hints and not made definite statements on their website.

However, some things they have hinted/said are: they will open up Solaris later this year. Also, on one of their Solaris pages they say they'll be making a new version of Solaris (presumably Solaris 8) available under their "easy access" (ie beta) program - they've never done that before. They also seem to be working on making their C/C++ development software and compilers available, and to Linux users as well - to help develop code that works on Linux and Solaris more easily. They've also made other things not mentioned in that article available under their "community source".

They do seem pretty serious about it.