Recently in gooseproject Category

GoOSe Project Collaboration Manifesto

| No Comments | No TrackBacks

This document is a copy. You can always find the canonical copy here.

The GoOSe Project is only one of the upstream enterprise Linux rebuild projects. We are excited to work together with others in the EL rebuild space, and feel that there is plenty of room for separate but collaborative communities. The similarities in our goals should work for our mutual benefit. And the differences which exist should only strengthen us all.

So we need to answer this question:

In what can we collaborate?

What follows are the results of a pretty free-form brainstorming session we had at one of the GoOSe Project's weekly meetings.

  • Shared infrastructure

    Sharing certain pieces of infrastructure makes a lot of sense.

    • Upstream Sources Mirroring -- Although there are various places that one can find the upstream sources having another collaborative mirror for the various rebuild projects could be beneficial.
    • Cross Project Backups -- Doing backups is difficult, if we spread out the load of backing up our repositories, scripts, look aside caches, configuration files we could restore in the case of a catastrophic failure
    • Project Mirroring -- Distributing the final product of our efforts can be daunting as well. Again, being willing to mirror the ISOs or packages of the other projects will help make all the products better accessible.
    • Help Building and Configuring Non-Shared Infrastructure -- Most of these projects are using the same or similar tools, Koji for example. Working together on setting up these systems will help reduce the amount of constitutional knowledge(better phrase here?)
  • QA help

    • Building QA Test Suites -- Due to the common ancestor of these projects, a common set of test cases could be useful. This should be extensible/fork able for the test cases which would be specific to a certain project.
    • Cross-QA Checks -- A very good way of testing if something is correct is having someone else run the same test as you. Sharing the QA work and results would reduce the need for everyone to figure things like this out for themselves. I think the best example of this would be the information needed to verify ABI compatibility.
  • Documentation

    Of the many places where EL rebuild projects can easily collaborate, the best return of investment is sure to come from the documentation side. Again the common ancestor of these distribution works in our favor. There is a great need for documentation and how-to's. Sadly most good documentation is out of date. Thus a collaborative documentation effort would help lighten the load and keep things better up to date.

    Other documentation-like ideas include common wikis, a common askbot-style system, etc.

  • Distribution Creation Information

    The main product of all these different projects is a Linux distribution. Sharing the problems and various solutions to compile and create this product helps to make the entire community better. Things to share include:

    • package build order
    • package meta data
    • package content signatures
    • ABI compliance information
    • upstream trademark issues/problems
    • missing build dependencies
  • Community Enhancements

    As the number one goal of the GoOSe project is to build the community, we spend a lot of time thinking about the ways to enhance the ENTIRE community ecosystem. We plan on sharing what we learn for best practices for:

    • community management
    • meetings
    • organizational structure
    • updates to your community about your progress

    We also plan on working on spreading the word about our community goals. Some tools to help us accomplish this include:

    • EL Rebuild Planet -- Would others be interested in joining this?
    • Social Networking -- Twitter, Identica, Facebook, etc.

    We also want to practice what we preach about making this truly a community based idea. Please fork and update this document to help improve it.

With a stronger community around our projects we can all have a better time accomplishing our goals. And hopefully making the world a little bit better than we found it :).

Introducing the GoOSe Project

| No Comments | No TrackBacks

Introducing the GoOSe Project

Recently I blogged about how some friends and I were talking about what it would take to rebuild an enterprise Linux project. We started researching what we would need and we got started. The result? The GoOSe Project.

What is the GoOSe project? It is a community rebuild of an enterprise Linux distribution based in the USA. But it is also more than that. The GoOSe project is more importantly a practice in building an Open Source community. We wanted to practice what we preach about how best to build a community. It just so happens that the product that this practice produces is a Linux distro.

Why "GoOSe"?

The name of the project was just a bit of riffing done on IRC(look around 20:03.38). We have quite a bit done as far as getting things rebuilt and have some ideas as to how we want to run this community. We have an ethos. A Koji instance running our builds. And we are just about done with the Buildroot needed to make a fully functional system bootstrap.

The GoOSe project is "in progress" to getting the first build out. We are currently just about done with the first step which is to compile all the upstream packages into a buildroot we can use to compile our packages. A more detailed status update will be blogged about later.

Why another rebuild project?

