Domain specific language (DSL)

[David Bovill]

On 17 October 2010 09:45, Michael Allan <mike at zelea.com> wrote:

>
> It looks your plan is:
>
>  1. Remove Votorola from the current open, distributed architecture,
>    or network of hosts, in which it is being prototyped;
>
>  2. Encase it in a Groovy shell; and
>
>  3. Insert it as a component in a newly designed closed, localized, or
>    "vertical" system, running on a single host.
>
> The immediate aim is to deliver on a private venture.  But overall,
> you believe this is "a better strategy" for delivering on the
> "horizontal market" too, meaning the open, distributed system of
> e-democracy in general.  Is that true?
>

Well put! But utterly wrong :)


I'll see if I can lay out the elements and aims of the strategy as clearly
as you have. So:

The primary aims are to:

   1. Further open up the current open distributed architecture of Votorolla
   by making it easier for developers to integrate with their own projects.
   2. Maintain and wherever possible strengthen the federated nature of the
   architecture - ie distributed pollservers
   3. Clarify and enhance the "protocol" aspects of the platform by using
   simple and more standard terminology understood by a wider range of
   developers. (ie Restful web services with explicit API's).
   4. Get the software out there and tested by real groups, through the use
   of plugins for common platforms (WordPress, Drupal, FaceBook, Pligg etc...)

The secondary aims are a bit more philosophical, and involve a strategy
whose fundamental aim is to:

   1. Involve *a greater number of stakeholders* in the co-design of the
   architecture and implementations
   2. Involve a *wider range of stakeholders* in the co-design of the
   architecture and implementations (so not just programmers, but community
   groups, designers, lawyers, architects etc)
   3. *Broaden the relevance* and the appeal of LD by seeing it as a
   relatively small part of a wider agenda of institutional change, which
   includes yes local and national governments, but also how groups work in the
   NGO sector, how scientists work, in fact how any group of people get
   together in an organised fashion to deliver a piece of work in common.

The problems that the proposed strategy is trying to address are:

   1. Over professionalising the development. Currently you need to be a
   Java developer, and have a good grasp of some fairly deep concepts and
   specialised terminology to participate in a practical way in developing the
   code base.
   2. A sole coder. Experience shows that any software project benefits
   hugely by having at least two programmers working together on a code base.
   3. Architecture driven. the project is currently being driven too much by
   an idea, and an architectural vision, and not enough by real world use
   cases. This is not very satisfying for the developer, it does not help to
   develop momentum and users, and it misses out on deeper understandings that
   come from working with users and their problems which in turn end up
   affecting the architecture and not just the GUI. The process should be
   participatory design based, and so needs again "opening up".
   4. Not interdisciplinary enough. It is clear this is a complex domain,
   and the ideal team working on this would be involve a range of skills
   working together to design and shape the project.
   5. No legal structure, making the project vulnerable to private
   organisations, making it harder to involve a wide range of stakeholders, and
   harder to raise resources of time and energy that would help with things
   like user trials.

To achieve the above aims - which all are aimed directly at opening up the
project to common ownership and the input of a wider group of stakeholders,
I think there are four main parts:

   1. Bringing the software onto a shared server and inviting other related
   projects to work in the same virtual space.
   2. Adopting a clear and open legal structure, democratic, and open to all
   participants.
   3. Developing a more intuitive language (DSL), that a range of
   stakeholders can use in order to express and design the type of fluid
   organisational arrangements that they together with their colleagues
   picture.
   4. Use a DSL and standard frameworks to open up the actual coding work of
   the project to as wider community of developers as possible, Java, Ruby,
   Python etc..

Yes the vision differs somewhat in it's emphasis of the diversity and
openess of all the structures involved, over the idea of achieving global
unity within a common voting architecture - that is it's emphasis on the
value of diversity and openess of people, organisational structure,
technical, architectural, etc and the benefits of this openness and
diversity to the development of the project. This does not discount the
value of architectural unity, but sees the design of such unity as an
emergent property of a participatory design process.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.reluk.ca/list/votorola/attachments/20101017/ac9aef60/attachment-0007.html>