8 Led
2019
8 Led
'19
11:43
Jóhann B. Guðmundsson <johannbg(a)gmail.com> writes:
Yes. The problem is that nobody has any idea how such carrot model
would work. Especially since the whole domain registration system falls
in the category "less popular but more important".
Which is exactly what we are trying to do. We cannot go full
distributed at the moment.
That would be better answered by other people like Jaromír or Jiří Šádek.
Ahh, wrong choice of words. People, of course. contribute. By
reporting problems to us. But the amount of patches is not as high as
we would hope.
On 1/7/19 2:56 PM, Miroslav Franc wrote:
I'm afraid this is based more on ideology and orthodoxy and less on
rational thought. That change in internal workflow might include
upstreaming bug tracker and unless that change would produce some
non-trivial number of C/C++/Python developers it is unworkable model at
the moment. We cannot embark on utopic projects that would be on the
day one on a collision course with reality. If you put a few people in
the same room, they will be able to progress faster than the same amount
of people trying to communicate via mailing list or bug tracker often in
their second or third language. The distributed model of development
you seem to be so fond of is not necessarilly incompatible with open
source and it has its own host of problems. I myself worked at Red Hat
for over five years and what I withnessed more often than not did not
impress me. It might be an endgame. But we must get there naturally
without jumping ahead of ourselves. Mirroring our repository on github
a allowing people to sending us pull requests was a significant step.
It cannot be the last, but for now it has to be enough. I know that in
this hybrid model of developement, the external contributors might feel
as second class citizens, which is unfortunate, but I cannot think of
simple solutions.
Jóhann B. Guðmundsson <johannbg(a)gmail.com>
writes:
The cost becomes less not more so there is always a reason to try
first by approaching this with an open community model from the get go
for an project but can become more costly to open afterwards ( not in
your case thou, just requires a change in internal workflow and a new
mailinglist afaikt ). On 1/4/19 9:27 AM, Jaromir Talir wrote:
Nobody in here will doubt that "enlightened" shared maintainership is
ideal. But in the real world it has its cost and unless you can get a
sufficient number of contributors there is a very little reason to even
try. Hi Jóhann,
it's great to hear that ISNIC is evaluating FRED. Feel free to report
any obstacles, we will do our best to make it right tool for you :)
I'm in no doubt you would but this and reference to ( internal
tracker? ) issues in commit's on github begs the question how much (
if any ) registry ( or the 3r's ) community product fred is and
perhaps every open sourced project coming from the cz.nic development
department?
To further explain what I'm getting at is that the general association
is made when hearing or reading the term ‘open source’ is that the
software project is collaboratively developed and shared freely with
whoever wants to see it (some licenses prohibit commercial use or
abstraction, but in general anybody who wants to can look at the code
and modify it for their private non-commercial use).
It's an world where anyone can join the developer community and submit
code and patches and other resources, and contribute to the roadmap of
that project. Sometimes the new joiner may not have commit access
until their credentials are proven, but the project is generally
community based and community driven.
In the case of Fred that community would most likely be made up of the
registry, registrar and registrant, the target audience of such
application or application stack )
The there is the "unenlightened" association in which projects
commonly generated by universities,institutions, corporate and other
entities in which they freely share their source code, but they
provide no community mechanisms for contributing to it or helping
guide its direction.
Sure individuals can email in a patch or suggestion, make pull request
in git(hub) and hope that it gets applied but there is no guarantee
this will happen. Often people tend to overlook the resource savings
that come with
Documentation( Technical Writing ), QA and downstream integration
etc. ( they fall into the trap of only count contributions in the form
of code ) which allows for developers to do what they do best focus
their time on the code base itself.
I worked as a sysadmin and QA before becoming developer. Trust me, I
don't won't marginalize those groups. But I don't think this is an area
where we are lacking the most. We have a technical writer, we have QA
and things are reported to us by our users. Some of that traffic might
be bypassing the mailing list, which is unfortunate, but it depends
heavilly on individual people. I know that RPM packages deserve some
love and we are grateful that you, for example, noticed our use of
obsolete init scripts. And feel free to suggest other changes. You
will be heard.
People are unlikely to contribute to a project
they are not
themselves using.
Agreed and if I put on my previous Fedora QA hat on even more
difficult in downstream distribution as in there needs to be some form
of carrot model to get contributors to devote their free time to test
less "popular" but if not more important components.
If you maintain and develop something like a
compiler, standard library, library for parsing some common format or a
picture viewer it will have thousands or even millions of users. And in
that case it is easy to attract sufficient number of contributors so it
starts to make sense to have an upstream governed by some steering
committee recruited from all main stakeholders.
Most projects dont adapt a full blown distribution governing models
but steer themselves based on contributions and trust.
But FRED right now is
not that type of software.
Which begs the question what was the project sight for Fred in the
beginning and what future sight nic.cz has for Fred?
Is your target audience atleast the ca 250 ccTLD'c registries or
more? Do you want to unify and ( try to ) get all the registries to
use Fred?
What are you currently aiming at?
So far it is used in 12 countries, mostly by
sysadmins who have hard time writing C++ or contributing with some
regularity.
That strikes me as bit odd since they should be testing the upstream
releases in a test environment and provide feedback.
Perhaps you guys have written the first ever bug free code yai! ;) but
I somehow doubt it ;)
I'm parsing the mailinglist from the get go ( in 2008 now ) so I will
be able to determine to what extend and how experienced those
administrators are. It doesn't mean that we won't accept a
patch.
It also
doesn't mean that it cannot grow into that area if there's enough
interest.
Is it not more what you see in the future for Fred and if you
want/need to grow that interest?
> But, so far, it is an "undiscovered country" for I think very
> obvious reasons.
>
>> The only way to get their voice(s) heard is to either know the right
>> people within the developer team, or to establish a formal
>> collaboration between universities,institutions, corporate and other
>> entities so that they can co-develop the project together.
>>
>> Basically the open sourcing of the project is done in the strictest
>> literal sense of the word, in that the source code is open for anyone
>> to see but no more no less which more then often than not leads to
>> fork offs..
>>
>> Of the above, which one does Fred fall under?
>
>> <snip>
>>
>> .....
>>
>> </snip>
>>
>> _______________________________________________
>> fred-users mailing list
>> fred-users(a)lists.nic.cz
>> https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users