As I mentioned above, community is the hard part. And although there are various other projects similar to ours, we think we can fill a certain niche.

The centOS project for example is probably the biggest rebuild project out there and it caters to those who are looking for a 100% drop-in replacement for the upstream Linux distribution. Scientific Linux is built as a base for supporting computing clusters and experiments.

The GoOSe project is not out to replace or out-do any of these projects. We are here to build a community of passionate folks to build the best community-based enterprise operating system around. We will be sharing everything that we learn, everything we modify, and everything we build to help use create this distribution. We all benefit from an improved community structure. We also benefit from having more than one project meeting different goals/niches. The things we learn also help all the other projects out there to have a well functioning system themselves.

GoOSe Goals

Our goal with building the GoOSe project is to have a cool community built around an easily constructed set of enterprise-grade software. The technical pieces of the equation taking the hard part out of building an enterprise operating system. Herlo said it best when he said this with regard to the vision of the project:

"[I see the GoOSe project as a] group of friends hanging out, building cool things with an enterprise-ready technology. Not exclusive to building the technology itself."

Come help us

We're already working away on these goals. You can come and help us. Here are some resources to get you started:

There is still plenty to be done. Come join us. It'll be fun I promise.

Nagios Config Template -- Goozbach rewind

| No Comments | No TrackBacks
Last week I got an email out of the blue.

it said:

While trying to organize a complete mess of an nagios install (half borked
by a nagiosql install) I ran across a post where you offered up an example
of your nagios configs. The link is now password protected, I know the
post is over 2 years old and things change....but I was wondering if you
still had that info available?

I did poke around your github but didn't find any nagios info.

This email was in reference to a comment I made to this blog post by the Standalone Sysadmin.

Well recently I re-did my webserver and the link mentioned in that comment has disappeared. So I took the time to drop the previously mentioned config template into a github repository.

I should mention that I've not done any Nagios work in a few years now, and moreover I only dumped the contents of the tarball mentioned in the original comment into the github repo without any changes or updates. So I don't know how well this would work with more recent Nagios configs.

If you find it useful, drop me a line.


Step 0 -- Build a Community

| No Comments | No TrackBacks

In a recent blogpost I discussed what would be needed to start a rebuild project based on sources provided by a prominent Linux distribution.

Some friends and I started working towards this goal. We quickly determined that as interesting and difficult the technical problems and hardware needs for such a venture are, they are surprisingly the easy part. Much more difficult is the task of building a community.

Community is Key

The key to any vibrant Open Source project is the community behind the project. Without a living, breathing community, any project is doomed to end up dead.

Analyzing other Open Source projects out there I discovered there are two distinct communities involved with any “successful” project. The contributor community and the user community. And yes one is a sub-set of the other (or ideally would be). These two communities are symbiotic as well.

Contributor Community

The contributor community is the core of a project. It consists of volunteers working on task relating to the creation, improvement, and release of a project. Without the contributor community the project could not exist. This isn’t to say the contributor community works in a vacuum. The contributor community relies on the user community for a few things:

  • First and foremost: Validation. Working on an Open Source project is a labor of love. Volunteers give a great deal of their time, talent, and work to an Open Source project. A vibrant user community validates the work of the contributors.

  • Second: User base. A project without users is a business without customers. No users; no project. The more users a project has the more willing contributors will be to work on the project.

  • Third: Feedback. There’s an old maxim: “Many hands make light work.” The Open Source equivalent to this is “Under many eyes, all bugs are shallow”. The larger the install base, the more likely quality bug reports will be generated and problems will be found and fixed.

User Community

The other half of the project exists in the user community. The user community consists of those who download, install and use the project in their daily work. The user community depends on the contributor community for few things as well.

  • Number one: A Quality Product. People are using large Open Source projects in the core infrastructure of their businesses. A quality product makes this possible.

  • Second: Transparency. Given the importance of a quality product. Users are eager for updates. These can be either security updates, new features, new releases, or just “we’re working on these problems”. When you develop your project “in the dark” users will start to get leery. If you miss big releases regularly they start to loose confidence. Fear of a dying project can lead users to find alternatives or to fork the project themselves.

  • Finally: Permanence. The user community depends on the contributor community for permanence. Open Source projects are living things and require constant care and feeding. They have their own life cycle. Open Source projects are created by volunteer forces. Those volunteers’ priorities change, they move on — for whatever reason. A completely open development model helps overcome these speed bumps that can affect a project. Some recent events come to mind with regard to the movement of a community:

