OpenWack Community Software Blog

Yes. We promised it to come much earlier and even now it doesn’t come in full. Namely we have a fully functional sneak peek for you.

OpenWack 1.0 platform is available for preview and testing at Xitti Adult Social Network Builder. Xitti is the adult version of WackWall and both services will be powered by OpenWack platform in terms of SaaS.

Currently we are fixing all those minor shortcomings you will inevitably encounter and working on new features for real, downloadable release in Spring ‘10. You might also notice that this release introduces only one theme, although fully customizable with CSS, graphics and comprehensive customization controls. Other themes are on their way.

This release comes as the public beta and we would like you to test it and weigh in with your opinion and feedback. Suggestions are welcome here.

Look who’s round the corner? OpenWack dev team with that fire of determination in the eyes!

Starting from today we will be doing a series of dev marathons — a well known way of developing software in Skalfa — meaning creating multi-hour chunks of time for the programmers with zero distractions from writing software. You know how it’s done — when a team of bright people works on one big task in the chaotic zen environment. I’m so glad that in the 5-year old company we still like to get our hands dirty and to act startup.

This means that we are seeing that red finish line on the horizon. We have agreed on all essential nodes architecture and implemented the skeleton so everyone in the team gets down to the hard work of building out details. We make 5-minute briefings every hour or so to stay in touch, correct the course, and swim further rapidly.

You want details? We have them for you!

Starting from this very minute we’ll be giving real-time Twitter updates as to what what’s going on in our SVN. We are not by far setting dates for betas or RCs but this stuff will be interesting for dev-savvy users. Read our updates here: Twitter.com/OpenWack.

P.S. No, this is not our team on the picture, calm down.

We’ve been on a stern schedule of writing end-user features for OpenWack and finishing core parts, and some time ago we realized that we are not going to meet that summer 2009 availability promise which I apologize for. Even this apology came a little late but I believe for good.

OpenWack will be available for free download in winter ‘09-10.

We decided to first test the new platform on our own projects (read WackWall and the family). This will let us debug it to death, get details straight, and add all plan-minimum features.

For OpenWack we will also develop all necessary infrastructure for plugin developers, theme designers and users before putting it for download.

This way we want to release something already capable of helping people accomplish their goals. It will save a lot of precious time for users and developers. Once you rely on the platform you don’t need to completely rewrite (or abandon) your efforts. To make it possible we’re gonna take all the real-life fire ourselves first.

We have seen companies releasing half-assed software. Then debug it for months/years or releasing new versions with completely changed APIs to make everyone adopt. Somebody calls that the only proper way to develop software. But we are the crowd that never opts for the obvious.

We will test the software on paid projects before open-sourcing it.

We’ve “been there, done that” before. All OpenWack is about is putting our industry and business logic experience from other projects into the most efficient technical form possible. The one that we’ve been crafting for 7 years. The mere fact that all future Skalfa products will be based on this platform makes us work really hard to show the world something that can be relied on during the whole lifetime of a community project.

Watch news, and watch WackWall update in October.

Yes, our devheads promised not to sleep and eat until the first OpenWack community software alpha is put for testing. However that doesn’t stop us from building community around it.

Thanks for suggestions that you put on our suggestions board: http://openwack.uservoice.com. When we have the first round of obviously must-have social features developed, tested and shipped, we’ll get down right to what you think is important.

Now we have also set up our Facebook group. You are invited to join, chat with us, ask questions and track the progress.

Of course we are also planning to create official user and developer communities some time later but Facebook group will also exist forever because it will let more potential users know about OpenWack and learn how to use it. Welcome to our community. We need you.

Some update about the progress.

Our work recently consists of sketching features and laying down business and technical specifications for them. We found this as the most effective way to write software. Development (coding) itself is a rather straighforward and quick process when you have specifications and exact user interfaces for your work.

Anyways, this critical part of the product development is consuming more time than we originally estimated. This is primarily because we have insight in the business logic (thanks to our 5 year experience with SkaDate) and a lot of system components and classes are being laid down before any actual features.

Of course we could go the startup way – build underfeatured and shortsighted version 1.0 quickly and see how people react to it. In our case we’ve got substantial experience of building community sites for people so we have a great idea of what it takes. Specifically we project the software having in mind anything that will be necessary later. This approach is more consistent and is only possible when you have exhausting business logic details.

As for coding we are building languages and profile questions business layers and user interfaces.

