Center

From BlackBox Framework Wiki
Revision as of 09:59, 11 August 2017 by Josef templ (talk | contribs) (→‎Links)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The "BlackBox Center" is a non-profit voluntary organization dedicated to maintaining the vision and values of the BlackBox/Component Pascal software developed by Oberon microsystems Inc. (Zurich Switzerland). Today the Center is the de facto standard for BlackBox developers, users, and project managers. The members spearhead projects that, through a collaborative and meritocratic development process, deliver enterprise-quality software attractive to large user communities. We operate under BSD 2-clause license to deploy products for business and individuals.


Mission

To provide software for the public good, based on the Oberon Spirit. We do this by keeping alive, adapting, and developing Component Pascal 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.

The Blackbox Center provides and ensures guidelines and policies to keep the community centered around the mission described above. 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 and let everybody add what they are good at to form something more than the sum of the parts;
  • work democratically and meritocratically;
  • be good citizens.

How is the BlackBox Center and its projects governed?

Members decide issues by voting. Every voting has the option "Abstain".

Votes on issues and proposals are normally called by the Chairman (or Chairperson).

The vote will be called, at the Chairman's discretion, when a discussion appears to have reached a stable point, or when two members call for a vote. He shall also notify members of the upcoming vote (by using the provided automatic notification tools).

Votes will normally be scheduled to run for five days, and members will be given the opportunity to change their votes during this period. Under appropriate circumstances the Chairman may choose a shorter or longer period.

If significant new or changed information comes to light during the voting period the Chairman may extend or cancel the vote.

At the conclusion of the voting period, and provided the vote is quorate, the vote is decided by simple majority. In the event of a tie the Chairman has a casting vote.

The quorum is given by the formula: "(Number of active Center members) DIV 2 + 1". All votes, including "Abstain" votes, count towards the quorum.

The vote may be decided and terminated early if the result cannot be changed however those who have not yet voted decide to vote (on the assumption that existing votes do not change). This is called the "Short-circuit" rule.


The Chairman is elected by vote on a half yearly basis

New members can be added by vote.

Members can apply for leaving the Center and stay in touch in the special board group 'exCenter' with posting privileges and without voting rights.

Contributions to the software come from the wider community, and the Center members decide what to add, and when, in compliance with our mission, our vision and our values.

Visions of development for the software

The following sections illustrate possible projects and priorities for the future of BlackBox. These visions will mature and evolve in the light of experience and input from the wider user community.

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 regularly 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 20 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…

Looking beyond our noses

  • When Niklaus Wirth designed the 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 run time 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, such as MS IntelliSense? Is it inherently against the Oberon Spirit, or are there ways to provide similar functionality in keeping the Spirit?

Center tasks

  • to make first version with all known bug fixes
  • to maintain stable versions of BlackBox Component Builder
  • provide it's distribution and promotion.

To maintain means:

  • regularly (period?) publish new versions of the BlackBox Component Builder;
  • support the international BlackBox open-source community;
  • adapt the BlackBox Component Builder to modern challenges.

Links