Another item to think about is reducing the “bus factor”. The access to the entire project should not be limited to one member or small group of members of the contributor community. It should be available to all of the core trusted team. See CentOS Project Administrator Goes Missing.

The ultimate answer to all of these concerns is to make the entire project VERY easy to fork. Using new distributed SCM tools makes this pretty easy. The ideal Open Source project should be able to be completely forked in a weekend at the longest.

Community Trust

When the user community and contributor community trust each other, things really start to happen. More contributors show up to help as they feel valued and want to participate. The stronger contributor community means a higher quality, better trusted project. The higher quality project then attracts more users and the feedback cycle grows. The output of this feedback cycle is better support, and a better product.

Attracting Contributors

After defining what the communities are and what they want, let’s talk about how to attract more people to both. To attract people to the contributor community you have to have a very low barrier of entry for contributions. I’ve found one of the easiest ways to do this is with a tool which allows for easy contributions. One such tool is GitHub. The manner in which you contribute to a project on GitHub is easy:

  1. Fork the repository

  2. Make changes in your fork, and push the changes back to GitHub.

  3. Send a pull-request.

  4. The upstream project will accept or reject your change set.

This low barrier of entry for a contributor also works as a great apprentice method. As people show their competency through things like these pull requests, they can easily be apprenticed into the core group of contributors. This makes your project a true meritocracy. This apprentice system balances access with trust, and gives a clearly defined path from user to contributor.

In order for this apprentice system to work you need to have a list of todo items. Ideally this list would be full of low-hanging fruit for apprentice contributors. Things such as improving documentation, or adding an additional feature or simple bugfixes are good examples.

Advertising the hard problems your contributors are working on in a todo list or using blogging/social media give a potential contributor a good idea of what is in store with the core team. The fun part of being a contributor is to work out how to solve the difficult problems.

Attracting Users

The easiest way to attract users is to have a high quality product. Another important tool for attracting users is a vibrant, open collaborator community.

Regular releases are key. Users (rightly) see regular, on schedule releases as a sign of a healthy, mature project. Usually the first signs of a dying or dead project are the lack of regular updates, or delayed updates with no explanation.

Users expect communication from the contributor community. This communication is multi-pronged. Good bug reports are a key form of communication. Bugs should be “scrubbed” regularly looking for bugs which are show-stoppers and when a bug is fixed the “fix” and when it will be packaged should accompany every bug closing.

Other communication channels include the project’s documentation. Documentation is something which can lag behind very easily. Ideally the documentation for a project is auto-generated directly from the source code. If auto-generated documentation isn’t easy to do, then a documentation team should be part of the contributor group.

The project should also have a blog. This blog should entail interesting problems being faced, the current status, highlights of people who are working with/on the project. There should also be a planet for all the people who have an interest in your project to share their entries. To drum up traffic, the main blog could feature something from the user’s planet regularly.

Social media is another avenue for attracting users. Getting the news out on new releases, or other news items is easily done using the various social media sites.

Holding your meetings in a public place is another way of being transparent to your user community. Ideally these meetings would be in a medium such as IRC so there is automatically a transcript or log of the meeting minutes.

There should also be a status page where users can quickly get an idea where the project is with regards to its goals. Things to include here would be tasks needed to finish the next release, show stopper bugs/issues, automatic updates from the various tools used in the project, and any other information like that.

In Closing

A community is key to making an open source project work. Cultivating community should be the first priority of a project. A well groomed community spirit, will do more for a project than any technological advances or fancy tools any day. Remember the folks who would work on something need motivation. I for one would do it again for free.

Stay tuned for step 1 and finally an official announcement of what this lead up is about.

Bootstrapping a RHEL Clone

| 1 Comment | No TrackBacks

There was some interesting action on the CentOS mailing list recently which stemmed from a tweet posted by Dag Wieers.

The question posited is: "How does one rebuild RHEL in a timely, open and collaborative way?"

Well, a few of my UTOSC friends and I did a little brainstorming and came up with what we think a good bootstrapping infrastructure for just such a project would entail: