Well, it's done.

No, I don't mean that the project is finished. If only! ;-) The web site for SWAPI is finally in a useful state. There are always things to improve, but the core of the site seems to be ready. Now the hard part begins... actually creating the framework and gathering a community. Can't wait.

Tools to easily create SWAPI

There were several tool requirements for SWAPI. Google stipulated that all projects must be developed in the open. My mentoring organization doesn't have an in-house environment, so I decided to use something simular to my existing project on Java.net. SWAPI is also simular in some ways with SAX, and I want to follow the development pattern they set forth.

I also observed how a wiki for the Atom project helped to document the decisions that led to its design. I like wikis; the way they're organized matches the way I think. (if you can't tell. :-)) MoinMoin seemed to be the easiest to install, confgure, and relatively pretty too. I used the default stylesheet as the base for the SWAPI web site's look and feel.

Finally, all the cool people are blogging about their work, so I should too. :-p Actually, I think there are some concrete advantages to a developer journal. They allow programmers to easily report on their current status and thinking patterns. I also use them to document ideas that I will probably forget in six months (when they're actually needed of course). They are also a good way of receiving community feedback and ideas in different ways from wikis.

Choosing a host for the project

The project needed a fast host with version control, issue tracking, and remove login systems. The host Ourproject.org was chosen to host SWAPI after some debate. There were some configuration errors with the new account, but Ourproject's staff quickly corrected those mistakes. The site is fast and responsive, and the environment is a standard Debian box so it was easy to create a web site while also maintaining security. All in all, they provided the nicest experience.

Several other communities were also considered. Tigris didn't have ssh access, which made it hard to set up a web site. It was also a confusing web site; the documentation was very unhelpful. Eduforge provided access through ssh, but the environment was crippled to only support CVS administration. (You couldn't even make a directory from the shell!) That's too bad because a community started forming around the project there. For that reason, I'm considering keeping SWAPI's Eduforge project page active and synced with the tools at the Ourproject page.

Sourceforge provided a well administered environment; everything just worked. They had the most comprehensive documentation too. However, the Sourceforge platform itself is not open source. That is kinda weird, which prompted my investigation into other organizations using an open source client (namely Gforge). Also, their severs were quite slow and the the shell environment prevented external web access. While I understand the reasons, this was quite a problem since my connection to the internet is very slow - averaging 36kps!

My previous bad experience with SourceForge also made me shy about using them again. (It took over a month to get an earlier project approved, yet it was canceled after a few weeks of inactivity.) Finally Sourceforge is really really ugly! Not that I'm Leonardo Di Vinci of course. ;-) A shame since they certainly have the largest community around. ::shrug::

Beyond 2000

The next step on the agenda is to aggregate all of the various API standards flying around the RDF community. There have already been some work on documenting the various applications, so I don't think it would take long. I also plan on documenting the initial ideas for the project's design. There are several directions I investigated during the last six months. They need to be digitized and properly documented. Finally, I also have to promote the project, something I'm very poor at.

There are just enough back-end tools becoming mature that application development is becoming really exciting. The use cases for the semantic web are starting to be implemented. However, the existing tools are still few and young enough - entering their first or second version - that the direction the community is moving toward can be easily inferred. That's one reason I feel it's an ideal time to create a standard interface.

Later.