The Plan

This document is now, for various reasons, out of date. We've had all sorts of interesting problems since we started - some our fault, some not, but all holding us up. Maybe we were too optimistic, who knows? Whatever, though, despite being quite some way behind the timescale envisgaged in this document and not following this as a plan any more, we're still going.

Eventually, this plan will be replaced by something which reflects our current plans. But we'd all rather be working on advancing KOSH than just sitting here talking about advancing KOSH, so don't count on it being too soon! In the absence of any replacement, this document has been left here, though it's mainly of historical interest by now. Feel free to study it, but remember it's no longer current.

At the moment, KOSH is a website, a small group of people with a lot of ideas, energy, vision and commitment, lot of people wishing to support it and offer help and resources, and a dream about a truly innovative future. In order to move forwards, we need to firm out where we want to be in the future. Once we have a picture of that future, we have two ends of a possible path. It then becomes possible to firm out that path. So, our direct future plan sees;
  1. An operating system on a CD
  2. Machines that can run that operating system
  3. Development tools for that operating system
  4. Applications that run on that operating system
  5. Individuals active in the KOSH market
  6. A lively, interactive and vocal community deciding the direction of KOSH
  7. A commercially strong KOSH company promoting and encouraging the community
Points 1 & 2

Designing and developing a new OS and set of machines to run it is no easy task in the best resourced of circumstances. That it can be done has been proved to an extent by the Linux community, although they have been at it for a good few years.

KOSH has to be both realistic and innovative. On the Hardware side, there is a lot of good stuff already out there but there is also a blockage in design innovation due to adherence to a standard architecture. KOSH will address this problem by specifying only a set of hardware specifications. These specifications will have an open end, to allow for HW vendor inspired hardware implementation (standard or custom) and a rigidly defined end, that presents a common set of hardware services to a Hardware Abstraction Layer/ Hardware Services Manager. We hope that KOSH will be able to run on anything, existing and future.

The KOSH OS will ultimately be a virtual OS. As long as it can find a HAL/HSM to which it can dock, then hardware specifics are irrelevant. The docking will be accomplished by a BOSS (Basic OS Services) object. This is the element that will provide the environment in which virtual activity can exist. All application developers will either directly call the BOSS or indirectly call it, through other elements. Applications are thus developed for the OS, not for the underlying hardware. To jumpstart the process, we may just hitch a ride though.

The result of this approach, apart from great flexibility and adaptability, is that we are moving away from gigantic, monolithic releases. With the hardware specification, a developer *can* design a brand new custom system from scratch, but equally, an existing machine could be used. Similarly with the OS, as long as the virtual environment can be sustained, then the OS can be shipped. It thus becomes upto third party developers to populate that environment. The end result is that we should be able to have a sustainable basic system up and running quite quickly for KOSH 1.

Whilst this all sounds great, there are potentially huge problems with trying to design and organise across the net, and by committee. To ensure that we make the best use of resources and the most timely progress, a rigid development plan is being created and will be adhered to in all its aspects. This project will be done in a professional manner. Small working groups of no more than seven, working in parallel to a time defined plan and utilising full peer review protocols will enable us to achieve the seemingly impossible. Each of us though has a responsibility to keep the momentum going, even when we hit the potholes, as we undoubtedly will at some point.

The first phase of the project, will be a requirements definition and initial design. This will tell us whether we have the people, the ideas and the commonality to create KOSH. The deliverables of this phase will be a requirements definition and high level architecture. It will also include a development plan detailing tools and machines to be used for development, and a first phase schedule. This is scheduled to last 3 months from the inception of the Logical Architecture Working Group (a week or so away as of 01 Dec 98).

The second phase of the project is the full design phase. This will see the logical design specification processed and extended, a fleshing out of the principles and logical architecture leading to the creation of firm technical documents and specifications. This period will see the first "real" development activity as prototyping and research is used to solidify the implementation plan. This phase is also scheduled to last 3 months.

The third phase is the implementation or development phase. The technical specs are handed out, coding and unit testing starts, followed by integration to alpha, private beta and public beta testing. On the Hardware side, the completion of the Hardware specifications should enable hardware vendors to begin either retrofitting KOSH to existing machines and designs or designing new machines for KOSH. Hardware templates will be developed by KOSH for licencing out. This phase is scheduled to last 6 months, at the end of which, KOSH 1 should be sitting on a CD awaiting installation and KOSH machines should be either ready or nearing completion.

Points 3, 4, & 5

Without applications, a platform is nothing but expensive furniture. Back in the home computer days, anyone could develop an application with a bit of intelligence and some free or cheap tools. The increasing "professionalism" of computing in the last ten years has made this an increasinly hard pathh to take. Only in the community platforms has this occured at all, as evidenced by the large amounts of PD and shareware generated. KOSH intends to reverse this trend and ensure that anyone who wants to can develop on KOSH, whether it be children with Visual Logo, hobby coders with BASIC or professionals with C/C++, Java, E, Rebol or any other language.

