/bin/cult -Rj

This is just my thoughts; obviously we will be incorporating feedback from within Binary Culture and our potential users. If that includes you, please let us know what you think!

My feature list (in no particular order):

• Integrated publishing and knowledgebase with transclusion from/to and tight integration within:
  • Web-facing publishing framework for internal and external publishing of static and mostly-static documents featuring
    • Workflow, versioning, i18n, smart folders or collections, pervasive RSS
  • Multi-author shared knowledge store (wiki)
  • Timelined journal/commenting system for team members (blogs)
• File repository with native & web interface, able to cope elegantly and securely with a distributed architecture
• Remote partner/client/conrtactor file delivery & collection system
• Shared calendar system that links to published material and provides freebusy
• Email with simple yet powerful server-side filtering and cross-platform compatibility
• Contact database
• VPN
• Voice, Video & Text IM
• Bug/issue/task tracking
• Asset tracking
• Accounting & ERP
• CRM

In my next post I’ll be outlining the features that I want to see in the fleshed-out DMC suite but before I do that, it’s important to talk about the general ethos behind our development. This is more bullet points than a coherent argument:

• First-up, we’re dogfooding, which requires that we keep things reasonably usable at all times but it also means that we are going to focus on those areas that we use most internally, at least during the initial development period.
• We intend to release early and to release often, especially during the development and beta process.  Once we have production-ready code, we anticipate forking development into stable and head branches, with stable only receiving bug-fixes and a much more predictable feature upgrade path.
• During the early phase, we are very heavily focussing on getting things working in broad strokes and will almost certainly go down technological dead ends.  In these cases we will attempt to provide a migration path but watch for announcements that we consider the suite ready for testing and that we will be supporting migration issues.
• We value working code over theories.  Although my 5 pillars may be a good basis for the ongoing development of the project, if we have to make a choice between code that works right now and missing the feature, in early versions we will probably include the feature, document the implications and work to resolve them in the drive toward V1.
• It’s collaborative; we are creating a package that helps us to create culture, so we hope to encourage a culture that helps us create good code.  Please give feedback, patches and suggestions as we go.

This topic deserves more than this quick visit but I needed to get that off my chest quickly so that we could move on to the features!

One of the key goals for me of this suite of software is to provide the power of sophisticated group software to small teams with limited resources. By providing a hosted and managed service on a per-user basis, we hope to reduce the barrier to smaller teams and give them a leg-up in the competitive worldwide content creation business.  In this way we are scaling enterprise-grade software down into the reach of smaller groups.  We will also work on configuration simplification that we anticipate will put the suite directly into the hands of medium-sized businesses with achievable administration overheads.

However, as I alluded before, the same software is intended for use at much larger shops, not only as the smaller teams inevitably grow to work on larger projects but through direct adoption by enterprise.

We see this suite as being the most integrated and genuinely useful software of its type in the world and are working to provide enterprise-grade availability, sophistication and utility into the hands of content creators worldwide.

There’s no doubt that this is going to be a very complicated suite of software, with complex interdependencies and configuration requirements.  It’s a sophisticated solution and the administration and maintenance of such a system will require similar sophistication.  However, that has nothing to do with ease-of-use for the content creators who are the ultimate users.   For them, it must be simple to create content, move it around, share it with the appropriate people and edit or update it as required.

Simplicity does not infer a lack of power, although it is often achieved by paring down the base options for an end-user to reduce potential for confusion and then relying on extensions or modules to add these options only when needed (as has famously been achieved with Firefox).  We will aim to achieve a very similar outcome by identifying the absolute core requirements and then having additional modules that expand the offering.

However, the focus is on harmonising the user experience, keeping common UI concepts throughout the suite and requiring minimal configuration to achieve complex goals.  We may use wizards and other configuration tools but the emphasis is on keeping the default configuration useful.

We’re already using V0.1 of our new software bundle on this website as I type so we know that it works… and we know that it currently has some significant issues that need to be sorted before it becomes more widely useful. Using the pre-production versions of the software you create (or in this case, the bundle of specifically-configured software and custom “glue” code we are creating) is called “dog-fooding” because we’re eating our own dog food (using our own bundle) and is good because if we hit a snag we’ll be ideally placed to get it fixed. However, we know that our usage is not going to mesh with our other users’ implementations, or even our usage in 12 months, so we’re trying to make sure that we create software that is as malleable and flexible as possible.

