Problem Statement:
Aeolus projects upstream community is Red Hat, full stop.
It's probably too easy to get caught up in hand waving and just say
"it's important to have a healthy upstream aeolus community." I've
been
thinking a lot about what the benefits really are to having a "healthy"
community, and what it means to be such. I want to keep this real and
not go all academic, but I will add references to really smart people's
research and perspective to add some sort of credibility (because you
guys know I keep booze at my desk and as such might think I've already
started the weekend).
/me pours a shot.
Quickly, the value proposition of having a community (Why it matters
that we create a community)[1]:
* Security
* Affordability
* Transparency
* Perpetuity
* Interoperablity
* Localization
A thriving, healthy open source community is one that yields the value
proposition listed above. Just throwing a license header in project and
making it available for the masses to download is not the blueprint to
building a community. All this does is make the project source code
'open'. Without a community, there simply is no project [2].
Furthermore, we can formulate how the Aeolus projects reach the
mountain-top that is a vibrant open source community - if we agree on
the value proposition listed above as the output of a thriving, healthy
community.
Typical paths to a successfull community
- Seed the project development[3]
- Get feedback from early and often releases[3]
- Attract users of the software[2]
- Attract developers[2]
- Letting go[2]
We, as a Red Hat sponsored group of hooligans, and I mean that in the
most affectionate way possible, have done a tremendous job seeding the
aeolus projects. We've created a metric ton of feature and function. So
if we've built some pretty cool features...why aren't they coming[5]?
It's necessary to address each of the factors at some point, but I'm
just going to focus on how we attract users and developers in this mail.
I think we need to ask ourselves some tough questions and be honest with
our answers.
1. Are we building function and feature that people want (individuals,
entreprenuers, enterprises) to use? If so, is the barrier to setup and
use aelous low or high?
2. How easy is it for developers to get involved and understand the
components involved and then debug, path, contribute changes?
3. Are we doing a good job letting our target users know aeolus exists?
There are plenty more questions we can analyze to come up with a self
evaluation, but I think the above 3 are sufficient for this already too
long email.
- First, did we build something that is useful, I say yes. However, we
built something that is less useful than using most cloud provider
management tools directly (because we went for the common denominator
feature/api base). There are some scenarios in which aeolus is easy to
setup, and there are others that are mindblowingly difficult and
confusing. The learning curve for an admin and a user is fairly steep as
well. If you don't believe me, you probably didn't hang out in the SA
training classes, or you started working on the projects at their
inception and have become blind to the complexities, or you've never had
the floppyinject-hook have its way with you!
- Second, all aeolus developers are Red Hat folks. There are probably a
number of reasons for this: perhaps the components that make up aeolus
don't lend themselves well enough to reuse in other projects, they
aren't puzzle pieces that can be plugged in to solve any other problem
than what we've decided to solve. The design priniciples of each of the
projects differ from one another. The languages themselves used between
the projects are different. The frameworks used between the projects are
different. The protocols used between the projects are different. What
we've done is create an enormous learning curve for any developer that
dares to take on the challenge of contributing (and they haven't even
looked at the development process guidelines at this point).
- Third, we have folks go to a user group here and there, *I think*.
Developers aren't good salesmen or ad-men, in general. Since we are not
creating a market with aeolus, we are way behind a lot of other projects
in this space, we had probably better pony up and do a much better job
letting folks know aeolus exists and is here to take down the
competition, because we're better than them! We need to get a fleet of
folks traveling to trade-shows, meetups, usergroups, conferences. Put
together consistent, professional marketing materials and get it in
people's faces.
markmc made a few suggestions to address making aeolus components more
useful to the masses, and I tend to agree they are great places to start
aeolus components without having to setup all the infrastructure.
(1) Credentials delegation plugin for deltacloud
Add a plugin interface to deltacloud which enables credential re-mapping.
Write a plugin which authenticates the incoming user against its own
user DB and grants any valid user access to a configured set of
credentials
The idea here is to allow deltacloud to be used as a proxy by which
someone can share access to a set of credentials with others, without
actually sharing the credentials themselves
(2) Notifications of interesting deltacloud events
Add a plugin interface which is called with details of any interesting
events happening in deltacloud.
Provide plugins for publishing those notifications over Qpid, RabbitMQ,
ZeroMQ, syslog, etc.
The idea here is that the person sharing their credentials can use this
notifications system to do chargeback
(3) Track resource ownership
If user A launches an instance via the credential re-mapping plugin,
then user B should not be able to see the instance or kill it.
Requires the plugin to have a DB which tracks the ownership of instances
(4) Add instance state change event notifications
There should be a way to have a service monitor clouds (via deltacloud)
for the state of an instance and notify you of changes via a message
bus.
Is this external to deltacloud, just polling via deltacloud? If so, what
credentials is it using to do the polling?
Is it part of the credential re-mapping plugin, since that has access to
credentials? But surely this is useful even if you're not using
credential re-mapping? Does it publish these state changes via the same
mechanism as
deltacloud's notification system?
(4) Add per-user quotas
The admin sharing a set of credentials should be able to set quotas on
each of the user accounts. This is for safety sake, not as a replacement
for chargeback.
The plugin needs to listen for instance launch notifications and
instance state change notifications in order to update the quota usage
of each user.
(5) Extend (1) to support credentials for multiple drivers/providers
(6) Experiment with ways for deltacloud (via a plugin or driver) to map
incoming requests to one of multiple clouds
(7) Explore using Heat on top of deltacloud
Suggested Actions:
1 - take one some of the suggested architectural changes that make the
aeolus components more reusable in projects outside aeolus as a whole
2 - set up a schedule to start marketing the components and aeolus as a
whole, go out and get community members instead of waiting for them to
show up
If you think this is bonkers or if you have any other opinions on how we
can better foster the community, let's hear it.
Thanks,
Chris
[1]
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1656616
[2]
http://www.oss-watch.ac.uk/resources/howtobuildcommunity.xml#body.1_div.3
[3]
www.feedbooks.com/book/4285.pdf (The Cathedral and the Bazaar)
[4]
http://michaeldehaan.net/post/21881841161/my-working-theory-of-open-sourc...
[5]
http://en.wikipedia.org/wiki/Field_of_Dreams
Hm, it seems my mail wasn't delivered to aeolus-devel yesterday,
resending it...
Hi Chris,
It would be best to get the answer on "What are biggest blockers for
community" from community, but since Aeolus community is... not big,
it's up to us to do initial step - thanks for opening this topic.
What I don't agree with is doing some architecture changes because of
hoping we attract some ppl. First, I'm not convinced that the Aeolus
would become simpler and second I don't believe this is a blocker. I
would say that most people don't even get to this level (where they look
at Aeolus architecture). True is that some architecture changes
mentioned in your list are already happening as mentioned in other replies.
As you said, we should let people know that Aeolus exists which we
probably don't do loud enough. Also we should offer them easy way how to
try it. But installing Aeolus on non-rpm systems (and non-rpm systems
are majority) is pretty difficult. I don't think many people pass
through this level. So one of first steps would be creation of general
.tar.gz package(s) which can be installed on any distro (+some
installation script like aeolus-configure).
Jan