Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@community.apache.org
MIME-Version: 1.0
From: Christopher <ctubbsii@apache.org>
Date: Sun, 23 Apr 2017 20:48:13 +0000
Message-ID: <CAL5zq9YfTifg4b6xcycUZR-zh2d3VBCS=CH1zvfxAnGTWxrGPA@mail.gmail.com>
Subject: Possible ApacheCon BarCamp topic
To: ComDev <dev@community.apache.org>
Content-Type: multipart/alternative; boundary=001a114595549e1f0a054ddb9ce1
archived-at: Sun, 23 Apr 2017 20:48:28 -0000

--001a114595549e1f0a054ddb9ce1
Content-Type: text/plain; charset=UTF-8

Unfortunately, I won't be flying in early enough to attend the BarCamp in
Miami, but I wanted to suggest a possible topic, if anybody attending
wishes to pick it up for discussion there:

Topic:
Establishing and strengthening relationships with downstream packaging

The premise:
Official ASF releases are source artifacts. Some users build from source or
use "convenience binaries" published by ASF projects, but many (maybe
most?) users experience Apache projects through a vendor or through their
operating system software repositories (RHEL/CentOS, Fedora, Ubuntu,
Homebrew, MacPorts, PyPI, RubyGems, etc.). Downstream typically falls into
one of three categories: the DIY user, a commercial vendor supporting many
users, or a community packager supporting many users. "Convenience
binaries" produced within the ASF fall into the third category (one of many
in that category). Though they may have different requirements, each of
these categories have a similar relationship to our upstream software
developer communities, and they are all important for project growth (the
importance each plays in a particular community can vary significantly). I
refer to all three of these as "downstream packagers" or simply "packagers".

Some ideas for discussion:
1. How can we approach packagers to make our software available to their
users?
2. How can we support packaging to ensure a positive experience for both
packagers and end-users?
3. How can we grow our upstream community by encouraging contributions from
packagers?
4. How can we build our software with build- and runtime-flexibility, to
support the different target environment requirements of many packagers
(rather than just a few)?
5. How can we work with packagers to deal with "dependency hell"?
6. How can we simplify/modernize build systems to make it easier for
non-committers to build from source?
7. Which responsibilities are that of the upstream project, and which
should be deferred to downstream?
8. How do new packaging/distribution technologies, such as Docker, Mesos,
and Yarn, change the traditional relationship with packagers?

Conclusion:
Some ASF projects (such as httpd, subversion, ant, and perhaps now maven)
seem have had a lot of success via these downstream community packaging
routes (as have other non-ASF open source projects, like Firefox, MySQL,
PHP, Ruby, etc.). Other ASF projects, however, may still be unclear how to
relate to downstream and what that relationship can bring to the project's
upstream community.  So, I think this could be a potentially valuable topic
to discuss.

Extra:
As both a Fedora packager and an Apache contributor, as well as an
occasional HomeBrew, and frequent DIY user, I find this topic fascinating.
Whether or not it gets discussed at the BarCamp, feel free to reach out to
me during ApacheCon. I'd love to discuss these (or any other) topics over
drinks or lunch or between talks.

P.S. For those unfamiliar, Apache even it's own "downstream" packager
project known as BigTop, that I encourage checking out (and possibly
contributing to).

--001a114595549e1f0a054ddb9ce1--