Expulsion of John Marino - reasons and impact?

Tue Feb 14 20:51:21 UTC 2017

Occasionally we’re called to account for our decisions, reflect upon their
correctness and at times reverse the decision.

John Marino (John) has conducted himself with a passion for making
decisions in the interests of ports' users over many years with great
professionalism and enthusiasm.   At times, this passion exudes into
bravado, even exuberance.  This is not uncommon when sharing deep-seated
beliefs of how things should be done.  Sometimes, perhaps too rarely we see
contrary opinions expressed in the various FreeBSD lists.

As I’ve observed with my first and second level managers, the weak managers
never hire people that challenge their views, or have talents superior to
their own; they hire people with lesser abilities.  To their detriment they
deny themselves the opportunity to grow.  Similarly with community-based
projects, I’m currently a Director of one, in this context strongly
divergent views distract from the singular imperative of helping
others.  Regardless
such views cause, reflection – are we heading in the right direction; are
our actions aligned with our mission; is our strategy meeting the goals of
our customers (the needy in the community); are we properly communicating
and advocating our purpose.  Time consuming and sometimes unpleasant, the
opportunity to review and challenge is worthwhile.

John is significant contributor to the ports user-base, he has advocated
views which represent the needs of the user-community and his expulsion,
the reasons for them and the analysis of his expulsion upon the project
should be communicated, for transparency and reassurance that such
decisions are in the interests of everyone.  This is simply inadequate:

https://svnweb.freebsd.org/ports?view=revision&revision=433827

https://svnweb.freebsd.org/ports?view=revision&revision=433856

I value John’s forthright opinions, and his motivations and contribution to
GNU, Ada, DragonflyBSD and FreeBSD are not unrecognised.  He articulates
his position clearly; his design and development efforts are sound, and the
development of Synth is appreciated.

This lack of transparency suggests that he is divergent, so lets examine
this as a reason for expulsion.

Was it due to providing a choice.  Users of FreeBSD have a choice:

a) build their own build/development system

b) use poudererie - which to me is another layer of complexity and another
source of frequent change

c) use synth - where transparency and is relatively simple to use.

The ports system has undergone significant change over the last 4 years,
much of it needed and requiring significant time and active contribution by
the meta-ports developers.  Unfortunately the cost to those using the ports
system during this time has been significant.  I see John as a stabilising
influence (as Doug Barton was) - is this the reason?

Lets just examine FreeBSD for a moment.  The project is fantastic and so
many different ideas and approaches have collaborated and continue to
progress; I was a saddened when Matt Dillon split from FreeBSD.  Its a
testament to all that there remain, that a high level of exchange and
collaboration continues and John has acted as a conduit and has contributed
in this area also.

So how should we view “The FreeBSD Project"?  Its really split along the
logical boundaries of: the base system, the ports meta-system, and the
ports system.

The ports system is actively maintained by many ports “maintainers” and the
frequency of change reflects the changes to applications (source) that is
under greater scrutiny to be (more) secure.  This is ok, and I’ll come back
to this.

I started with FreeBSD in 2003, when packages were available and this
greatly contributed to my uptake of FreeBSD.  Over time, I needed to
customise my settings sometimes for performance reasons, usually for
security reasons.  I was very happy with the ports system, and I was able
to work-around the changing library versioning issues; but it did need to
be fixed.

Roughly 4-5 years ago pkg and the meta-ports system underwent significant
and needed change. The folks doing this work have done a great job; but.  The
implementation of the changes had a deleterious effect.  The frequency of
change became intolerable, at one point we had 0.25 of an FTE just
maintaining our build systems.  We rebuilt all packages overnight which
enabled testing in the event of critical issues for our clients. Had we
known of the meta-ports flux we would've changed our business model and
commitments to our customer base.

Now we see discussions over whether ports should be supported past the EOL
of an OS.  Seriously?  I had a client that refused OS upgrades, so we
maintained up-to-date ports for around 4 years after FreeBSD 6.1 was
EOL.  Ridiculous
but a credit to the ports and meta-ports developers/maintainers, at the
time.  Our view of FreeBSD being rock-solid was reinforced.  However,
nothing like this should be expected to be supported, though packages
should be able to be built for two or three minor revisions back - if only
to give the people looking after servers a time to schedule and update.  The
current practice of changing the ports system to disable the building of
ports on “older” OS is a disservice.

