Built for obsolescence

When we started working on Pokko we identified two interesting facts that have stuck with us through the process we have undertaken.

What we have built is out of date.

By the time that we reach our goal of releasing our shiny new toy it will already be out of date. Someone else will have a product like ours that has features that ours doesn't.

This means that we will constantly be striving for betterness. We will never stop tweaking, updating, changing, enhancing, advancing our Pokko.

It might sound a bit disheartening, but we like to see it in another light.

We will never be finished.

The previous realisation lead us to another similar understanding - our job is never done.

You - our dear users - will always want more, and lucky for you - we will never stop wanting to give you more.

We promise to listen to our users, keep a close eye on the market and adapt, shift, change as needed to make sure Pokko is always fit for purpose.

People are inherently change-averse.

Change can be good, but the wrong kind of change can be annoying and obstructive.

The approach we will be taking when it comes to delivering changes will include a lot more community involvement.

We will be constantly pushing out bug fixes, slight tweaks and minor enhancements. There will be CHANGELOG publicly available so you can keep up to date if you wish.

But when it comes to larger changes that have a serious impact on how the system works - both for content creators (marketers, authors, etc...) and content consumers (developers, API integrations, ...) we will give fair notice to ensure everyone has enough time to act. Obviously we will do our absolute best to ensure that our enhancements have no impact on preexisting systems, but sometimes, if the reward is big enough, the risk needs to be taken. In these cases we will offer as much support as you need to make any necessary changes.

If there are features we're seeing a lot of requests for from our user-base we will take the "RFC" (request for comment) approach. We will document to the best of our understanding what the issue is and then offer our intended approach for implementing. This will be published on our forum where the community can give their thoughts. Once we feel that we have a clear grasp, and that the community understands clearly, we will go about implementing the feature. Possibly rolling it out to a small group first.