[openspending-dev] Modularisation

Sat Mar 9 21:55:50 UTC 2013

Moving to a new discussion thread since I feel this is will be a big,
long and an important discussion.

Þann lau 9.mar 2013 20:46, skrifaði Friedrich Lindenberg:
> So, you can either take the existing resources and play infrastructure, or
> you can stick with the actual problem: explaining government spending to
> people. Making OS into modules is a nice technical thing to do. Maybe it'll
> even get us a piece of generalised software (it's actually the model
> editor, I think, not the cube itself). But I would argue that modularising
> OS has a fairly low value with regards to achieving that goal. (There's
> going to be a "clean foundations" in the response here, but is shit really
> broken? Do you really think that it'll be easier to get contributors if its
> ten packages, rather than two? Why not solve the "satellite contributors"
> problem first - that's where actual value is added most easily.)

Hi Friedrich! :-)

I'm actually not going to respond with something containing "clean
foundations".

Having a modularised system can actually help us focus on our actual
problem (explaining government spending). Having a big software that
tries to do "all the things!" can actually hurt the project. Even though
we're good there might be others who are interested to add features but
are turned away when they start messing with the code.

Bernhard and Hannes (along with their group) set up their own instance
and have talked about specific Austria-based features. I would like to
see support for these in OpenSpending but they might be turned away by
the fact that the technical platform is too coupled with
openspending.org (I guessing here - Bernhard and Hannes can correct me).
Knowing where to add single-entry bookkeeping support without messing
with a Solr instance on their dev computer can help OpenSpending
development (faster and more agile). In their case they're going to pay
for some development and could divert that dev attention to the
"spending analytical machine (spam?)" and leave things like what does
openspending.content_root in the .ini file do to the people who work on
offenerhaushalt.at

The biggest benefit I see with having a modularised system is that it
makes it easier for us to swap out the modules. What if the python cubes
project is good enough for us? A modularised system would allow us to
drop our homebuilt solution (which is probably better than cubes for our
needs at the moment) and replace it with cubes. We would become
contributors to cubes but active maintenance would be somewhere else
(raising some other issues which are I think easier to deal with than
maintaining things on our own). This would actually help us focus more
on our mission and real problems (although it's always easy to hack
together a working piece of software, maintaining it is difficult -
especially when it's not the core focus of the project).

One of the things I love about open source software is that if you see a
project that doesn't do exactly what you need, you can just contribute
to that project and use it instead of rolling out your own solution.

Things work now so this is not something we do just because. This would
be a long-term goal (put it on our roadmap). I don't even think it would
be finished within the next 6 months ;-)

So not a top priority and we would have to figure out how we want to
modularise the code base (it may not be necessary to divide them into
different projects although I feel that it would be the best).

You haven't really convinced me that it's a bad idea. You've just
convinced me that this may not be a short term goal (and I didn't really
need to be convinced of that since I never thought it was a short-term
goal).

So I don't really see why this couldn't be a direction we'd want to go
in (but just take baby steps to get there). But for such a big decision
though we'd need to agree on it as a community.

Just out of curiosity, what is this "satellite contributors problem" you
mentioned (without wanting to divert this newly created thread)?

/Tryggvi