michaeldehaan.net

Have you ever noticed some open source projects are more open than others? Most folks don’t realize this is a problem, but I think it’s one we can help solve by showing others the path of some things they need to do IN ADDITION to just open sourcing code and putting something on sourceforge. Putting a tarball out on source forge and having a web page isn’t enough, in order to fully capitalize on what open source can offer (free word-of-mouth advertising, patches coming in unexpected, testing help, ideas, extra development help, etc), here’s a few metrics to try to achieve. I don’t pretend to be doing any of these perfectly, but it’s what I hope to see from any application — not an absolute requirement, but something to strive for. And, I’ll warn you, it takes a lot of work. Thankfully in Fedora-land, we have lots of experience and lots of apps are doing it the right way. So, without further rambling, here’s a list:

(A) A rather simple goal — You have lots of happy users that don’t work for your company. Willing users mean adoption and you are filling a need that other people have. If you don’t have users, either you need to advertise a bit more or you need to figure out why folks aren’t using what you are producing. Maybe it doesn’t fill a need, maybe it is too complex, maybe it’s not complex enough. It is FANTASTIC if you decide to open source a component that your company is using internally, but it is even better if you can spend some time to try to build a community around that tool/library/widget that will help you maintain it and evolve it further. Open Source is about breaking down barriers between organizations. Adoption is metric #1. No question.

(B) All your discussion happens out in the open where people can participate in that discussion, whether this is planning or development related discussion. Internal discussion means you have an “inner circle”. Stage one is “talking to yourself”, stage two is having a conversation with other users/developers — chances are they will most often be right and having a chance to have that conversation allows for new ideas to seep in and sparks future conversation and feedback. Do you have an IRC channel? How can you build a community of enthusiastic users and developers there? Does your company make a huge effort to make sure all discussions are open and internal conversation gets repeated for external parties so they can contribute?

(C) You have a way to report bugs and that it’s clear what the status of those bugs are for people who want to track them. Pretty obvious, but maximize transparency. If your bug tracker is a black hole, your relationship with users isn’t as good as it should be, and they will stop reporting bugs. Don’t take offense at bugs, this is a GOOD thing if you are getting bug reports. I’ve worked at some closed source shops where people had a grudge against you if you filed a bug against them. They should instead say thank you. Humility is hard to learn. Talk openly about what’s busted in your project when appropriate.

(D) You have a lot of contributions coming from folks outside of your organization. Fedora wins BIG here and has gotten to the point where there is no organization. You can’t expect for all projects to be so “dis-organized” (HA!) but it’s always nice to see the unexpected patch, especially when it comes from what you might have ordinarily thought of as a competitor. Welcome even small patches, it means that people care enough about your thing to make it better. Given, upstream maintainers will probably still end up doing a ton of the work — free code is not the only benefit of the open source development model. Sometimes though, you’ll get really big and neat contributions completely out of the blue. But to do this, you first need happy users and a community that feels like they can ask questions and become engaged. It has to be a welcoming community that is obvious to find out how you join it. Yes, you have to ask for help often, because it is not always readily apparent how open a given “open source” project really is.

(E) You have users talking about your software with other potential users. Whether it’s LUGs, blogs, or otherwise, word of mouth is the best way to advertise a product. Google isn’t it, because folks only have 5 minutes to read a web page (maybe less). However your buddy saying “check this out, this is really cool” is a great way to gain adoption, users, community, and in turn, more contributions. This means not only did it solve a problem for someone, they thought it was good enough to share with other people.

(F) It’s easy to find your licensing terms and where to download the code on your website. If it’s not easy to find, chances are your definition of open source is “you can download the code”, but the open source development model is not being followed too well. Open source is not a feature to put on a web page on your “pay us now” page, but is something you do every day. And it’s not just about the code, it’s also about the process.

(G) You can and do accept unprompted patches. Some projects have strong upstreams, but are not really able to adapt to unforseen patches that add interesting features. It’s always important to be able to accept new ideas, even if the ideas were not originally planned for — provided they are good, solid, sustainable ideas. One of the most interesting features of open source development is letting go of the idea that you “own” something and in addition to providing contributions, become one of the people who helps other people shape where it goes. This can require some help as folks may need some assistance in getting their patches into better shape. Make it easy for new people to dive in with your project without a lot of setup or confusion if possible, write some good docs, and minimize barriers to entry. This doesn’t mean you accept everything, but you should have a discussion about new features and if something that doesn’t fit, explain why, so the contributor wants to come back and still help.

(H) Your users know what the plan for your future release is. This doesn’t have to be a concrete roadmap, but this helps them better plan for the future and get excited about where you may be going. It also gives potential new developers a better deal of the same.

(I) You can collaborate effectively with applications that may be viewed as potential competitors/alternatives to yours. Microsoft: GPL’d patches welcome. Send them my way. Seriously. I do not fear you

(J) You can give back to upstream communities that you benefit from, either in terms of code, testing, or just helping other users with similar tools. This might be as simple as helping in user forums. This also can be very hard to do, but it ensures that you are also not just a user of other software but you are also a contributor to the things you benefit from. Development is not the only form of contribution — bug reports also are!

(K) Every single bit of your “thing” is open source. Having “pro” versions that are not open source means your advanced features do not benefit from community effects. Also, do not include proprietary components that similarly benefit but don’t give back. (Fedora also does a very good job here!) you don’t want to further the cause of people who are benefitting from playing in your sandbox but not helping to improve it. This also helps improve the ability for the thing to be distributed and merge/be-used by other things. You not only want your “thing” to be distributable, but also all the ideas in it — again, OSS is just as much about ideas and sharing /help/ as code.

(L) I don’t have to join a huge committee or stay closely in tune with a process to be able to take part in something. A lot of your users don’t have a lot of time. If they have a small change, can they get it in? If they have a small question, is it easy for them to stop by and ask it?

Bottom line conclusion: strive to be Open in everything you do, every LOC, every process, not just having available source — if you’re not doing that you are not getting all of the great benefits of Open Source which is the REAL reason why you do it, to achieve vibrant communities that feed off each other and get stronger because of it. If you’re mainly just talking to yourself (in stage 1), figure out how to maximize the stage 2.

If you have an open source project, think about how to grow a community of users and a community of developers. The latter is pretty darn hard, but a pretty rewarding thing to achieve.

I could have written this more simply — open source code is great, open everything is better. Hopefully this is useful to some new software companies out there, as well as some developers. The main idea here is, think community, not code. It’s everything — and when you do that, THAT is when you actually reap the benefits of open source. Otherwise the only real benefit you are getting is freedom to debug/fork, which is only a very small part of the equation.

I have run into a few companies who have said when asked “Are you open source” that say “Our application is not, but we use OSS”. Naturally this is not taking advantage of any of the above, but if you are just going to use the above, see how you can contribute back to some of the projects that you do use — testing and bug reports, user communities, and ideally, development. The OSS ecosystem benefits the most as you make things as open as possible, and give back as much as possible.

Anyhow, I’m probably preaching to the choir here on FPO, but I figured some folks would find it useful. A lot of it is simple communication/presentation stuff. Google index bots: transform and roll out.