Aeolus Community Assessment

Chris Alfonso calfonso at redhat.com
Mon Jun 4 19:39:34 UTC 2012


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-source-project-leadership
[5] http://en.wikipedia.org/wiki/Field_of_Dreams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20120604/96c3d0d6/attachment.sig>


More information about the aeolus-devel mailing list