What’s coming?
First of all we agreed to write full specifications for the current WackWall functionality so we can relaunch it and continue to quickly add functionality. Together with that we will start building infrastructure for OpenWack.org and put the software for download some time later. At this point I can’t provide any dates. We try not to make ourselves hurry too much.

We had an uneasy feeling that we ought to support IE6 for the default theme of OpenWack – the one that will be bundled with the basic distro and will always be used for admin area. But then we decided to look at WackWall stats. If a million pageviews a month is any indication we found out that IE6 is used by less than 8% of visitors on WackWall social networks. So we decided to join the camp of those designers who prefer to ignore IE6 and its incurable problems.

Internet Explorer 6, an ugly creature – you can wrap up in a white shroud and crawl to the graveyard where you belong. The reason you are still undead is another big Microsoft failure – Windows Vista. If people did not snatch at their non-upgraded Windows XP copies IE6 would be long gone.

I think IE6 problems are well-documented on the web by designers so I’ll spare you the rhetoric. Default theme for OpenWack will not support IE6.

While development we use technical specifications for writing code with schemas, drawings, sketches and text. Tomorrow we start laying down proper documentation based on the references we use ourselves.

We realize that some things change right on the road and we will have to rewrite some parts together with the code but the absolute majority of this material is going to stay there. We want to keep this process running along the development because of 2 reasons:

1) It’s just much easier to contribute to documentation writing in small parts using our own references and putting for you what have been magically turned into working code. So it’s not like a damned abyss of work to write the whole thing when the fun part (development) is done.

2) You will have complete reference in the end because it’s being forged right on the dev assembly line and covers particularly anything that is being actually developed.

We understand that nobody wants to read manuals and that is why we will do everything to make it not critical for you to start using/developing for OpenWack. On the other hand, any open source project needs to have sufficient technical reference and manuals to attract rock-star plugin developers. Who is going to dedicate their time to your project if you can’t even describe it properly? We are definitely determined to avoid this question. ;)

Update: We have set up documentation wiki here: docs.openwack.org. This is what will be used by the development team and later by plugin developers and theme designers. Watch it getting filled with the documentation, references, specifications and howtos.

It’s been one month since we mentioned something called “OpenWack 0.0000002314″. Today I’m happy to say we are working with OpenWack v.0.00001. The idea is the less zeros we have after the comma in version number the closer you are to grabbing v0.1 – the initial public OpenWack release scheduled for summer.

At this point we have DB structure and interfaces, theme engine, forms engine, and a rudimentary plugin system. Currently the developers finish database interfaces, DAOs and DTOs; interfaces designers lay out default theme (that will always be used in admin area).

Some time this week we will move on to tangible functionality – admin pages and forms. It’s exciting to see the dev process iterate to the funny and actual stuff. Especially since we declared our commitment to create something good. We may have some sneak peek screenshots for you down the road.

Watch news!

Everyone of you saw those fancy labels on sites and software products indicating that the page markup passed W3C validation.

Hereby I claim that W3C validation will not be the priority of OpenWack pages markup nor will it ever be a requirement for OpenWack themes and plugins.

W3C standards were introduced with a good idea of validating HTML and CSS to be supported by all generally available browsers. But the reality is that they bring unnecessary restrictions and do not guarantee anything.

For example, putting block elements in <a> will not validate. Tag <object> (for a flash video player e.g.) will not validate. Although both those examples are handled fine by all relevant web-browsers of today. Why restrict then? These are examples of XHTML Transitional, I’m not even speaking of XHTML Strict.

On the other hand you can write W3C compliant code but there’s no guarantee that it will work in IE7 or (oh god) in IE6. It’s absolutely necessary to test your code in these browsers and even write some CSS hacks to handle their misbehavior. Microsoft did a great job of creating this mess.

I understand why software like Adobe Dreamweaver will generate W3C-compliant markup at all costs. This is marketing and is aimed at people who know what W3C validation is but are not aware of its failure. So realistically for now these are just labels. And they significantly contributed to the wide adoption of the standards that fail to bring the order.

We will try to maintain those standards wherever reasonable but not for the sole purpose of staying compliant with them. Given the mentioned shortcomings we do not see big reasons to comply.

There’s a much more effective practice of just testing all your markup in all major browsers people use. That’s the only relevant validation you can get to write software aimed at providing adequate user experience.

During the first months of planning and development we’ve elaborated the detailed picture of our goals with the OpenWack product and what it will try to achieve in the Web. I tried to formulate a short description of the main points that you can now read, evaluate and ask questions about.

We welcome any feedback on how our mission speaks to you and what we can do to serve your needs better.

OpenWack Mission Statement