The OS is currently sitting at version 0.6.6 -- what are some of the major milestones between now and version 1.0? Do you have a roadmap of what needs to be done?
Even though we have a strong vision of where we are going, we have bad experiences with publishing roadmaps. Sadly, many vocal people have difficulty appreciating volunteer work that is being done for them.
We have often explained our vision, like in this interview, but because it is high level and partly deals with the future, we get people accusing us that we are not there yet, or not working on all aspects of it every day.
Lots of details need to be sorted out to get there. And we have to do it with volunteers, who each have their own lives to run as well. Several times over the years we have made detailed lists times of tasks that needed to be done, as a result of requests by people who wanted to know what should be done.
The assumption seems to be that publishing a list results in those tasks getting done. This may be so in a command-and-control organisation that pays employees to carry out assignments, but it does not work that way in a volunteer open source project.
None of those tasks got done, so making the lists was just an extra load on us, keeping us from spending time on doing actual work. What is worse is that malcontents have misused it to claim that nothing was being done.
A rather special type of person is needed to do this work: Someone who is both able to do it and interested in doing it. Such a person typically does not need a list, but understands what needs to be done and just does the work through self-motivation.
Finally, we need to stay flexible. Because we are a long-haul project, and we aim to make the best system we can, we are operating on the bleeding edge of technology.
We need to do the best job of predicting an uncertain future, with an uncertain workforce of volunteers. What we want to achieve, the goals of our vision, is quite clear, but how we plan to do it changes continuously.
We are dependent upon many factors. The plans need to be adjusted when a volunteer stops contributing, when a new volunteer joins, when a third-party project stalls or changes direction, when a new, useful third-party project enters the scene, when manufacturers produce new hardware, when service providers introduce new network services, when we hit a technical problem, when we find out that something was easier than we thought, when someone has a good new idea, when we learn how to do something that was only a concept before, or even when we plan a conference or when we are asked to do an interview.
We realise this brings an amount of uncertainty with it, but this is inherent to the world we live in. Some people want us to freeze our development plan and perhaps focus on copying some existing system, but this was never our goal, as it would eventually lead to a product that is already outdated once we finish it.
The closest thing we currently have to a roadmap is the project description on our About page . A list of details that need to be done grows organically by people reporting issues on our forum. Anyone who is looking for something useful to contribute can pick an issue report that interests him or her and fix or improve the situation.
We used to have a fairly strict roadmap for reaching version 1.0, but its relevance has diminished. We cannot plan very strictly because it is too dependent on what volunteers are willing to contribute.
The most important way to motivate volunteers is to offer them a usable platform. The original plan assumed that we could finish the system while others would work on applications. Failing this, it is now more important to force a breakthrough in application development. Our plan to solve this was always to use the REBOL family of programming languages to develop cross-platform software.
This is necessary to create network software that will work between Syllable Desktop and Syllable Server, and to motivate developers on other systems to write software that will also work on Syllable.
REBOL was invented by Carl Sassenrath, who was previously the chief designer of the influential Amiga Operating System. The language was designed to match and improve operating system development.
We are participating in the development of a new language called Red, which is inspired by REBOL and open source. Red enables incredibly easy portable development and cross-compilation.
Many developers nowadays want to develop on Linux or Mac, but are forced to work on Windows because their co-workers or customers use it.
Red will enable them to cross-develop without any of the setup required by other, complex cross-compilation systems. Red is in its early stages, where it is bootstrapping itself upon a lower level Red/System language, but it already allows Syllable Server to compile command-line programs for Windows and other supported platforms by merely setting a compilation switch.
Next year, it will be possible to compile graphical programs for Windows from Syllable Desktop. Red will also target embedded systems, such as the popular Arduino boards, so Syllable will also be a development workstation for those. We will work to enable as many Red programs as possible to run on Syllable itself.
Other important things that are left to be done include a new installer, support for wireless networking and 3D graphics.
We have taken the complexity out of the installation of our Syllable Server Linux system, but installation is still manual. The Syllable Desktop installer is quite easy, but it is text based, so it makes a primitive impression.
Server needs an installer, and Desktop needs a graphical installer. Support for wireless networking is one of those hard tasks, because it requires new low-level subsystems and porting of a considerable number of drivers, but it is necessary to support mobile systems.
We are making progress with 3D graphics, but making it hardware accelerated is a very difficult task for open source systems. We don't consider it required for releasing Syllable 1.0.
More important for that status on Syllable Desktop are things such as improving the stability of our file system, and properly supporting SATA drives with an AHCI driver.
The lack of this driver can usually be circumvented by changing the disk interface in the BIOS of the computer to legacy mode, but this is a hurdle during installation.
There are other hurdles that also need more support to fix.
On the other hand, these would be no issue if someone wanted to ship devices with Syllable preinstalled. Also, many of these issues do not apply to Syllable Server.