Nisses,
I appreciate you taking the time to share your thoughts. I must start with
saying your feelings are echoed by quite a few developers, both internal and
external to the core team, as well as many of our users. I hope the
following goes a long way to giving you, and others the information they
need.
The issues I see from my perspective are many, but I will try to summarise
them as best I can. Keep in mind they are from my experience and opinion
only:
a) Timing. We've had a tough few years, with the project recovering from the
loss of a large proportion its core team in the not so distant past. A
generous few donated their hard earned time to keeping the project alive for
quite some time. Focusing on attracting developers and contributors to the
project without fracturing the culture and strategy is something we are
still learning to do. Quite a few ideas have been put onto the table on how
to achieve this, but we need to make this a priority, document what we
expect from people, and do it.
b) Consensus. There is quite a lot of talk about what needs doing, how we
should be doing it, and not much doing. I am guilty of this myself, and I
will go into detail in subsequent points. This is not so much from actual
coding point of view, but rather around the supporting systems and processes
around which a healthy community thrives. Consensus has been relatively
difficult to achieve as Adam has mentioned.
c) Common-ground. As the project maintainer, it has been difficult for me to
find common ground and mutual understanding with our developers about the
finer points of non-code specifics that we need to see addressed in the long
term. Documentation, usability and testing are vitaly important, but
nonetheless often not seen as first-class citizens when compared to new
features, ie: the "fun stuff".
I am by no means passing the blame onto our developers, they do an amazing
job with the resources they have, but as a team, what we have is not good
enough.
The main cause of this in my opinion, is the fact that I don't (yet)
contribute code to the project and prefer to focus on the non-technical
aspects of the project. As a consequence, I have to find ways to develop
respect and mutual understanding in not so intuitive ways.
d) Culture. We have extremely talented people working on our team, and we
all have ego's, myself included. Signs of territoriality and ownership are
destructive and need to be addressed. Further, there has always been the
tendency to keep 'core discussions' internal, without transparency or
involving the community.
My opinion is that this has been due to the desire to avoid never-ending
discussions and negative feedback, has been common in the past, and which I
feel is a natural human tendency. It is not an ideal situation, has many
disadvantages, is not a suitable way to be engaging our community, and is
one the first things that needs to change.
e) Limited Resources. We have people donating their time and effort and
money to the project. This is not designed to be an excuse and should play a
relatively small part in the successful evolution of Miranda, given that
many Open-Source project have proven successful with the same constraints.
It is to serve as a reminder that priorities and expectations need to be
managed accordingly.
f) Motivation and Momentum. Progress encourages motivation and stumbling
discourages it. Mainly due to the contributing factors I mention above,
gaining momentum has been awkward and difficult at best, nonexistent at
worst. Overcoming the lack of momentum requires seperating large, undefined
and non-tangible issues into bite size peices and easy-to-achieve goals.
The short summary of the point I ouline above is, we are a successful
project with extremely talented people contributing to it. We have a
community that cares a great deal where Miranda IM goes, and we as a project
team need to reduce the barrier-to-entry to leverage it to everyones our
benefit.
I welcome any discussions, suggestions and help in addressing the issues ive
mentioned.
Post by Adam StrzeleckiPost by Nisses InsaneI was browsing Miranda forum and Miranda core and plugin sources for
the whole day (and night). One question bothers me much. Is there any official
document (specification) other than Plugin Development Guide (4 pages)
and 4 html pages Services & Hooks Overview both dated year 2006? Or
it's just several developers with an idea in their minds but not on
paper?
IMHO miranda/includes/*.h is now the best specification, but indeed we
miss some DoxyGen or RDoc documentation.
I remember my first steps programming Miranda were really hard, so I
understand new developers being discouraged by the lack of the
guidelines.
Post by Nisses InsaneI've seen many plugins going in different directions
(sometimes opposite ones) and many changes (mostly in plugins) that
plenty of developers call unreasonable and thoughtless. Is this the
maintained project or every developer should do what he wants to
(like the service plugins becoming more important than core)? Is
there no directions and roadmap?
I doubt there's one recent, there was lot of discussion about
Miranda's future last year, we had miranda-internal very active, now
it's kind of dead.
Koobs there's was trying to put the project in the right direction,
but it seems we missed final consensus.
Post by Nisses InsaneThe project was great, great and glorious! ...back in 2006. Now it's
more like a mess, still precious but falling into chaos, more
visibly after failed attempt to implement UUIDs (athough it was planned
the people got surprised).
I don't want to start flame war here, but I share the same feeling.
Miranda is not recent project though, it had many developers, may
ideas. I perceive current situation as natural process for many
projects, Miranda had its days of fame already. Now the newer projects
having fresher ideas are about to take over the lead.
Moreover openness of Miranda API, many plugins doomed Miranda to
chaos. I have nothing against the plugins, but the core should be kept
crystal clear, but it's not.
For example there're 3 forks of clist sharing 60% of same source-code
base, so don't look for DRY in the M's code.
Post by Nisses InsaneI hope I'm wrong and someone points me to some resources filling
missing information. There's another project Pidgin (former GAIM)
which seems to be more organized and worth following from the side
of docs and planning.
Pidgin is amazing example of revitalization. Currently I'm little bit
supporting Pidgin sending them patches as now I'm one of happy Adium
(sharing same proto lib) users.
The Pidgin developers community seems to be very active at the moment,
also Pidgin is multiplatform IM so that's great advantage.
Finally I think there's still a chance for Miranda, only if there was
someone who could cut the bloat off the core.
Regards,
--
Adam Strzelecki |: nanoant.com :|
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Miranda-Develop mailing list
https://lists.sourceforge.net/lists/listinfo/miranda-develop
--
--
My reality check just bounced.