SisterProjectPages
Recently, the following message was posted to the jos-general mailing list by IainS.
The World According to Iain...
In the interest of expediting things I'll put out the "World according
to Iain" as a strawman proposal. Just my take on the situation, layout a
possible action plan, and give us something to poke at.
- Note 1: I'm only going to send this via email as my net connection is a bit limited right now. If someone wants to plaster this into the Wiki somewhere that would be great too.
- Note 2: "expedite" as I feel time is of the essence. The school year is about to begin (I've been out of school for a mere year so my body still feels the "back to school" pull... and I've been out shopping and saw all the back to school sales.) In addition, despite our very limited numbers, we have managed to lose two more members, Jack D. Unrue and Phillip Gonia in the past week and had several others that have come in and then faded just during this current discussion (Warner for example).
- (as for my original "vote" question, the question boils down to, should we follow this plan or another one?)
OK. Here's my take:
Re-organize JOS
We should re-organize. I've never been that fond of the JOS name or the JOS organizational structure so my proposal is:
Action Items
- Cede control of
JOS.org and related resources (mailing lists, website, sourceforge project, etc) to Gilbert who will continue the JOS.org effort as a Java Operating System research and collaboration project. The new jos effort can join JOS.org as a "sister project" but will be run independently similarly to Jext (www.jext.org). individuals are welcome to participate in either or both projects.
- Form a new project focused very clearly on creating a Java-based/focused os. New name, new focus, new resources, same basic people. This is a "fresh start" that gives us the freedom to quickly recast the project as we see fit.
New jos Organization (NJO)
I'm a pragmatic Open Source advocate. I don't see source code access as
fundamental right like the freedom of speech. I believe there are
situations where open source benefits everyone (and also situations
where this is not true). I believe in openness in research and academic
pursuits. I believe in open collaboration. I believe people should get
paid for their work and that you have the right to charge for software.
I believe that code contributors should share in profits produced using
their work. For this new organization I propose:
License
Binaries produced by NJO are available at no-cost for download and
minimal fee for CD's.
Core source is covered under a modified SCSL (see www.sun.com).
Modifications are made simply to reassign the license to NJO rather than
Sun. Research/academic use is free. Internal commercial usage requires
passing compatibility tests. Commercial products or redistribution
requires compatibility testing and a commercial license (if you make
money, NJO gets some of it).
Non-strategic source is released under a BSD license... essentially
public domain with a disclaimer. This would particularly cover useful
tools and utilities.
I realize this is going to be highly controversial and unpalatable to
GPL fanatics. My primary reasoning is:
- Allows us to negotiate licenses with other organizations. In particular, I propose using SCSL code (the kvm and libraries) to bootstrap our development. In the future we may be able to create our own version of both the vm and libraries. But the first "ugly and quick" versions will be much faster to produce if we use the Sun code. Also opens the possibility of using a commercial kernel... QNX being a strong contender in my mind.
- fits with my philosophy as a "pragmatic open source advocate"
- provides possibility of hiring developers to work on NJO full time
Organization
NJO needs to form a company to manage the commercial license. I would be willing to do this. In this case, it would be a CA, USA company. Technical decisions are made using an Apache model. Business decisions are made as they do in coops (consensus voting amongst "members" who are either investors or "sweat equity" owners). A "business manager" CEO makes day to day business decisions and voting is monthly on "significant issues" along with full disclosure of operations (financials, etc). Eventually we transition to a Sun/Java Community Process model.
Product/Focus
NJO needs an extremely clear and easy to execute product focus to succeed. To maximize the chance of success, exploit the current "hot topic" in Java development, and create a very interesting design, I
think NJO os v. 1.0 should be:
- J2ME CLDC MIDP compliant
- runs on x86 (386+)
- VGA (640x480) 16 color micro-gui
- ne2000 ethernet networking
- keyboard and mouse support.
If we have time I'd also like to add PPP modem support. Essentially it will work like a PalmOS written in Java for a PC. The system would be built with:
- Microkernel - picoBSD (stripped down FreeBSD www.freebsd.org) or QNX (www.qnx.com). Essentially boot up and provides the C libraries to run the kvm... also nice to have a kernel tcpip stack so we can avoid writing the tcpip stack for the kvm. BSD is nice because the license is extremely flexible, their code is clean, and their stuff is FAST. QNX is a nice commercial RTOS that developers can download and use for free. QNX will really accelerate our development but when we decide to distribute it, it is going to cost us (at least one developer seat at ~$5000 and a distribution license... less than $1/unit at high volume). It may be easiest to bootstrap and only internally release for "research purposes" a 1.0 using QNX then a 2.0 public release using a custom microkernel (picobsd or our own custom kernel... I'm really attracted to the 32 kernel described in the book, Build your own 32-bit OS by burgess).
- kvm - J2ME CLDC KVM. We use the Sun SCSL'd kvm and libraries and port them to our microkernel. The port is trivial as the KVM is relatively simple and requires very little from the microkernel (threading is done in the kvm not the os).
- CLDC MIDP libraries - We use the Sun SCSL'd libraries.
- NJO GUI libraries - Custom libraries that implement the MIDP graphics libraries for our particular platform (vga). For BSD this is going to have be some native graphics library (Xwindows seems way too much overkill for this). For QNX we use their excellent neutrino GUI.
- NJO drivers - Hard coded drivers for standard ibm vga video, ne2000 ethernet, keyboard, mouse. Whatever the underlying microkernel offers here is what we'll use.
- NJO desktop - a pure Java desktop app to handle MIDP midlet installations, manage applications, provide the user operating environment, etc.
Action items
Obviously discuss and decide on each of the major issues (organization,
licensing, product focus). Unless someone has a real strong opinion on
any particular issue we can tackle them in this order:
- Decide to split off separate NJO (I don't think this proposal is appropriate under JOS)
- Decide on NJO organization (license + biz org)
- Decide on product focus (overall platform)
- Decide on 1.0 implementation details (picoBSD vs QNX vs etc)
- Form organization, start development.
Obviously this is a pretty radical departure from the current JOS status
quo. I expect people to have some strong reactions and hopefully good
feedback. Blast away. :)
- IainS
It seems to me you are suggesting a view similar to GilbertsProjectGoalDiscussion for JOS, but that you are also proposing an implementation project.
This leads me to think that JOS needs to more clearly define sub/sister projects, I don't see a specific NJO project as counter to a broader picture of JOS.
On the implementation project I suspect that I disagree with a number of
points. I think:
- picoBSD is too big
- QNX's license is too restrictive
- both are too narrowly ported
- Redhat's eCos is a much beter choice (includes Linux user mode HAL)
- add serial port support (debugging !)
Now the question is why is this project interesting ?
I think your project was too middle-of-the-road to be interesting. I agree it needs to be small, to be focussed, to do something sort of novel.
Perhaps it should target a Palm Pilot ?
- Palm makes a reasonable simulator available
- the ucLinux people have documented lots
- the lack of a VMM is irrelevant to Java
- the hardware device list is small and fixed
- the GUI must be simple.
- Dragonball is a nice, simple architecture (x86 is not)
- JonT
Reference
|
Content of these pages are owned and copyrighted by the poster.
|
|
Hosted by:
|
|