Empty Thoughts

Since I published my introductory post on the django-command-extensions project, I have not posted any additional updates regarding the project. Quietly, there’s been tons of work happening, and so I thought I would give some visibility to all of the great contributions to the effort.

As a review, the django-command-extensions project is a repository for collecting global custom management extensions for the Django Framework.

Since the project was started there has been an additional twelve commands added. The bulk of the work has been headed up by Ido Sebastiaan van Oostveen, with some additional work by Doug Napoleone and Ludvig Ericson. Personally, I haven’t had much involvement in the development beyond a few initial commands. Although, I have been a satisfied customer of the extensions, such that it has become a staple for all of my Django projects.

So on to the fun stuff. Here’s a list of commands in the project:

• create_app – creates an application directory structure for the specified app name. This command allows you to specify the --template option where you can indicate a template directory structure to use as your default.

• create_command – creates a command extension directory structure within the specified application. This makes it easy to get started with adding a command extension to your application.

• create_jobs – Creates a Django jobs command directory structure for the given app name in the current directory. This is part of the impressive jobs system.

• create_superuser – makes it easy to create a superuser for the django.contrib.auth.

• describe_form – used to display a form definition for a model. Copy and paste the contents into your forms.py and you’re ready to go.

• export_emails – export the email addresses for your users in one of many formats. Currently supports Address, Google, Outlook, LinkedIn, and VCard formats. I have found this really handy.

• generate_secret_key – creates a new secret key that you can put in your settings.py module.

• GraphModels – creates a GraphViz dot file. You need to send this output to a file yourself. Great for graphing your models. Pass multiple application names to combine all the models into a single dot file. This one is very useful with lots of options for flexibility. See the wiki page for detailed information.

• passwd – makes it easy to reset a user’s password

• run_job – run a single maintenance job. Part of the jobs system.

• run_jobs – runs scheduled maintenance jobs. Specify hourly, daily, weekly, monthly. Part of the jobs system.

• runprofileserver – starts runserver with hotshot/profiling tools enabled. I haven’t had a chance to check this one out, but it looks really cool.

• shell_plus – An enhanced version of the Django shell. It will autoload all your models making it easy to work with the ORM right away. I use this every day. It is so handy.

• show_urls – displays the url routes that are defined in your project. Very crude at this point.

• sqldiff – prints the (approximated) difference between an apps models and what is in the database. This is very nice, but also very experimental at the moment. It can not catch everything but it’s a great sanity check.

On the documentation front, Ido has been actively putting together some installation and usage instructions to help people get started. We still have quite a few undocumented commands so if you would like to pitch in, we appreciate your help.

If you like using Mercurial, Ido maintains a Mercurial repository for the project. You can find more information on using his repository on the wiki page.

I would like to thank Ido Sebastiaan van Oostveen for his help. He’s really taken a leadership role and contributed a lot of great stuff. Additionally he’s been fleshing out the documentation and managing the tickets / patches.

Finally, if you would like to get involved in the project, we’re always looking for people to help out. Feel free to submit patches or bug / enhancement reports. If you would like to contribute directly, please let me know.

I like to support open source projects. I think it’s vital to the survival of the community, and I think in a very small way it makes it possible for me to provide encouragement and thanks to the people in the trenches doing the heavy lifting each day to benefit the community at large.

There are a lot of different ways to support open source projects. There’s individual contributions (patches), time, money, attention, and probably many other methods. Each of those things is important, but this post is specifically about money.

On a personal level, I’m a frequent contributor to open source projects and blog tip jars (when they’re available) when I stop long enough to remember that I am only where I am at today because of the contributions of others. I may only contribute $20 or $50; sometimes more, sometimes much less, but that’s not important.

What is important to me is that I have the opportunity to contribute to these projects in a way that makes it easy, in a way that keeps me honest, and in a way that helps me realize I’m participating in a much larger goal that is making a difference.

The Idea in Summary

I say all of the above as background for an idea that has been running through my head for a long time. The idea involves a way to make contributing to an open source project more accessible to people that want to do so. It also involves making the receipt of contributions by an open source project simplified and more readily available. In addition, it aims to do it all in a way that would provide a foundation of lasting supporting, while making the whole process transparent.

So how does this idea differ from an open source project deciding to put a PayPal button on their web site, and individuals seeing those buttons and donating? Well that approach by and large has been shown not to work. Few people ever make contributions. I’m not sure why it is, but that’s generally been the case.

I also realize there’s lots of foundations that have a sole purpose of supporting a particular technology, through accepting donations as well as by holding conferences and promoting their brand. Plus, there are organizations like the Free Software Foundation who work hard to evangelize the benefits of free software, and work to protect the rights of those that are creating that software.

Even so, none of these solutions address the challenge of making needs in the open source community visible and providing an easy avenue for individual donors to contribute. There are Web sites like Pledgie, which are a free-for-all platform for collecting donations, but there’s no real oversight and it is all over the board.

About two months ago I finally formulated my ideas enough in my head that I decided to put some things down on paper. The following is just a stream of thoughts that I put together.

The Details

Support Open Source Foundation (SupportOpenSource.org)

Foundation to manage investment and payout of support for open source projects. A not-for-profit 501(c)(3) organization. Goal is to encourage investment and support of open source projects and provide a mechanism for streamlining that investment in a way that will build a foundation for investment in perpetuity.

The organization will strive to keep as much of the money as possible supporting the projects. In other words, it would only be looking for infrastructure and bandwidth costs, and possible administrative fees, like investment costs, cutting checks, bookkeeping.

The organization would provide complete transparency, publishing a record of all money and where it is going.

There would be a guiding board of directors.

How it Works

