As a student, you get a stipend of of $5000 USD and the respective mentoring organization gets $500. Students have from March 26th through April 6th to apply to the mentoring organizations that they are interested in. Afterwards, the mentoring organizations rank and review the proposals. Finally, the accepted proposals are announced on April 23rd.

If you qualify (you’re a student and older than 18) and have some coding skills, I highly recommend you consider doing GSOC as it’s a great way to learn something, get some experience and even get a job potentially. I recommend looking over the list of mentoring organizations. I’m excited this year because Twitter is a mentoring organization and we will have some students work on some of our open source projects. Of course, the Eclipse Foundation is participating and has a great list of project ideas.

In the end, if you’re a student, just do it if you don’t have anything else crazy lined up. You get to work with quality mentoring organizations that have been vetted as great places to get started on working on open source.

The slide above reminds me of Maddox’s classic rant on kid artwork.

Thanks for the great analogy Michael, I completely agree with you!

Inside the eclipse.org community, there’s been some discussion lately about scheduling releases. Historically, the Eclipse platform ships a major release every year (triggers a release review as part of the EDP) with six-week milestones in between. Also, the Eclipse platform project aligns itself with the annual simultaneous release (e.g., Indigo). I think this works fine for the platform project because it’s extremely mature and dependent on by a lot of consumers. However, I would love to see the platform release more than once a year, but I haven’t had enough time to think about how to do that without being very disruptive. It is something the project leadership should be thinking about as we move into the 4.X Eclipse stream.

Since the Eclipse platform project is very prominent, a lot of other eclipse.org projects tend to align their releases with the platform. I think this is wrong method to choose your release schedule, especially if you’re a young project. Actually, some people I have talked to think that they only have to release once a year, which is wrong as the EDP doesn’t impose any major time restrictions on you releasing. I think each project should release according to its maturity level and adopters needs. For example, let’s look at the Mylyn project’s release history…

• Mylyn 3.6.2 (February 24, 2012 – Indigo SR2)
• Mylyn 3.6.1 (September 23, 2011 – Indigo SR1)
• Mylyn 3.6 (June 22, 2011 – Indigo)
• Mylyn 3.5 (March 16, 2011)
• Mylyn 3.4.3 (February 25, 2011 – Helios SR2)
• Mylyn 3.4.2 (September 24, 2010)
• Mylyn 3.4.1 (August 4, 2010 – Helios SR1)
• Mylyn 3.4 (June 23, 2010 – Helios)
• Mylyn 3.3 (Oct. 26th, 2009)
• Mylyn 3.2 (June 24, 2009)
• Mylyn 3.1 (March 4, 2009)
• Mylyn 3.0 (June 25, 2008)
• Mylyn 2.3 (Feb. 27, 2008)
• Mylyn 2.2 (Dec. 19, 2007)
• Mylyn 2.1 (Sep. 28, 2007)

If we notice a pattern, Mylyn tends to release about four times a year and tries to align itself with the annual release train. Another example is the EGit/JGit projects…

• EGit/JGit 0.7.1 (Mar. 22, 2010)
• EGit/JGit 0.8.1 (Jun. 2, 2010 – Helios)
• EGit/JGit 0.9.1 (Sep. 15, 2010 – Helios SR1)
• EGit/JGit 0.10.1 (Dec. 17, 2010)
• EGit/JGit 0.11.1 (Feb. 11, 2011 – Helios SR2)
• EGit/JGit 0.12.1 (May. 2, 2011)
• EGit/JGit 1.0 (Jun. 1, 2011 – Indigo)

The EGit/JGit project tends to release every few months and tries to align itself with the annual release train.

What’s your ideal release schedule? If you’re an eclipse.org project, why don’t you release more often?

“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.

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.

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?

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

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.

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).

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?