On Sun, May 27, 2012 at 8:26 PM, Peter Stuge <pe...@stuge.se> wrote:
> Alon Bar-Lev wrote:
>> Peter, quality is not absolute term.
>
> In computing I actually think it is; a high quality program does
> exactly what it is supposed to do and never anything else.
>
> Computers are very simple machines, so it is feasible for humans to
> create such programs.
:)
Well, this is similar to what I thought ~20 years ago... and I know
you are not young either...
Although I think I can reach to this point near the one you refer to,
over the years I meet a lot of people that in my view reached a father
point which was not perfect but good enough for the use case.
Perfecting anything derives infinite resources or very talented
resources. I prefer to invest resources in finding the segments where
the potential of side effect is high, and manage these ones, well,
unless I am the developer my-self :)
>
>> best algorithm
>> "good enough"
>> service and responsive to user's issues
>>
>> I, personally, for (3), providing a great service and responsiveness
>> while perfecting the code as 2nd priority (exception are interfaces).
>> I think this approach was taken at opensc in the past.
>
> It doesn't work unless there's lots of feedback from users however.
If nobody use the software, maybe the whole effort is void...
>> I also like the (2) approach, while trusting the active core
>> developers to define what is "good enough", and if someone thinks
>> otherwise he is free to become core developer or show the code of his
>> alternatives to the point it is accepted by the core developers.
>
> Right, the real fun starts when the core developers actually don't
> agree on anything, or just have different areas of expertise. And
> pack mentality comes into play if the core developer pack is smaller
> than the opposition.
Right. The core developers must be a group that shares the same vision
and methods. If core developers do not agree, project should either
fork or someone should resign.
> Ideally the core developer pack is large enough to assimilate and
> mentor opposition before any conflicts, but personally I prefer to
> focus on code over trying to educate someone who insists on doing
> things their own way in any case.
I don't understand this statement.
The code is only a mean to achieve a goal.
If a group of people does not agree on the basics, such as modularity
vs monolithic design, readability vs performance, customization vs
pre-defined, interfaces methodology -- what help is in focusing at
code?
I do understand that there is value in focusing at code in stable
maintenance mode, but I don't see this is possible when project need
to evolve.
>> Agree on commits is not something that can become reality as without
>> someone who can actually DECIDE, there can be non-ending arguments for
>> each change.
>
> The definition of agreement would be that multiple people decide the
> same thing.
Right.
And what if this cannot be achieved?
For example, let's take OpenVPN case... a patch was submitted in order
to support the Android platform. This is a good cause indeed, I think
everyone agree that supporting Android is required. There are about 5
possible integration methods achieve this goal, the quick and dirty
which adds the code within #ifdef, there is more conservative way to
add the required features of this specific platform to the common
linux platform, even if it is unique to the UI implementation of this
platform, <skipping some other>, and there is a way to perform this as
external plugin provided we delegate some more functionality to the
plugin.
So the question is not about the code, the submitted code can be perfect.
The discussion is about methodology, maintenance costs, and
flexibility to solve similar issues in future.
How do you decide which group of people should agree on what?
My solution is to divide core developers by subsystems and assign
small number of core developers (2) to he project as a whole, to be
able to decide on issues that cannot reach to agreement.
Example: OpenSC is divided into [at least] the following subsystems:
build, PKCS#11, PKCS#15 core, {reader} interface, {card} driver,
windows. For each one core developer should be assigned as accounted
to any change in the subsystem, bug or improvement. In one scenario it
can be the same core developer for all, but I there is advantage of
allowing delegation.
So if core developer X is in charge of card driver GPG, it has the
full permission (trust) from the community to perfect this driver as
he see fit. As a result you have different quality level of different
drivers, that's true, and this is acceptable cost for open source
which is based on volunteers, the larger the user base, the large the
developer base, the better quality that can eventually reached.
>> We have this exact issue at OpenVPN project, which also reached a
>> complete stop as it does not have core developers and clear
>> responsibility for subsystems.
>
> I guess that perfect commits will still be included in the codebase?
I tried to provide a use case above, there are no perfect patch,
except when project is in stable maintenance mode (stability,
security, pin-point bugs).
>> Programming is human creative work, there can be N^^N ways to acquire
>> a goal, very hard to evaluate what is "correct" or "better" in most of
>> the cases, it depends on the people involved and the people who
>> actually review at specific point in time...
>
> I'd say that it must only ever depend on the users and never on the
> developers. But of course you are right in that developers must often
> try to judge what users want and need.
True... about 20 years ago I saw an IBM platform for AS/400 which
tried to provide the user with a graphic tool to develop his own
database application, it was very impressive! I remembered I was so
impressed, to a point I thought that we are at a verge of change. But
then technology got even more complex.
So users are still at the hands of the developers, and the quality of
the solution users get depends upon the quality of the developers.
>> Same change can be accepted at week X and rejected at week Y as
>> other people review.
>
> Unfortunately yes, when there is not much agreement in the core
> developer pack.
>> Because of that trust in the "core developers" of a project is
>> essential, as it is the only constant factor in the process.
>
> But the trust doesn't materialize out of thin air. My point was that
> trust tends to come (at least for me) when there's also strong
> agreement.
Few "observers" of mine:
1. The average level of developers who are acting as core developer at
open source is higher than the average in commercial companies.
2. The process of becoming a core developer usually involved in
proving the quality of the work for some time, hence obtaining trust.
3. Whoever has time to act as core developer of open source project is
entitled to some credit, he is donating something others not, even if
it is not the perfect solution, it is progressing the ability to
provide solution out of the commercial world.
4. Whoever who rejects a core developer's work should be prepared to
show the code of his alternatives, and not expect someone else (core
developer) to do the work for him.
5. ==> Core developers should be trusted as a group and as individuals
in order to make things actually happen.
>> Not sure what this discussion was, but I wanted to comment your
>> statement.
>
> Thanks for the comment - you make many valid points! It's a very
> interesting discussion, but of course we're already off topic for
> opensc since long. :)
Right.
Sorry.
I don't think it relates to opensc project.
I follow quite large number of open source projects, I think that
project without clear leadership such as opensc and openvpn tend to
come to a complete stop after a short while of stable maintenance
mode. Project with clear leadership such as KDE, xorg, bluez, linux do
progress [=provide service to their users] even if their changes are
not perfect.
Alon.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
