Annunci online

All that comes in the mind of an italian guy moved to california
11 novembre 2008
Tecnologies:AROS:Anubis OS: Anubis, son of AROS and the "leap" legend
[Edit: sorry to have taken so long in publishing this since the italian version: been busy in my job and in real life.]

I would have liked to start this thread with some mythological tone, such as Conan the barbarian and similars, talking about heirs to the throne, heritages, traditions and other stuff like that: i sincerely admit i was tempted to do so.

I will instead start talking about a day, three weeks ago, when Michal Schulz posted a link on the #aros channel on IRC: this link.

It is nonetheless that the sourceforge page of what has announced this week from Damocles as Anubis OS, the latest incarnation inspired by Amiga OS, based on a Linux kernel and with a Graphic subsystem that, according to the Anubis mailing list, should be based on xcb,xlib and a mix of Glib/Gtk and Zune. Further details have been explained here.

In short, is their intention to do with Amiga OS what has been done from Apple in OS X: somebody already uised the term "carbonize".

From what both Michal and m0ns00n (Hogne Titlestad) told me, the main reason that make them start the project has been an essential steadfastness from other AROS developers towards more innovative goals: Damocles already complained about the conservative approach of many of the core developers. as i wrote here.
So, Michal, together with m0ns00n and Damocles started to define the base functionalities and requirements of Arix. Michal will begin tu put full steam on it once the Efika port will be done; task that is bringing along the comppletion of the USB mass-storage bounty, another important requirement.

In a following IRC chat session, Michal told me how Amiga OS seems to have an history of lost opportunities, both for management and markerting mistakes, but also for ego trips and "balcanization" of the resources. He thinks at ARIX (sorry i dont like the name Anubis OS too much) as the Amiga OS that should have been, with resource tracking, protected memory and all those features that first Amiga OS then AROS were unable/unwilling to develop for the known reasons.

Michal is a pragmatic person and for him the usual debate about whether if you use a POSIX kernel in an Amiga OS that ceases to be an Amiga OS is or not is over: he decided that it is and, i hope, wil prove it quite good in the future.

Anyway, has to be known that Anubis OS cannot be considered an AROS fork: technically AFAIK a fork happens when a project is duplicated and modified but, being Anubis based in a different kernel, figures as an indipendent project.

The announcement was taken not too good from the amiga boards: for the aforementioned reasons above and for the cronical lack of development that is afflicting all incarnations of Amiga OSes, a heavy FUD cloud spreaded around, like has rarely been seen before. The maini nconcern among other amiga users is the runaway of the already few developers towards a system that might not even reach an usable state, and the progressive death of the already existing systems.

Luckilly, open source projects hardly die: they might become unmantained until somebody else starts again to take care of it or integrates the code in their own project; luckilly for AROS this fate looks far from happening: the project look active as ever so far, and hoping this state will last.

And, like to show that AROS, despite the imminent departure of "Doctor" Schulz and the announced "pregnancy" (kitty is a female cat :P) is still vital, let's talk about the so-far spiritual heeir of the Doctor: Stanislaw Sszymczyk that, according to its job for the self-compilation bounty, now almost [edit: no more almost: done!!!] finished has achieved considerable result, such as:
 - non dynamic port of the latest versions of python and perl;
 - self-compilation at first in RAM, then under SFS of AROS in AROS;
 - extension of the POSIX layer compatibility adding instructions such as vfork(), wait() and waitpd();
 - DOS.library modification in order to allow soft-links;
Beside that, sszy also standardised the development packages in the variuous port of AROS under GCC 4.2.2 and included their compilation in the AROS build system in order to have a system of compilers and cross-compilers built for all targets.

Furthermore, Stanislaw gave a look to the sources of Netsurf and OWB; beside some minor issues, the browser can be ported quite easily starting from the OS4 port if the GUI was not a ReAction one; so Stanislaw is looking for someone (looks like o1i might help, and i want to mention ShinkurO due to its experience on workarounds for the zune bugs) to help hm in doing a zune GUI for it.
The OWB port looks a bit more complicated due to the fact that the Gladelib port is required under AROS and so far sszy was unable to do the port.

Another important update comes from the API completion report: Krzysztof Smiechowicz completed its review job that kept him busy since last april; according to its data the completion level of AROS is around 80%. This report is also the ground for a concrete roadmap to follow so that a version 1.0 of AROS will be available in a more human timelapse.

And is also a good step that finally in the mailing list somebody is starting to talk about the strong need for documentation. Krisztof Smiechowicz has already started in adding documentation on the ABI v1 here and hopefully some more important documentations will continue to come soon.

At last look also that somebody will finally take care of the printer.device in a laid back timing; about me i was looking and sent cdocumentation to the guy interrested to help himin the development, included the old Ghostscript port on AROS now no longer working [edit: seems a new port is on the way]; lets hope to see something soon.
9 luglio 2008
Tecnologies: AROS: the Pidgin Factor and Product Management
[This article translated in a latter time]
Originally published in July 9,2008

