Chris Aniszczyk's (zx) diatribe

I’ve been starting a lot of documentation work lately for the EGit/JGit projects and happened to come across this timely article from Forbes. If you don’t want to read it, the gist of it is that solid documentation is more important than you think… especially when it comes to attracting a user and developer base. Here are some quotes…

“I can report that my company receives 70% plus of our site traffic from organic sources, and our documentation generates more than half of our overall site traffic. Furthermore, over half of our lead generation is driven by our documentation.”

While the article specifically mentions commercial software, I think the lesson of having solid and findable documentation apply to the open source realm. I mean, when’s the last time you’ve come across an open source project that you praised their documentation efforts? I can maybe count two total in my lifetime. As open source developers and project leads, we tend to put documentation last and our expectation is that users would pitch in to help. As users, we just want good documentation and don’t believe it’s our responsibility to help out necessarily…

So next time you’re working on that feature, weigh it versus taking some time to document things for your users. If you’re in Eclipse land, feel free to take a look at our documentation guidelines and some examples on how to crowdsource your documentation efforts a bit.

Over memorial day weekend, I noticed that the Apache Software Foundation is having a little fun with marketing over Twitter.

I’m a fan of their “Did you know…” series of posts as of late. I mean, I had no idea Apache Shindig is the foundation for the LinkedIn InApps platform… and I’m sure the folks at LinkedIn wouldn’t have told me in a straightforward fashion either. I mean no offense to the folks at LinkedIn and other companies that use open source software, but they generally don’t do the best job advertising the open source technology they use. Sure, some companies are better than others but my point is that the burden of marketing seems to fall on the open source projects themselves. The problem with that is that open source developers are generally terrible at marketing (well, mostly apathetic). And I can guarantee you that if no one talks about your project or can find it, no one will be really using it even though it may be a great piece of work.

At Eclipse.org, I know this has been a bit of problem given just the diversity of projects and from people who have spoken to me. The Eclipse Foundation has done a good job when it comes to case studies on people building upon the Eclipse platform, but what else can it do for projects? From my own experience in supporting people who use Eclipse technology in the field… it’s quite amazing where you see Eclipse technology turn up… from ski lifts to banks to rail way systems. I don’t think many people understand the breadth of places that Eclipse technology shows up. Just a couple days ago I learned that Xtext was helping the automotive folks at AUTOSAR.

If the burden of marketing falls to open source projects themselves, what can you do to convince people to “sell” their project a bit? Should we suggest webinars as something people do as part of the release review process at Eclipse? Should a book be required as part of a graduation review at Eclipse (ok, maybe that’s a bit much but I’m still waiting on my Xtext book)?

Just some food for thought.

Over a couple frosty beverages yesterday, I had a lively discussion with a colleague about open source contributions from a developer’s perspective. In my opinion, open source developer’s have to walk a fine line when it comes to working with new contributors and not killing all of your time while doing it…

What do I mean here? Well, when you get a contribution it’s pretty rare that the contribution is just perfect and ready to be submitted to the main line. The reality is that you get contributions that generally need some form of tweaking before they are ready for the world. It’s the tweaking where things get interested. There’s two attitudes you can generally take.

The first position is you can simply be happy that you got a contribution in the first place and just make the necessary tweaks your self and push it to the mainline. The upside to this is that the contribution actually gets contributed quickly. The downside is that this consumes a bit of your time to polish the contribution and that you may also miss out on the opportunity on cultivating a contributor. The second position is that you can do a thorough review of the patch and force a contributor to polish the contribution to meet your standards. The upside is that your this may result in higher quality patches from contributors in the future. Heck, if contributors become really good, they may even make the jump to a full blown committer on your project. The downside is that patches may go stale because you may discourage contributors if you ask too much from them.

I’ve seen both approaches in a variety of open source communities. I’m generally happy just to get a contribution from anyone. I don’t think there’s a silver bullet approach in the way you treat contributors, you probably have to do things on a case-by-case basis. In the end, I felt like I needed to do a brain dump of the discussion I had yesterday. On top of that, I find the question of how to attract contributors without killing all of your time while keeping quality high… just fascinating.

What do you think about this problem… from either a developer’s or a contributors perspective?

Today I had the opportunity to speak at Texas Linux Fest 2010 and meet some Red Hat colleagues…

I presented some ideas I had on how to get involved with open source and be successful with it. It seemed the audience received the presentation well even though I was a bit nervous since this was the first time I did this type of presentation (and I wasn’t talking about Eclipse). Some people have asked for the slides so I posted them on SlideShare.

Also, for the first time that this conference was put on, I think everything went smoothly (good job conference organizers). From my point of view, it was interesting to get exposed to the Linux enthusiast community again, it’s been awhile. I do admit I felt a bit dirty doing my presentation off my MacBook Pro using Keynote in front of an audience of Linux enthusiasts, but hey… Open Office is terrible… I’m a pragmatic open source guy

There’s been some discussion as of late amongst the Eclipse Architecture Council about streamlining the committer election process.

