[BLACKBOX] Aw: Re: [BLACKBOX] Re: [BLACKBOX] Re: [BLACKBOX] [BLACKBOX] The official position of the Russian OberonCore team about BlackBox Support from Rene A. Krywult on 2013-08-21 (BB-FullArchive.mbox)

From: Rene A. Krywult <"Rene>
Date: Wed, 21 Aug 2013 15:14:46 +0200

----boundary-LibPST-iamunique-614127119_-_- Content-type: text/plain Well, Ivan, I dont' know. Language is an issue here, definitely, because I often have to guess what you are saying, and even more often, what you really mean. English is not your first language, and it is not mine either. So, I hope that in what I write below, I do understand what you are trying to say and not bark up the wrong tree. If so, I apologize right now :). >From what I understand, you say that we should do first and talk later. And you claim that this probably has to do with age, too. And you are right: As a child, I believed that analysing, planning and talking was for sissies, too. I had to make mistakes, have high goals *not* achieved, see software projects I had my heart set on crumble because I didn't do the necessary work of analysing and planning before starting to code. But this taught me that anything worth doing is worth doing it right! And to do anything in IT without analysing first is a sure recipe for shattered dreams. If you are not old enough to understand this, Ivan, then good luck with sore knees and broken bones, metaphorically speaking. You'd better listen to wisened old men, if you want to keep your health. When Omi first made BB OpenSource, the community was glad - but nothing happened. A few years later, I tried to convince the community that we should stop waiting for Omi to fix BB, but start doing it ourselves. I read articles about OpenSource projects and what makes the difference between failure and success, and I sent a few of them to the list. Nothing happened. Why? Because Omi was still there to do the work. So the community of BB using developers didn't need to become a community of BB developing developers. Now Omi has taken itself out of the equation. They will not be responsible for further developments. A bold move! A necessary move! Now it is up to us to either live up to the task or let BB rest in relative obscurity. For me, this is like a hike in the montains. I buy equipment and a map, I plan, I prepare, I go, I succeed. If you want to run off without a map and without preparation, fine. But don't you think you'll get lost and exhausted without ever coming to anything? I'm not someone with great knowledge of machine code, compilers, low level programming and such. I am, though, a project manager and a software developer. That's my bread job for the last 20 years. I know something about what makes the difference between a failed project and a successful one. I know something about RAD and it's strenghts, I know something about SCRUM. I'm also a networker and community builder, though not in IT. I have experience in religious and in academic communities, I'm also involved with the Red Cross. In all those cases I work with volunteers and as a volunteer. I know how to build a community, and how to keep it focussed and working. If you think that youthful warhorseship is the way to go in an OpenSource community building effort, have fun. I'll aplaud you for your enthusiasm, and commiserate with you for your shattered dreams. Rene Gesendet: Mittwoch, 21. August 2013 um 14:26 Uhr Von: "Ivan Denisov" if I understand your official position correctly, you do not concern yourselves with > *) internalization of the basic BB framework > *) adaption of the basic BB framework to newer versions of Windows > *) porting of the basic BB framework to other platforms, like Linux, Apple OS and JVM > *) adaption of the basic BB framework to better fit the state of the art > In short, OberonCore does not see a need for a unified and central BB Framework 1.7. > Is this correct? 1) United centre of responsibility for "unified and central BB Framework" is a precondition. There is no point in discussion about "unified and central BB Framework" without it. Such centre may be assigned as the successor of BlackBox Support Oberon microsystems AG by acknowledgment. Or shall be elected by Community. 2) We are open to any development and it's our main activity (for example: support of BlackBox Russian documentation for BB 1.6 (http://oberoncore.ru/projects/bb-docu-ru); BB1.6-rc6 Linux Console (http://oberoncore.ru/projects/bb16lin-console) ). Hypothetic "basic BB framework" (HBBBF) ported to newer Windows versions, Linux, Apple OS & so on� Is HBBBF compatible with standard BB? Or it inherit it's name only? Who can answer this question now? There is the concrete public assembly � OberonCore BlackBox assembly on the other side. It's based on BlackBox Component Builder 1.6-rc6 (for Windows (XP, 32bit, �)) for now. And it's main development rule is "Primum non nocere". Best regards, OberonCore team. ---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy ---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy ---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy ---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy ----boundary-LibPST-iamunique-614127119_-_- Content-type: text/html Well, Ivan, I dont' know. Language is an issue here, definitely, because I often have to guess what you are saying, and even more often, what you really mean. English is not your first language, and it is not mine either. So, I hope that in what I write below, I do understand what you are trying to say and not bark up the wrong tree. If so, I apologize right now :).

>From what I understand, you say that we should do first and talk later. And you claim that this probably has to do with age, too.

And you are right: As a child, I believed that analysing, planning and talking was for sissies, too. I had to make mistakes, have high goals *not* achieved, see software projects I had my heart set on crumble because I didn't do the necessary work of analysing and planning before starting to code. But this taught me that anything worth doing is worth doing it right! And to do anything in IT without analysing first is a sure recipe for shattered dreams. If you are not old enough to understand this, Ivan, then good luck with sore knees and broken bones, metaphorically speaking. You'd better listen to wisened old men, if you want to keep your health.

When Omi first made BB OpenSource, the community was glad - but nothing happened. A few years later, I tried to convince the community that we should stop waiting for Omi to fix BB, but start doing it ourselves. I read articles about OpenSource projects and what makes the difference between failure and success, and I sent a few of them to the list. Nothing happened. Why? Because Omi was still there to do the work. So the community of BB using developers didn't need to become a community of BB developing developers.

Now Omi has taken itself out of the equation. They will not be responsible for further developments. A bold move! A necessary move! Now it is up to us to either live up to the task or let BB rest in relative obscurity.

