Center white paper

[ReneK]

Ivan proposed the following on his wiki. For those who do not want to join the wiki right now, I post it here:

BlackBox Framework Community "center" is the nonprofit organization for ...

Center mission

To maintain stable versions of BlackBox Component Builder, provide it's distribution and promotion.

Center rules

1. The decisions about "center" and BCB are made by voting

2. Voting quorum is 80%

3. The application about new membership in the "center" approved by voting with preliminary minimum of X days discussion. For the discussion applicant should give information about it self in the form of motivation essay: a self introduction, why he wants to join, what his current affiliation is, what his relationship to BlackBox is.

[ReneK]

I think that "maintain" is the wrong word, since it is passive. I think the center needs to be more active. Thus:

.. adapt the BCB to current needs
.. publish stable versions of the BCB
.. build up and support an international OpenSource Project Community.

[Ivan Denisov]

I agree, that the mission can be more concrete, but better it not be very long.

This points looks like the tasks but they works, the only I think that adaptation is not the first task.

Who else think that "maintain" is passive word?

[OberonCore]

The word 'stable' isn't suitable for BBCB. At least it isn't suitable for Oberon-way... and BBCB is of Oberon System class.

[ReneK]

The word 'stable' isn't suitable for BBCB. At least it isn't suitable for Oberon-way... and BBCB is of Oberon System class.

Do you object to the concept, or to the word? Why? Is there an other word you'd like to use? Which? Why is it more in the oberon-spirit?

AFAIK, the A2 website (Bluebottle OS) used "stable version" on http://bluebottle.ethz.ch/download.html some time ago (they had a "nightly build" and a "stable" one), and I think they are of the Oberon System Class, too. They were even a project of the ETH.

For me, a stable version of a piece of software is

analyzed
programmed
refactored
tested
documented

or, short, "ready for shipment".

A BBF-version is one, where those subsystems that BBF-Center that releases, are stable in the above sense. What's your take on it?

[Josef Templ]

To me there are two more meanings of 'stable'.

1. Keep the module interfaces stable.
This applies to both syntactical and semantical aspects.
Any change of a module interface must be done with great care.

2. Keep the documents compatible.
Existing documents must remain usable with newer versions of BB.

- Josef

[ReneK]

Very good ideas, Josef. I second that.

OberonCore proposed to have a chairman in order to further posting and voting discipline.

The role of the chairman is proposed to be:

(0) to be sure what any center member known about the vote (at least about important questions);
(1) to start the voting thread after a prior discussion;
(2) to inspect "any center member wrote his vote", finish the voting, count.

Some further roles I see necessary are:

cashier
forum administrator

[ReneK]

I think that http://forum.blackboxframework.org/view ... 3f0f3#p280 is relevant to this discussion, so please take the time to read that post.

In light of this post, what about:

The Blackbox Framework Center (BBFC) is an international OpenSource joint venture of persons and groups committed to serving the Blackbox community by evolving and regularily releasing and promoting a ready-to-use distribution of the Blackbox Framework based on the final release of Oberon Microsystems AG (BlackBox 1.6).

A ready-to-use distribution is refactored, tested and fully documented, both for programmers and users.

Blackbox Center uses blackboxframework.org as its central working space.

As a joint venture, BBFC makes its decision by vote. All members are bound by such decisions, as long as they are part of the joint venture.

Every Center member, no matter if representing a group or a single person, has exactly one vote on every question.

Votes are called by the Chairman only, whose responsibility it is

(0) to start a voting thread after sufficient prior discussion;
(1) to make sure that each member is informed about pending votes (at least about important questions);
(2) to make sure that each member took voted
(3) to close the voting thread

The chairman is called by vote and automatically released after a fixed term (yet to be defined). In cases of severe mismanagement of his duties, the center members can call a vote to release the chairman before the end of his term.

This wording includes OberonCore's caveats against "Blackbox Framework Community Center" and "stable version", it includes our starting point of development, our goal (evolving and regularily releasing a distribution - active formulation) and who we are (international persons and groups).

