On Thu, Jul 03, 2014 at 04:01:16PM +0400, Loganaden Velvindron wrote:
>
> I see such trends as leading to dangerous situations in the future.
> OpenSSL is widely deployed, and the developers appear to grow older,
> according to the various interviews I read. (I don't wish to offend
> any of you guys here). What happens if something happens to the core
> developers ? Who will take over ?
>
> The roadmap is nice, but if we don't get young developers who can work
> their way to maintain the OpenSSL codebase, we're going to hit a huge
> problem, in 10 years :-(
There are two several issues being conflated here. One is how
security disclosures get handled and who gets access to things like
free open source Coverity scans. In the linux kernel, we do have a
closed secur...@kernel.org list, but that's separate from those core
maintainers, and things only kept quiet a relatively short period of
time --- typically only a week, and the distributions know and expect
that they need to turn around a new package in a short window of time,
but that's Linus's strong preference since he doesn't believe a longer
window does anything but reward incompetent release processes at
various distributions. (Given that Microsoft has weekly "patch
Tuesdays", if even slow moving *Microsoft* can turn around a security
update in a week, what's your excuse? :-)
However, in the kernel we are much more lax about who gets access to
the Coverity project. Part of this is the sure and certain knowledge
that the bad guys are quite willing to pay for a Coverity license, and
so for us the balance of increasing the pool of those can who are
looking through the Coverity scans, and contribute to fix bugs, and
thus grow the development community, tips in favor of being more open
about who gets access to Coverity.
This is in turn *completely* different from who participates in the
development community. Note that with git, you don't have to have
committer access in order to contribute. In fact, with Linux, only
one person --- Linus Torvalds --- has access to merge in changes into
the tree, and while we don't have a closed mailing list only open to
committers, that's because Linus isn't known to be Schizophrenic, so
he doesn't talk to himself, and he certainly doesn't need to conduct
closed votes amongst himself. He's a *dictator*, after all.
And yet, the Linux kernel has a pretty healthy development community.
I'd submit that the better metric of developer community health is
looking to see who has actually authored patches that have gotten
merged into the git tree, on a monthly/quarterly/annual basis. And in
fact, I'm trying to see if we can get the folks who are doing the
annual "who writes Linux" reports can do a similar analysis on the
OpenSSL git tree, and make the results public for all to see. After
all, as the saying goes, you get what you measure.
I personally think that sending patches for review on the mailing list
is actually healthier than just hiding it in request tracker or github
pull requests, since it invites a much larger set of people who has at
least *looked* at the patch. But that's an implementation detail, and
as someone who isn't an OpenSSL developer, I don't have standing to
make suggestions like that. And also, does it matter? If a year from
now, the statistics show that patches aren't getting merged from a
growing set of people, one of the wonderful things about git is that
it makes forks so much easier. And if a bunch of young Turks are
upset that the old dinosaurs aren't letting them into the clubhouse,
they can always fork the git repo and make their own version --- and
that's a good thing.
Because when it's that easy to fork, paradoxically it changes the
incentives to make forks much less likely --- and if they do happen,
git makes it a lot easier to merge and cherry pick changes back from
forks into whatever development tree is acknowledged by the majority
of the development and user community as being the mainline branch.
It was really important to Linus Torvalds that his tree not be special
compared to any other tree in the git "forest", for this very reason.
Cheers,
- Ted
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