I brought the issue up because I have mentored quite a few projects at Eclipse.org and have seen the good and bad parts of the process in play. We are also at a time where we are modifying the Eclipse Development Process so we have the opportunity to make some changes to the committer election process. I don’t like the process currently because I think it takes too long for a committer to get elected and eventually get commit rights to source control. From the 7 day election period to the paperwork, I think we can do a bit better. I like the process because it plays into the fact that Eclipse is a meritocracy and allows existing committers and community members to speak their mind. In reality, there are very few times where I have seen someone voted down when an election was called. In most cases, I’ll bet existing committers have talked amongst themselves already before calling an election so that veto vote is less likely to happen.

How do other mature open source projects deal with this? How do we make it better?

Anyways, if you have any comments or suggestions, please speak up on the bug. It would be nice to hear from people what they experienced when they were being on-boarded as an Eclipse committer or even other open source projects.

Next weekend, I’ll be speaking at Texas Linux Fest 2010 which happens to take place in my beautiful town of Austin, Texas…

In a theme similar to what I blogged about a couple days ago about getting involved with open source, I plan to give a talk entitled Open Source from the Trenches: How to Get Involved with Open Source and Be Successful. It’s a long drawn out title, but the basic gist of it is that I have 25 minutes to share my experience in open source land with the audience. I’ve learned a lot from everyone I have met a long the way and plan to divulge some of the lessons learned. I’ll admit I’m a bit nervous as I have never given this type of talk before…

For those from the Eclipse community, anything else you want me to say that you may have learned a long the way? I think we have a special place in the open source community as we tend to dance between the line of commercial and open source really well compared to other open source communities. I was going to say “dance with the devil” but that would be very freetard of me, I’m more pragmatic these days

Anyways, if you’re in the Texas area, I highly recommend attending the conference. I’m personally looking forward to these talks:

• With Software as a Service, Is Only the Network Luddite Free? – Bradley Kuhn
• Benefiting from the Skills of Non-programmers – David Cramer and Janet Swisher
• 5 Important Topics in the Intersection of Open Source Software and Education, and how You can Participate – Max Spevack

I hope to see people there. If you’re in the area and want to meet for frosty beverages, let me know. On top of that, we Red Hatters also plan to have a lot of Fedora swag at the event too (I’ll have Eclipse stickers).

I was recently approached by a student I mentored a couple years ago. He’s been doing some job shopping and asked for some advice on how to get involved with open source and be successful at it. At first I thought, I’m naive what the heck do I know… I was shooting for a simple answer but after a few minutes of thinking about it I was a bit lost what to say. I rather not offer some trite advice and leave the guy with nothing practical. After spending some time over the weekend thinking about it, I started writing and came up with this short bit of advice…

Find your passion. Contribute to it. Brand yourself.

What do I mean about finding your passion? There are a ton of open source projects out there that span all sorts of topics. Find open source projects that truly interest you and are exciting. If you don’t, you’ll soon find yourself distracted with other things. Someone once said that, “Nothing great in the world has been accomplished without passion.” Also note that the majority of open source communities are meritocracies and to build a repertoire with them takes time. If you really want to get involved with an open source project and potentially become a committer you need to dedicate some time. So that being said, there’s some practical things we can do to help your passion to get involved with open source.

Find the Right Open Source Projects

Like I mentioned before, find open source projects that interest you. There are a lot of forges out there you can browse for interesting work, like SF.net or GitHub. However, I recommend that you take a look at the list of mentoring organizations from the Google Summer of Code (GSOC) program. These organizations have already been vetted by the GSOC organizers and are of a higher quality than other open source projects out there. They also tend to be more welcoming to new contributors which brings me to my next point about mentors.

Mentors, Mentors, Mentors

I believe mentoring is crucial to your success in becoming involved with an open source project. Without a mentor, you will waste time learning the ropes of the project. There are a lot (but not many) of open source projects out there that have formal mentoring programs. For example, the Fedora project has a program where you can find mentors. The Eclipse project also has a specific place contributors can go if they are seeking some mentorship. Another approach that worked for me a long time ago was simple emailing a project leader and asking him if they were willing to mentor me. Sure some people will say no, but you’ll be surprised on how many people say yes. Oddly enough, this is how I got involved with Eclipse.org but that’s another story.

If you qualify as a student, I think the Google Summer of Code program is one of the best ways to get involved with open source. I have mentored students the past few years with GSOC for Eclipse.org and have seen some amazing things happening. I’ve seen students evolve from open source contributors to full-fledged developers. I have even seen a couple students find open source related jobs due to their involvement in the program.

Contribute

Many open source projects are meritocracies. In order to get involved, you have to contribute and build your repertoire. So simply do the work in finding some bugs you can fix. This is hopefully where your mentor can come in and point you to some low hanging fruit to get you started. Since I’m a software guy, I have a tendency to focus on programmers but there are many ways to contribute to open source outside of code. For example, documentation and testing are ways you can get involved with open source. For example, I think the Fedora project does a good job in highlighting the different avenues you can contribute to the project based on your skillset and desires.