Of course the part about the chairman is just a proposition that still needs to be refined and voted upon (as already stated, we also have to vote if we want a chairman at all).

[ReneK]

Peter called us to provide our vision about Blackbox after a week of no discussion. So, here is my vision, as a basis for discussion:

What is the Blackbox Center?
As of now, the Blackbox center is a loose joint venture of 10 juristic persons (“members”) dedicated to the mission, the vison and the values of Blackbox Center. It is a de facto board of directors. In the future, it could be necessary to transform the Center to a juristic person of its own, in order to provide a framework for intellectual property and financial contributions and simultaneously limit potential legal exposure for our project committers. The members spearhead projects that, through a collaborative and meritocratic development process deliver enterprise-grade, freely available software products that attract large communities of users. We operate under a licence to make it easy for all users, commercial and individual, to deploy our products.

Vision
The mission of the Blackbox Center is to provide software for the public good, based on the spirit, philosophy and technology put forth by Nicklaus Wirth and Jörg Gutknecht in the Project Oberon (the “Oberon Spirit”. We do this by keeping alive, adapting and developing Component Pascal, Blackbox Framework and Blackbox Component Builder starting with the last official release (V 1.6) provided by Oberon Microsystems AG (the “software”) and growing and maintaining an international user community.

Mission
The Blackbox Center provides and ensures guidelines and policies to keep the community centered around the vision described above. As such, we are not the sole developers of the software, nor the only providers of the software, but we provide a clearing house to centralize efforts.

Values
As a community we strive to

• * Cooperate for the common good,
  * Make things as simple as possible but not simpler
  * Use the idea of component building, that is to let everybody add what he is good at to form something more than the sum of the parts.
  * Work democratically and meritocratically
  * Be good citizens

How are the Blackbox Center and its projects governed?
Currently, the 10 members decide issues by vote, with 80% constituting a quorum. Every vote needs the options “none of the above”. Such a vote is counted for the quorum, but it does not take a side. For an option to be accepted, it needs 51% of the quorum.

Votes are called by the Chairman only (who is elected by vote on a yearly basis), whose responsibility it is

• * to start a voting thread after sufficient prior discussion;
  * to make sure that each member is informed about pending votes (at least about important questions);
  * to make sure that each member voted
  * to close the voting thread

New members can be added by vote, if necessary.

Contributions to the software come from the wider community, and the Center members decide which additions are added, and when, in compliance with our mission, our vision and our values.

Visions of development for the software
Keeping alive

• *All parts of the software are documented both in source and in an overview document (no “this module is internal” documentations!)
  * All OS function calls are checked regularily and if necessary changed so that the software does not use deprecated functions.
  * Known bugs are fixed
  * There are regular “working releases” and once a year or so there are “major releases”, to make sure that the user can rely on the stability of the software.

Adapting
Blackbox is now 10 years old, and the world has changed. We need to adapt.

• * Providing a 64-bit version of the software
  * Adapting to the changed native look and feel of the OS
  * Internationalization of user documentation and user interface
  * Implementation of additional GUI elements provided by the OS as part of the standard distribution

Developing
Source-Code compatible versions with local look-and-feel for
* Mac OS
* Linux
* JVM
* Dalvik VM
* .NET
* Raspbian…[/list]

Looking beyond our noses

• * When Wirth designed Oberon System, he discouraged multi-tasking on single processor systems, because it only adds complexity (i.e. it is against the values). Over 20 years later, most of our systems are multi-processor systems. Is the current handling of “Actions” still the best practice, or should be implement – in the spirit of Oberon – multi-threading, and if so, how? For instance, we are faced with the problem that the Runtime System freezes when you keep a mouse key pressed. Is this really necessary, and how can we solve this in the Oberon Spirit?
  * Are there new paradigms of user interaction in software development that we could (and probably should) integrate, like for instance MS IntelliSense? Is it inherently against the Oberon Spirit, or are there ways to provide similar functionality in keeping the Spirit?

[Peter Kushnir]

Thanks, ReneK.
As a manager you've also described some Center's future.
I think, when every member will provide his opinion we can finally summ them in a Manifesto, that must be precisely translated on different languages.