[EDIT - oct 20 2008: this article is quite old, but seems to have grasped well some AROS recent ongoings so give it a read]

Unless somebody else of the Cannocchiale bloggers don't tell me how to recover my old unpublished articles (waiting for time, inspiration, further documentation,etc.) i feel kinda forced to start again this article, with the needed updates.

First of all, let me introduce the "causus belli": Pidgin Bug Report, an article on Product Beautiful and a further Article on Product Beautiful on the subject.

The outcome is surely known on who is following open source software progress: since last jannuary pidgin users are complaining about a new feature that resizes automatically the message textfield; the developers answered that it was introduced by them because they liked it and they have no plan to remove it or make it facoltative. A big discussion arised, quite polite but with strong opinions and brought to a riot against developer's decision, at the bug report closure as "wont_fix" and at a fork of the program, funpidgin.

Among all the interventions, one quite interesting from Dan Livingston, teacher of "collaboration in the Open Source world" in a North American college, going quite hard on developers behaviour:

I teach "Collaboration in an Open Source World" at a local college. I have been searching for, and in this ticket have found, a perfect example where communication between open source developers and users fails at multiple, fundamental levels.

Obviously, the motivations of open source developers are varied; some do it for technical enjoyment, others enjoy knowing they are contributing intellectual capital to a better world. The problem is when the motivations of open source developers conflict with the expectations of users.

Consider every wildly successful open source project: the users are enthralled with their ability to perform new activities in ways previously unimagined. Rabid dedication grows, and an evangelical fan base results. Pretty soon, it's obvious why users would not want to go with non-open source software alternatives.

What happens when those same newfound powers are taken away? What happens when the developers impose their personal dogmas upon the project? Even for as small an issue as chat window resizing, a minority (or majority) of users will emphatically express dissent.

It's easy to see why open source developers could develop dogmas. Some like to fantasize about the theoretical limits to which a design may become "pure", developing a vile repulsion to anything which steers away from purity. Others become obsessed with metrics such as maintenance effort per line of code, even though they often worry about features and lines of code which only contribute to 1% of the complexity of the application. Yet others develop fixation on "ultimate user simplicity", feeling that two options are better than five options which deliver more power. The most dangerous dogma is the one exhibited here: the God feature. "One technological solution can meet every possible user-desired variation of a feature."

The initial lure of open source software is that quality software should resoundingly meet the needs of users. As demonstrated up until Pidgin 2.4, the fan base has emphatically been extolling the virtues of Pidgin. But when developers take a feature away, presumably to implement a "better version", and that better version in fact is a step backwards from the functionality previously available, they had better have a damn good reason. Such a reason is lacking here.

"This is how IM should be used." "Our design is better." "We will only consider a 'pure' design in which we can accomplish the old functionality in a paradigm that also supports the new functionality." "An additional checkbox is too detrimental to the user interface." "Maintaining two branches of logic within the dialog sizing component will be untenable." "We have no interest in not pushing our shiny new object."

These are all statements, which if executed within a corporate arena, would get developers fired. Developers, make note: you are doing a disservice to the community you claim to represent, and are doing so with false illusions that you are "right" because you have convictions in your justifications.

It does not matter that you are open source developers with the autonomy to ignore your user base. It does not matter that a plugin "could" be developed to solve the problem. It does not matter that you feel your default solution is superior. It does not matter that you only want to consider solutions which can be implemented through the new solution framework. It does not matter that your users should abandon your product if they don't like it. It does not matter that someone could fork the code base. It does not matter if 11 thousand people download your source code per day, and only 270 complain about it. For each of these, there are very valid rebuttals.

So, only 270 complaints for this feature, out of 11 thousand downloads? How many people immediately uninstalled the program when they realized it could not longer do the simplest functionality that GAIM and other IM agents do? How many don't know that they are using software that is now crippled in comparison to its former flexibility? How many use the software today, but will switch to GAIM tomorrow when they hear from their friends that it's so much easier to resize in GAIM?

The fact is that typing letters into an IM window is THE most critical task of an IM program. Users have varying needs, needs which can not be addressed by your limited attempts to come up with "one solution for everything" that incorporates "shiny new logic" that demonstrates how smart you are. You are ignoring the fan base with a dedication to your convictions that is alarmingly evident to even the most unobservant of followers, and as such, you are demonstrating that you no longer deserve to be in the position of servicing the needs of your user base.

For the sake of everyone involved, I hope you find your path back to the light.

And the following is the hypothetical response that Dan supposes users should receive from the development team:

Dear Users:

You are most undoubtedly reading this page because you want to know how to manually resize the text input area in Pidgin. It is a feature that you have perhaps grown accustomed to and comfortable with, but please make note - this feature is no longer supported.

We have received many complaints from a very small minority of the user base who nonetheless persists in being very vocal about their displeasure. Please take comfort in the fact that they are only a very small percentage base of Pidgin users, and if ignored, will go away and bother some other open source project.

Nonetheless, we feel it very important to make the following proclamation regarding on our stance on this project: we will not "fix" it. In fact, please notice that the status of this "bug" is "wontfix". So would you please just get this idea through you head and go away now?