By being a community platform, KOSH expects people to get involved to see what they want come alive. This is obviously true for the design of KOSH, which will provide full documentation and tutorials as well as conforming to a minimalist environment design, which encourages an ecology of applications and objects to populate it. Less obviously, the tools for development need to be developed. The innovative nature of KOSH is screaming out for an equally as innovative set of design, development and testing tools. True virtual engineers manipulating components in a foundry or workshop. Again, the community has to get involved.

It can play its part by developing and promoting a unique support package. It will be unique because the very developers who need to use it will be the ones that design it. No one knows what support they need better than the people who do need it. By being actively able to participate in and construct the developer support program, they can guarantee that they will get what they require.

Writing an application is a time consuming and expensive task. Traditional application development cycles call for monolithic, infrequent projects, a period of high return, declining rapidly as development costs rise for the next release. KOSH allows this model to be broken by promoting an object sea ecology. A developer can create a container within the sea that acts as a home for a set of objects, and then release the objects frequently for a small amount of money each. In this way, the massive efforts of swinging out giant applications are replaced by frequent, continuous development, which provides the developer with a more continuous revenue stream whilst allowing users to buy only the objects that they require, and customise their systems according to their needs and tastes.

Of course, the big issue, especially for commercial developers, is deciding to invest in learning, and outfitting for a new platform. Such investment is risky at the best of times but, with a project such as KOSH, a platform that doesn't exist yet, it is "across the crocodile pond with nitro glycerine on a pogo stick" risky. Commercial developers, as part of the community can only be expected to invest savings and jobs and livelihoods in developing for KOSH if the users, retailers and journalists, the other members of the community, let them know of their support, that they will be hungry for products. Of course this all depends on both sections of the community seeing real progress from the creators and the maintainers. We are all bound together, and if KOSH is to succeed we must all play our part in it.

The plan here is to form a development working group. It's task will be to specify a plan, not a traditional plan for putting manuals online or taking money to get priviledged information, but a plan that opens up the whole area of development for the platform. KOSH is not a traditional platform - it doesn't want traditional solutions.

In addition, because of its community nature, KOSH offers a unique opportunity to build new economic models. Instead of the rigid producer/consumer model, KOSH's reliance upon community allows for developers and users to work together. Developers don't have to guess what users want and risk putting out a product that bombs. Users don't have to risk $50 on a product that may turn out to be useless to them. The object sea model allows for frequent releases and intimate relationships. It also allows for the true development of the subscription model, where users get involved and pay a certain amount a month or year for a certain set or number of objects. A working group will be formed to investigate all these possible ways, and to help strengthen, and at the same time, break down the bonds between the different groupings in the community.

Point 6

Many people have said they don't like the name KOSH. However, an analysis of it will reveal that is it the perfect name. It defines the three parts of the platform and puts the most important part in front; the K for community. :)

Comunities arise when a platform offers something more than just computing. When it offers challenges, when it empowers, when it encourages discussion and debate, when what is put into it makes it more than just another product, just another customer base and revenue stream.

In return community offers the most valuable resource possible; itself. The best usability lab, the best support structure, the best brain storming group, the best evangelists. Traditional companies pay consultancies millions of dollars to provide these services but a community that is honoured and cherished provides them as part of its input into the platform.

For KOSH, the community IS the platform. The OS and Hardware are just tools that allow the community to be, to express itself, to develop, communicate, show off, play and advance forwards. KOSH helps to build them as they help to build KOSH. A lively, vibrant community can only be built by lively, vibrant people getting involved, giving time, stepping forwards and building that community. For those who believe in the ideals and the aims of KOSH, please get involved. The adventure will be truly worth it and in ten years time, hopefully you will be able to look back and say to people, I am KOSH, I helped make that become real.

The plan for the community is open ended because the community must write the plan. Mailing lists and IRC channels are one thing, the Monthly K is another. There are many more. Until the platform is built, it seems strange to have a community but this is the most important time, because getting involved now in the formative stage of the platform means a person can have direct influence in the future, at whatever level.

Point 7

KOSH needs to be a commercial entity in order to provide full protection to its IP and product line. These are very important points. KOSH will generate IP through the actions of its members. Although we are still in discussion, the ownership of that IP needs to be equally shared between KOSH, the entity and those who create it, whether it be individuals or all the members of a Working Group. In doing this, KOSH benefits from having free use of that IP and the individuals benefit in being able to licence that IP to others and make money for their own efforts. How ownership of IP created will be determined is a point being discussed at the moment.