The people at the Habari Project have recently released version 0.4 of Habari. If you don’t usually read my blog, then you might not know that I help write this software and that the software is what runs this site.
Following up on the 0.4 release, I wrote a kind of “manifesto” for what we need to accomplish for Habari 0.5, and then I read the whole thing into the computer so that you could just listen to it. Lucky you, fun for me. Enjoy.
Here’s a copy of my original post for your convenience:
Greetings Habari Developers!
This week we finally released Habari 0.4! Congratulations to everyone involved in the process! It’s been a lot of hard work and a lot of improvements have been added. I’m really excited by what we’ve been able to accomplish and am looking forward to what we will do next, which is the main reason for my writing today.
As you may know, we’re gearing up for a couple of interesting things in the coming months: PodCamp Ohio and Google’s Summer of Code (SoC).
As a short mention regarding SoC, we have reason to believe that Google will start to release information on the this year’s project in the coming week. I would like very much for Habari to be one of the participating open source projects this year. We have an amazing, sharing, welcoming community and an obvious desire and ability to bring more people into our project.
I’d like to be prepared to present Google and potential students with a list of viable ideas for our project. If anyone has any particular suggestions, please voice them to the list.
Now on to more pressing matters…
PodCamp Ohio seems like a strange milestone for Habari, but I think it represents our first step into moving Habari into the net consciousness as a mainstream blogging application.
To really make Habari ready for PodCamp Ohio, I see four requirements we must achieve and release as 0.5 before June 28th:
#1/4: We must adequately support podcasting. Podcasting has been in our to-do list since before most people knew Habari existed, and we haven’t really done much to achieve this goal so far, but this item is absolutely essential if we intend to convince podcasters that Habari is useful to them at June’s event.
Primarily, Habari needs to allow the creation of new posts that are “Podcast episodes” and contain any data that a podcast requires beyond standard post data – Like audio files.
We need to choose target client applications of podcasts and verify that they work with Habari’s feed output. For example, we would be missing our target completely if we did not successfully allow an author to publish a feed that was readable by iTunes Music Store.
We need to make it easier to publish podcast audio than other blog software. To do this we should refine and connect the media silos to the posting interface and make sure it is possible to do this with a new content type - a podcast. As an added bonus, we could attempt to enable some interface for recording and saving podcasts to silos directly from our UI.
We’re already gold sponsors of PodCamp Ohio, and as thanks for all of the monetary contributions people gave to make that happen, I think we need to make the best impression on the people whose attention that money buys.
#2/4: We must produce a plugin and theme directory. This is adjacent to our need to make Habari itself presentable, simply because the first question that anyone asks these days after hearing that Habari is new blog software is, “What themes/plugins does it have?” We need to say, “They are available here from this central location.”
My vision (which is completely malleable, but I present it so that we have a starting point for quick discussion) is that we use the Habari instance already installed at habariproject.org to house the directories. We would add two custom content types, one each for plugins and themes, and allow developers and themers to add their own content to the system.
To make this a reality, we need to finish the permissions system. There needs to be a way to give out free access to the Habari instance on habariproject.org without giving every user account access to all of that installation’s features.
Also, we will need to consider what data we want to store about plugins and themes, build the content types to house that data, create templates that display the data in a useful way, and allow visitors to obtain the things we list in the directory. The directory should also be responsible for automatically controlling the update beacon for new plugin and theme releases. I do not want to delay the directory functionality for a better design for the hp.o website, but if a better design suddenly appears that incorporates the directory, that would be fine by me.
#3/4: We must revise the admin theme and provide additional in-core themes for use. This goes directly to making Habari presentable to a group of people we’re trying to convince to use it. The second question people ask when they hear you have new blog software is, “Can I see it?” I’m anxious to have something beautiful to show them.
There was little talk here on the mailing list of Mike’s Monolith design, although there was plenty of admiration at his site. I know that while there are many people who are in awe of his design, there are some folks with objections to it, specifically in that it is “not here”. I suggest that, as Chris Davis recommends to me, we do everything in our power to bring Mike “in” with his design so that he can benefit as part of our community and we can benefit from his design expertise. What the next step to affect that is, I don’t know.
I think this item is probably the most challenging on this four-item list, not because of the technical requirements to accomplish it, but because a lot of people are going to have to compromise in places they have been steadfast on and cooperate without the previously demonstrated animosity if we ever hope to see this happen.
Regardless of the admin, we also need to consider k2. k2 is a great theme, but many people associate it to WordPress. It would be ideal if Habari also had it’s own signature theme to face the world. For that reason, I want to start the selection and revision process for at least two themes to include as part of the core distribution.
I have mentioned on IRC that my shortlist of three consists of Charcoal, RedArry, and Mzingi. I am open to other suggestions or new submissions. Any accepted theme will need to be vetted for licensing and be code-complete. We might also develop a minimal “training theme” that is both simple and saturated with code comments and links to documentation. We should do our best to include at least one theme demonstrating functionality that you can only do with Habari so that when our themes are appropriated for Wordpress.com like Garland was, we can still offer a home-field advantage.
#4/4: We must update and organize our documentation to be as useful to end-users as possible. We need to pull together to document the things that are missing from the code documentation we already have, and to organize the documentation into a structure that makes it easy to find what you’re looking for and to place new items.
An idea has been floated on IRC lately about doing a “wiki week”. I think this is a great idea, provided that we’re able to pre-organize a structure for new documentation to be in, or use part of the week to arrange that. I have no desire to see the Habari wiki turn into a quagmire of duplicated information with vast expanses of things that are missing.
It is our responsibility to our users to see that the wiki is complete and the documentation that ships with Habari is culled from the top-tier of wiki writings.
The above four items above are huge. Nonetheless, I think that we can accomplish all of them before June, and throw a few other goodies in to boot. If we work together toward these goals, I have no doubt that the people at PodCamp Ohio will be stunned with what Habari can do, and we’ll ultimately succeed in positively expanding our community and improving our project.
Thanks for reading. I look forward to your replies.