Money is donated by individuals or organizations where they can specify particular open source projects to support, or just specify the type, area, or size (other attributes possible) of open source projects they want the Foundation to vet and support. Regardless, money is distributed according to the wishes of the donor.

The money becomes part of a permanent endowment where funds are perpetual funds, the assets of which are owned and invested by the Foundation. The income earned is paid to the open source project the donor designates. Any person may make an addition to the fund at any time.

The agreements will have annuitants (immediate payees) as well as contingent annuitants, where the money will go in case the primary annuitant quits. (There’s obviously a lot of things to think through here. What if someone is taking donations but producing nothing?)

Donors can also choose a Received and Paid Out agreement as well. This would be the case where the donor wants to donate a certain amount and have it paid out in full immediately. This would be somewhat similar to how Pledgie works. The Foundation would encourage donors to choose a permanent endowment option over this option, because of its long term benefits to the project.

There is a lot of different variations on this theme and the specifics can be moved around in different ways, but the concepts are there nonetheless.

Getting the Word Out

1. Talk to larger organizations about how they are all relying on open source projects to keep their businesses running, and how their contributions will help these projects continue to be improved and supported. Discuss various open source projects, those that are in the systems area and those that are used in various development areas, like Tomcat, Ant, nUnit, nAnt, DotNetNuke, PHP, Python, Ruby, Ruby on Rails, etc… Request support of these projects.

2. All open source projects that receive support will have to agree to place a banner ad (nothing too crazy just a small square or something) on their site indicating that they are supported in part by the Support Open Source Foundation.

3. Get the word out to the more well known bloggers and ask them to talk about this. Most of them are using WordPress or similar products, which are open source.

4. Possibly, any non open source projects can place our banner ad on their site and receive “google” ad type revenue for traffic that they send to our site. This would be for sites such as blogs. This is a bit touchy, but it could be a mechanism for allowing bloggers, that support open source through their writing and product evangelism to receive support while also supporting the Foundation.

The Site Itself

Create a site that is easy to use, with a clean design, and informative. Provide features that allow open source projects as well as donors to manage their “accounts” and see the activity towards projects. Some features would be:

1. Allow people to submit their projects. We would need to vet them. We would need to establish qualifications for allowing their project to be considered. This is going to be tough. We’re mainly looking to be sure these are legitimate projects, that have been kept up to date, and have some appeal. Although, the appeal thing has to be carefully considered.

2. Ability to show “statements” on the various projects about how much has been donated, how much they have received to date, and so forth. Show who donated (if not anonymous) and how much.

3. Allow donors to donate anonymously. Allow donors to donate in honor of someone else. Maybe have different levels of donors, so we can encourage greater levels of donation (i.e platinum donors or something), but be sure to not denigrate those that donate smaller amounts.

4. Probably have some feature that allows projects to set project goals or milestones.

5. Have donor pages where the donor can privately see their activity, how much they’ve donated and to whom.

6. Make banners available where donors can put them on their site if they want to let other people know that they are supporting open source projects and to encourage others to do the same.

7. Very flexible searching. We can do a ton here.

8. Project of the Day. Feature one open source project each day and discuss it in depth. Get someone to do the research, possibly small podcast with the developer(s). This could really rock if done properly.

Some To Do Items

1. File the paperwork to get things going. Apply for not-for-profit status.

2. Develop the site

3. Begin gathering together a board of directors.

4. Get financials in order, such as bank accounts, investment accounts, accounting books, etc…

5. Begin pre-filling some open source project information.

6. Contact open source project leaders and let them what we’re doing. Get feedback on the site, and the process. Incorporate feedback.

7. Rollout site and make formal announcement.

8. Start getting the word out

9. Begin to rollout things like featured project, podcast, and viral marketing ideas.

So Where Do We Go From Here?

So why have I posted this? Well, just because I didn’t know what else to do with it. I have sat on it for a long time. I’m not totally convinced it is a worthwhile endeavor. I’m also not willing, at least at this point, to commit the time required to pull something like this off. At least not alone. I guess I’m throwing it out to the wind to see where it flies. Perhaps people will say it is a waste of time. Perhaps not. What do you think?

This post may be the first and last that you hear of this. I don’t know what I will do or if I will proceed in any way with the above. If you’re passionate about it, run with it! I’ll support you in any way possible. If I change my mind and decide to move forward with some of these ideas, I’ll keep you updated.

Regardless, I will continue to support open source projects and make community contributions on a personal level. Being able to do so makes me feel I’m truly one of the lucky ones.

If you have global custom management command extensions or if you have suggestions for some that would be useful to you in your daily work with Django, we want you. Yesterday I posted a new project on Google Code, called Django Command Extensions, that will hopefully grow into a nice repository of custom management command extensions. Currently I’ve included the following three commands:

• describe_form – Writes out a newforms definition to the console for the specified model

• create_command – Generates a custom management command directory structure in the application specified, which makes it easy to get started creating your own commands.

• generate_secret_key – Generates and displays a new secret key that can be used in your settings.py module.

There’s no documentation at the moment but that will come shortly. The application should be installed on your python path like all Django applications. Your Django framework must be at least updated to Changeset 6047.

Join In

Here’s a couple ways you can help out:

• Become a Committer – If you’d like to contribute to the code please let me know and I’ll add you.

• Test – Use the commands on various operating systems, different environments. Give us feedback.

• Make Suggestions – If you have ideas about how we can expand the functionality of current command extensions or if you have a suggestion for a new command extension, let us know.

• Documentation – Like to write documentation? Okay, but would you be willing to? Let me know.

If you need help getting started in creating your own custom management commands please check out the screencast I did on the subject.

The code is licensed under the MIT license.

Pretty amazing stuff. See Scott Gu’s post on the subject.

http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx

Now I don’t have to spend so much time in Reflector