On Thu, Jun 07, 2012 at 11:34:28AM -0400, Hugh O. Brock wrote:
Thanks to everyone who has weighed in thus far.
I think it's fair to say two or three things based on what I've read:
* Everyone agrees we aren't doing enough to talk up the project and
evangelize it and we need a whole lot more planning around
that.
IMHO, this ought to be the top priority here.
* Everyone agrees that we do a lousy job of making the project
consumable to non-RH developers -- we should have tarballs
available, if possible we should have things broken out into
rubygems, our configure stuff should be platform-agnostic, etc.
* Everyone is deeply skeptical of top-down rearchitecture for its own
sake, and, I dare say, deeply skeptical of architecture in general.
To all of this I say, excellent, absolutely correct. We can move
forward *right now* on making what we have much friendlier and more
consumable, and we can move forward in the very near term about making
evangelism and "talking up the project" happen. I'd like to challenge
those of you who have responded thus far to propose the following:
1. A concrete plan for making the bits consumable for developers on a
wider set of platforms. You define the set, but OSX should probably be
part of it since we're in the Ruby world.
Jay's been doing some good work on getting Aeolus to work without the
RPMs, or at least Conductor. There's probably a whole lot more we need,
but it's at least a good step in the right direction.
2. A concrete plan, or at least some good ideas that we can turn into
a plan, for getting more developer attention. Propose anything you
want.
I think more developer attention is great, but more *user* attention is
even more important, IMHO. We've been building this thing for a really,
really long time. I'd like to get some users and see if we meet their
needs before we go on building more without much input. (This isn't to
say that we should stop development, or that I wouldn't be ecstatic to
have more outside contributions... Just that I'd be even more ecstatic
to have more users who give us good feedback.)
Now, I've also read a surprisingly spirited defense of the
Conductor-and-friends architecture as it currently stands. I want to
make absolutely clear that I do not care what the architecture is, and
that even if I did I wouldn't tell you :). However I'd like to suggest
a couple things I think the community should be thinking about in
having these discussions.
1. Successful open source projects do one thing well;
2. Successful open source communities aren't tied to the success or
failure of a single project within that community.
(Thanks to Steve Dake for doing a great job of articulating these
points).
I think it's pretty clear that Aeolus as it is currently constituted
does not meet either of these criteria. I would challenge folks on
this list to imagine what the Aeolus ecosystem would have to look like
if it did meet them.
It's a half-baked idea on my part at best, but I wonder if, instead of
trying to break Conductor up and cram it into Deltacloud, we should be
looking at breaking Conductor up and making it a series of
independently-useful components that handle the stuff Deltacloud doesn't
solve -- an authentication service, manager of quotas and permissions, a
secure keeper of cloud credentials that releases them only as
appropriate, a component for polling cloud providers through Deltacloud
and firing updates on changes to those that register hooks, a means of
intelligently launching on a provider, and a slick web GUI that sits on
top of all of it.
But my problem is -- is this actually any better? It feels like maybe
the code would be more maintainable and it might be nice for me to have
my little niche on one of the projects. But is there anyone that would
set this up and *not* want a means of watching for updates, nor *not*
want to store cloud credentials?
-- Matt