If you’re into books, I can recommend Karl Fogel’s Producing Open Source Software as a good read. It’s a little outdated in my opinion, but can give you some insight on how a lot of open source projects operate. It may also be useful to you if you start an open source project in the future of your own.

I also recommend getting an Ohloh.net account so you can track your code contributions. For example, I’m able to look at my Ohloh account and remember the good ol’ days when I actually contributed to Gentoo Linux.

Brand Yourself

This may be odd to hear for developers, but you are a brand and you should control your image. In open source land, things are done in the open so we have to be mindful about that. Avoid negativity at all costs and kill people with kindness. Be critical without being negative, it’s possible. Also, if no one can find you, how can you expect to be successful in an environment that is all about being open? So I recommend getting yourself a website, a blog and a Twitter account. These things will help with visibility and will also get you in the mindset of doing things in the open. It will also allow you to share your expertise in the areas that you’re passionate about it. When you’re comfortable, I would also exude confidence but wouldn’t over do it.

I would also recommend getting a slideshare account if you’re giving talks at conferences. I use it as a dumping ground for all my presentations in the hopes that people may find them useful.

In the end, the point is that you have to understand you’re a brand and if you want to help your career, you should be findable. Also in terms of career advice, I say that you should brand yourself for the career you want, not the job you currently have.

Networking

Networking is one of the most important things you can do for yourself and your career. If you can, attend conferences (including other type of meetups) and meet the people you have been working with (or want to work with) in a face-to-face environment. There’s no better way to connect to folks than sharing a frosty beverage and chatting it up.

On top of conferences, do yourself a favor and get a LinkedIn account. This will help you establish a professional network and also may help you land a open source related job in the future if that’s what you want.

In the end, my advice is to build a network via conferences and online interactions.

Conclusion

Well, that’s all I have for my brain dump about getting involved with open source and being successful. I really just kept writing and put what sprang into my mind, so sorry if it’s a bit hectic. In the end, I think it’s all about finding the right open source community to act as an outlet for your passion. Anyways, I hope people find it useful as I’m not sure what other advice to really give. What do other people think? What helped you get involved with open source? What could have done better? What helped you become successful?

It’s interesting to hear that Liferay switched to the LGPL recently.

On top of that, they did the license switch in a way that involved their community (which is a good thing and should be noted by other companies looking to do the same thing). Anyways, there’s interesting discussion in why they did it and also people’s reactions in the comments are always fun to read…

Well, it’s a legitimate detriment to us. Our company has a policy preventing the incorporation of any open source product licensed under GPL or LGPL in any of our products. Irrespective of one’s opinion as to the wisdom or necessity of this, there are many organizations that have similar policies.

Sad that many companies still have this policy…

On a side note, maybe my prediction about the rise of weak copy left licenses has some merit?

I recently joined the advisory board for The Open Source Business Resource (OSBR) which is one of my favorite reads when it comes to crossroads of open source and business. I find that when it comes to quality business-related open source material out there, we don’t have many options (or I’m just not aware of them yet). I mean, besides opensource.com, a couple analyst firms and a few interesting blogs, I don’t have much to go on.

In the latest issue of OSBR which targets the mobile industry, there’s one article I really appreciate by Andreas Constantinou which starts off with this revealing quote…

“Open source licenses tell only half the story. The governance model, the implicit rules defining transparency and influence into an open source project, is the small print that determines the power dynamics around that project.”

If you haven’t noticed, the mobile industry is in an open renaissance when it comes to giving people access to source and allowing them to contribute via a variety of levels. For those who had the pleasure to work in mobile in the past, this is a bit shocking given how the industry previously treated access to mobile operating system source. The important part of the article is when it starts mapping open source license types to governance models (see the fairly accurate figure below). And discusses how the mobile industry needs less marketing hype around the benefits of openness, but more education and clarity on governance models.

See where Eclipse fits in (it’s snuggling next to Symbian)? Do people like it there ?

Just because Android says they are open, doesn’t necessarily mean they are when it comes to governance. Anyways, give the latest OSBR issue a read if the mobile industry is your cup of tea. If you want to see anything in upcoming issues, like a potential theme covered, please let me know.

Over the weekend, I noticed a bug trickle in…

I first thought… wow what a !@#$, this is not a way to win friends and influence people…

I was thankful my team responded correctly with the mantra of killing people with kindness.

As open source developers, we have to remember to have some restraint when interacting with our consumers. The old adage of killing people with kindness should apply to most of the cases we deal with. As consumers of open source software, it’s important to follow some basic etiquette rules when hitting a problem and reporting a bug:

• Be civil and positive when reporting bugs. Saying the !@#$ing software sucks isn’t going to help.
• Be patient when reporting bugs. Some people work on projects on a volunteer basis (if you need better support, some open source projects have commercial support offerings).
• Don’t double post and spam all the open source project’s communication channels.
• Read “How to Ask Questions the Smart Way” and live by it

In the end, it’s all about interacting with people. Over the net, it’s easy to forget that we are actually dealing with people; not autonomous robots without any emotion.