Another scenario: Lets say FreeBSD X.Y is EOL'ed, a CVE is issued for an
application.  Unfortunately we often hear: "Too bad, they should upgrade."
Really?  If that CVE was say, heartbleed, for (in my case) 1450 servers to
be left unsupported, or according to the current paradigm - require an OS
upgrade is frankly, ridiculous.  When I was the Head of Security for a
minor bank.  I asked "Have you considered FreeBSD for this use?" - instant
derision.  Lots of reasons, little to do with the FreeBSD base system.  Draw
your own conclusions.

Microsoft got it right.  Users want applications, and they will rely upon
the OS to provide a solid and reliable base.  The FreeBSD project has
dedicated and enthusiastic port maintainers.  They can, do and should
upgrade their ports with a tempo that maintains significance (for features,
fixes) and timeliness (security); however the meta-system should be subject
to the same rigor as the rest of the FreeBSD development to convey a sense
of reliability and stability.  FreeBSD base development progresses with:

- an idea

- discussion

- code development and availability for open review

- development and placement into current/head, further review

- move the developed code into stable - further opportunities and testing

- beta cycles

- release candidate cycles

- Release!

vs the ports meta system.

- an idea

- code

- release into production (at times re-release into production the same day)

This isn’t to say the developers are wrong in their pursuit of enhancing
the environment, which is commendable, rather this should be performed
against a plan or schedule and perhaps notification of what’s coming or
about to be changed so Admin’ers can plan and schedule their work.  This
comes back to governance.  And we need to remain cognizant that not all
FreeBSD users are in first world countries; with multiple boxes available
for build/testing.

If anyone is challenging the way things are, and trying to make the various
FreeBSD domains better, good luck to them.  The FreeBSD Foundation should
be providing sound governance, and develop an advocacy program to RETAIN
those that currently use FreeBSD, instead I'm witnessing departures at a
disconcerting rate.  It might say something about the SAMBA project, but I
had maintained separate email folders from the SAMBA and FreeBSD lists
since 2005; the level of interaction/discussion on these, relative to each
other has dropped alarmingly (ie SAMBA remains high)

So when someone makes a significant contribution, is an advocate for
excellence - forcing them out raises serious issues about the management of
the ports system and the overall governance provided by the FreeBSD
Foundation.  This calls into question the relevance of FreeBSD’s ability to
continue to provide a reliable, solid body of work that Server owners in
particular, are proud to use and advocate.  Transparency, sound judgement
and the criteria for rejecting high-value contributors are the issues here.
And when someone with John's talent is being pushed out, then the wider
community should be made aware of the circumstances and the criteria.  (For
the record, I've disagreed with John on something years ago - the discourse
was invaluable, as John is at times a forceful antagonist which as history
shows, is often, and at times unintentionally, of great value.  BTW we use
portmaster as it is fit-for-our-purposes; though we have (had) plans to
migrate to Synth)

FreeBSD is an amazing operating system, I’ve read every svn entry into
stable for the last 4 years – unbelievably smart people.  I use 1037 ports
from the ports tree, and value all those that contribute their time and
effort to the betterment of computational “stuff”; the features and the
productivity that are provided.  There are areas that need to be improved,
and I think that John contributes positively (albeit abruptly) to the
Project.

At the very least we should know why, and by what criteria he is judged?

Regards, Dewayne.

PS I'd prefer to be silent and let things run their course - but that would
be seen to acquiesce with something that I perceive as harmful to “The
FreeBSD Project".

-- 
*Disclaimer:* *As implied by email protocols, the information in this
message is not confidential. Any intermediary or recipient may inspect,
modify (add), copy, forward, reply to, delete, or filter email for any
purpose unless said parties are otherwise obligated.  Nothing in this
message may be legally binding without cryptographic evidence of its
integrity and/or confidentiality.*