[openspending-dev] Roadmaps and release schedules

Sat Mar 9 17:54:25 UTC 2013

(snipping and reordering)

Slightly shorter email than the previous one, but an important aspect we
need to discuss here as well.

Þann fös 8.mar 2013 17:12, skrifaði Stefan Wehrmeyer:
> We certainly don't have to deploy every day, but if I can't see my code improvements live within a week and instead have to defend the current deployment state to users, I have no motivation to improve our code.

I want to start with this. I see this a strong argument for _not_ having
a rigid release schedule with bi-annual release dates. Like I said in my
last email (the long one) I'm willing to back down and go for a pure
rolling release and I think given the opposition that I can safely say
that we're going for a pure rolling release (continuous deployment).

> The idea of OpenSpending.org is to be the platform you go to if you want to know about budget and money flows. OpenSpending is Open Source software, but it's actually not meant to be set up by individual organisations (unlike e.g. CKAN), because having a central datastore for spending data allows for cross dataset analysis and better insight.

I think this is however not a good argument. Even though the idea is
that OpenSpending is a central datastore that's a matter of providing a
service and not about the software. If we want to make it a software
issue we need to design the software with that in mind, e.g. federation
to allow data to flow between instances but I don't think that's
something we need to focus on (our focus should be about providing a
good service with our datastore - giving people a good reason to use our
instance instead of putting up their own).

The software however is open source and even though people "shouldn't"
install their own instance (which I don't agree with) people should be
able to use stable parts of it and we should try to encourage that by
designing our software in such a way. If our OLAP cube is awesome,
people could use it in other projects and help us make it even awesomer
by adapting it to their needs in their project (we would benefit from it).

Only wanting to have once instance of the software running is not a good
reason for not using proper software development procedures - It's a
limited point of view in my opinion :-)

This is coming from a guy who loves the UNIX philosophy of creating a
program that does one thing and does that thing very well.

/Tryggvi