We are developers of this software, and we develop Pidgin so that it may fulfill our explicit needs and desires. If you want to join us for the ride, then fine. Just shut up, though. Please, if we've made a feature a certain way, it's because WE WANT IT THAT WAY. Is that so hard to understand? All day long our bosses tell us what to do. Our wives tell us what to do. Our government tell us what to do. YOU will NOT tell us what to do.

Some say that as the developers of the premier open source IM client, we have a "responsibility" to serve as wardens of our precious charge, nurturing it into a fine, outstanding, model citizen of the open source community. That's rubbish. The last time we checked, we didn't sign up for day care. We signed up to write software that WE want to use.

So please take your ideas and go elsewhere. If you want a development team that responds to the desires of their user base, hoping to release world-class, quality software to millions of people, then start your own open source project. It's not that hard. It's free. All you have to do is commit your time, just like we commit ours.

The development team would very much like to come up with a solution that meets the needs of ourselves and the general user base. However, we cannot understand your needs. You speak in a foreign gibberish, gobbledy gook language that none can understand. "I just like it that way!" That is not an answer! You must enumerate the metrics and aspects of your preferences and desires in ways that we can evaluate and then assimilate into our collective. We cannot currently assimilate any of your idiotic reasons for wanting a resizable text box. And by idiotic, we mean "any solution which does not fit into the scheme of our cleverly intelligent auto-resizing text field."

So, just to make it clear: we will not listen to your suggestions unless your suggestions make sense to us, and we like them. If you do not like it, there are plenty of other ways on the Internet in which you may occupy your time.

Regards, Pidgin development team"

Damn! Me too, when i develop in my job am really tempted to answer like that way but, considered that if i do it might need a new job , might find myself broke and with no way to pay bills, am  kinda forced to consider a more condescending attitude.

Anyway, going to the point, i took out the Pidgin debate because of some attitudes from the ReactOS team in their discussion forum shortly before the 0.3.5 release.

I heard several hundreds of time and am aware that AROS and ReactOS need to be defined "hobbyist" operating systems and not "world domination" systems and also am aware that the "no schedule and rocking" philosophy of AROS developers is not keen to make final users and investors to plan on it; the other side of the situation is that AROS is not enough developed because its low developers number and, paradoxically,  has a low number of developer because is not developed enough yet.

Beside the preaching of FOSS evengleists, the Open Source philosophy does not require a cooperation based on the "code or get out" attityude: as exposed by Dan Livingston above, a open source community expects cooperation even in "minor" tasks such as community activities: feature requests, bug report, advertising, advocacy, graphic themes, etc.

In example I feel that am controbuting writing about AROS in my blog (advocacy): i hope in future to cooperate at a deeper level, wife and job allowing me to do that.

And even an open source community, willing or not, DOES marketing, meant as presentation of it for its diffusion: it does it mainly in a viral way, such as spreading the word, commenting it, etc.

Of course having a more outgoing profile to "sell" helps the copmmunity in the "product" diffusion.

And the diffusion of the "product" brings in both final users and potential developers.

Aros, thanks to its media apperarances with VmwAROS, for its user's advocacy and advertising activities and for the surviving Amiga community that is having benefits through AfAos (AROS for Amiga Os, a project that is replacing outdated AMiga libraries with more recent AROS ones) is actually getting more users and developers; but it's not enough yet.

A better presentation of the project, the rewquired documentation development - that is starting to appear but is still too depending on the pre-existing Amiga OS one, being also affected from the Guru book publishing - maybe the apparitions of written and video tutorials to explain the AROS use and at the end the hoped coming of applications and hardware drivers (tightly tied to the aforementioned catch-22 "lack of developers in a underdeveloped OS") might finally bring AROS and other alternateOSes to be more widespread than they are now.

It is also my opinion that, once a poject reach a "critical mass" of users, the developing team's hobbyistic/edonistic approach to programming cannot be the main motivation and the reason of existence anymore; from the fact itself that users are using and relying on it doing even critical activities with it, the team acquires the moral, if not social, obligation to listen to the final users. Then, if they like to modify things they can "sublet" the maintenance and dedicate themselves to a "director's cut version" aside; then, if the new version will have a good response they can let it contribute back to the main flow and so on; but the fate of the project is no longer in the developer's hands only: the project has become and belong ALSO to the community that embraced it, use it and love it.

Product Beautiful in its article talk about the Product Management in the Open Source community and on how the actual approach - thinking that product management is meant only for commercial activities - is wrong;
As provocation, they propose that open source products should have a "quality seal" in their home page (the one at the top of the page) where developers declare whether the project purpose is toward the community or if the project is made to "scratch their own itch" - meant for themselves - in ordet to avoid bad facts as the ones in the Pidgin Community.

I would be glad to hear firther opinions about this.



Feed RSS di questo 

blog Reader
Feed ATOM di questo 

blog Atom
Resta aggiornato con i feed.

blog letto 1 volte

Older Posts

Who links to me?
Get in touch with Simone Bernacchia