For me, this is like a hike in the montains. I buy equipment and a map, I plan, I prepare, I go, I succeed. If you want to run off without a map and without preparation, fine. But don't you think you'll get lost and exhausted without ever coming to anything?

I'm not someone with great knowledge of machine code, compilers, low level programming and such. I am, though, a project manager and a software developer. That's my bread job for the last 20 years. I know something about what makes the difference between a failed project and a successful one. I know something about RAD and it's strenghts, I know something about SCRUM.

I'm also a networker and community builder, though not in IT. I have experience in religious and in academic communities, I'm also involved with the Red Cross. In all those cases I work with volunteers and as a volunteer. I know how to build a community, and how to keep it focussed and working.

If you think that youthful warhorseship is the way to go in an OpenSource community building effort, have fun. I'll aplaud you for your enthusiasm, and commiserate with you for your shattered dreams.

Rene

Gesendet: Mittwoch, 21. August 2013 um 14:26 Uhr
Von: "Ivan Denisov" <d.ivan.krsk{([at]})nowhere.xy An: BLACKBOX{([at]})nowhere.xy Betreff: Re: [BLACKBOX] Aw: Re: [BLACKBOX] Re: [BLACKBOX] [BLACKBOX] The official position of the Russian OberonCore team about BlackBox Support

Dear Rene and OberonComunity

This message includes a lot of criticism, but should not be considered as aggressive or anger. I agree with Rene that now is the stage of trial, maybe not because of the cultural difference but the age difference you looks at my "trial" as a final decision. For young is more interesting to trial work then trial talk, because that give a chance to learn more. Also, if nothing to do and show, there are nothing to discuss. I respect everybody for the professionalism and work you are doing. This is dialog you ask for and it will try to explain why I think we should take a look more on a technological part of Community Future Communication.

Certainly the expert work is important, but the "center" without hands and ideas will be a mouldering stump. If somebody take roles called by Rene it is not sufficiently to be the center. As Rene right mention, community should "accept the services and role". I think that the key word here is "services". Oberoncore provide the best service for forum and documentation of bugs. Applause! But the other sides not allowing them to be such "center" them will be touched bellow.

The next scenario suggested by Rene is simply "community", and agree with OberonCore that it is the most probable scenario. But do not agree that BlackBox Component Builder 2.0 should not see the light some time in the future. The community also can make decisions and maintain the versions.

The community of BlackBox can unite three things: 1. Style (minimalism, goes from the N.Wirth & A.Einstein slogan). 2. Technological goal (already wilted and does not bloom yet) 3. The platform (the place to solve your working problems).

The minimalism for work today possible but becoming dangerous and not every user of blackbox enjoy this. That is why the first role for community holding should play the platform. In includes development and distribution part. There was two centers for that stuff before: 1. the H. Zinn collection of components and 2. OberonCore collection. All other stuff was decentralized. As a user and developer I was not suttisfied from both. Their editorial systems makes me fill fear. Also the usage without bug tracking, users comment, ratings automated version control systems was not efficient and I am sure it had decelerated the improvement of components blocking dialog of developer and user.

Today for the development we need Issues tracking system and modern code version system friendly with Component Pascal.
Today for the distribution we need the same automated platform for components as Lunchpad for Ubuntu developers, for Apple Store for Apple developers, for PlayMarket for Android developers.

That two services can make community unite and grow. That is why as a patriot of Oberon language family I do that I do — make this services works. All other is conversation "who will be the mouldering stump?". I do not want any "center" decide is my documentation written good or bad, or is my component good to distribute enough. Let the users decide, mark me, give a feedback. That is my idea. Make it modern BUT SIMPLE. Not Mailing list or words blowing forum BUT GIT+REDMINE+CHAT, not static web-sites BUT Kindly Automated Component Store. Not a conference once 4 years but weekly!!! Oberon Google Hangouts.

Technical and organization solutions for this challenges are not on a plate and need to be checked from existent and some are developed from the scratch. The Redmine was one of such check suggested on forum.obeoncore.ru for the development and this check I done and invite you to test it well.

Everything revolves. Robert C. had already gave a feedback of using "git clone" and the issue about zipped archive with BlackBox. Ilya Ermakov had already gave an solution how to fix this server slow start Issue. Oleg N. Cher and Roman Miro have been started pushing Bug Issues and fixing them. I have merged OberonCore, H.Zinn, Maliya, Louwe, M.Frei fixes to master branch. Peter Kushnir working on how to integrate odcTOutf8 converter to Mercurial for have choice between developing system. Helmut Zinn integrates all known fixes to maintain his experted version, we includes all of them in redmine for sure. Boris Rumshin and Eugeny Temirgaleev make great work on forum to make it more friendly for non Russian language users, and I am sure they will maintain new version of their assembly too.

We do know what are doing in Oberon Microsystems AG. Is there is a hope that our activity not make them change their opinion about FreeBSD license? :)

Regards Ivan

2013/8/21 Rene A. Krywult <

Great! I agree. Technical issues, both concerning hosting platform and future development need to wait until there is a "center".

I propose the basic functions I believe the "center" should have:

1) Publication of a stable version of BB Framework

This includes adaptions to future versions of the OS, bug gathering and fixing, testing, documentation, making sure that all changes are "by the book". This does not mean that only the "center" may provide bug fixes, but only the "center" decides, which bug fixes actually make it into the next stable version.

2) Planning and coordination of internationalization

3) Planning and coordination of ports to other OS/platforms

4) Web Marketing of BB

5) Communication between members of the "center"

6) Communication between the "center" and the BB community as a whole

7) Facilitating a central and international communication platform for the community