One of the ways we’re working on this is to get a list of requirements from other companies nearby that might consider using the bundle and rolling it out to other early-adoptors as quickly as possible. The sooner we get a wider usage range, the sooner we uncover the problems that might limit us. Also, if you’re on the lookout for this software, please let us know how you want to use it, what features you think are most important and how you would evaluate the package. This feedback is invaluable to us.

By selecting the components of this suite to be best-of-breed, with active extension communities, we support maximum flexiblity because users can take advantage of these communities, multipling our own efforts.

Too many people think of good security as an impregnable fortress.

It’s actually pretty easy to create a nearly perfectly secure computer; just cut all of the cables leading to or from it and encase it in a couple of tons of concrete. It’s not especially useful but it is very secure.

This problem is worse in a modern content business. Creative people are notoriously intolerant of security and will work around almost any system that gets in their way, so it’s especially important that the system be designed in such a way as to work seamlessly with the workflow of the business.

We want the security profile to fully support the complex business relationships that are often found in large content businesses and traditionally have been impossible to securely maintain in smaller shops. External contractors, vendors, clients & partners all want/need to have access at different levels to your network. Perhaps a contractor or vendor just needs to upload a completed asset or download some concepts; this should be managed as a part of a complete security framework that supports this kind of usage. Trusted partners may have the ability to access, perhaps even to contribute, to your knowledgebase; read notes on various aspects of a project, review work that has been done, file or resolve bugs. This type of system is almost a prerequisite for effective outsourcing. When you have simple control over the level and type of access that is provided and it is done in a structured, secure and auditable manner, great productivity benefits are only a few clicks away.

This does not mean that you “open the Kimono” to partners, in fact, entirely the opposite. With a modern security and permissions system in place partners only have access to the information that they are supposed to, instead of using whatever horrible kludges and workarounds are in place at the moment, unaudited, not even verified and probably not authorised.

Stability and predictability of core software cannot be overestimated. Although it’s often tempting to use the latest versions of new software packages, unless a new feature is an absolute requirement, we recommend against it. Much better to wait until the package has been tested and found to be stable and the community of practice has evolved around it. Support can go a long way to making software stable and predictable, so we will be actively supporting the this project and our active users. As I alluded to earlier, we’ll have a range of support options available ourselves plus will be encouraging the community to work together on several fronts.

There is no panacea and we will have to work hard at ensuring our codebase and processes remain stable, resiliant and well supported.

The new Media Software Core will clearly be an ongoing effort to incorporate best practice and new technology but there are five pillars of our success in this endeavour;

• Stability
• Security
• Flexibility
• Simplicity
• Scalability

All of these issues are critical; the software must be rock solid because it is the very heart of our users’ businesses. It must (always) have no exploitable bugs and be highly secure while allowing powerful interactions and enabling users. We cannot imagine all of the ways that games and digital media companies will want or need to use the software so it must be sufficiently flexible that they can make it work for them. It must be simple to use and “just work” without the UI or usability concepts getting in the way. Finally, the software must be cheap and able to run reasonably with modest hardware and low overhead for small groups yet also scale up to support large companies with studios in several cities.

None of this is easy and we all know that it will be a journey not a destination, yet it’s important that these five pillars remain uppermost in our minds as development continues.

So, Binary Culture’s Core Software project is to create a software bundle that is best of breed in every area, that is integrated tightly into a unified, easy-to-use whole. This will be developed and published in a transparent manner (probably GPL & CC Attribution Required but we’ll sort that out later) and the objective is to provide a turnkey product but this will be a sophisticated package and will require sophisticated IT management, so we will also be offering a management package to assist companies that want to use it. Of course, we are also happy to work with users on a consultative basis to incorporate various functional or aesthetic requirements.

I’ll be posting here with some initial ideas of requirements and starting points over the next few days.

Binary Culture’s mission to facilitate excellence in digital media development must include a focus on infrastructure and within that broad term, I see a very real need to develop a easy-to-run package of that core software infrastructure necessary for a modern content business. Email, IM, Wiki, Shared Calendar, Task Tracking; the software that enables a shared knowledge space and keeps everyone in a group working toward the same goal.

From our previous analysis we know that existing groupware products do not solve these problems in a best-of-breed manner that provides the customisable, flexible and cross-platform manner that is required. So we will instead create a bundle of cheap, easy-to-use software that we can make available to the community and stand behind as a reliable production-ready system.

You can read more about my thoughts on this project by tracking this.