Eclipse Top Ten: Important lessons I've learned working on Eclipse
•Als PPT, PDF herunterladen•
1 gefällt mir•1,263 views
An insightful, candid and funny look at the top ten things I've learned while working on Eclipse for 8+ years. Community, contributors, committers, comics, this talk will have it all. See http://relengofthenerds.blogspot.com the text associated with the slides
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Eclipse Top Ten: Important lessons I've learned working on Eclipse
Ähnlich wie Eclipse Top Ten: Important lessons I've learned working on Eclipse (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Eclipse Top Ten: Important lessons I've learned working on Eclipse
- 1. eclipse top Kim Moir IBM
- 2. me: license to build
- 3. transparency
- 4. yes
- 6. contribution
- 8. family
- 11. proof is in the code
- 12. teamwork
- 13. make a difference
Hinweis der Redaktion
- Wasn’t that a great talk? I love the fact that we’re getting paid to learn about lego. Show of hands, how many people are here for their first EclipseCon? Great. Welcome. This is my third eclipseCon and I’m very happy to be here with you today. My talk is about the top 10 things that I’ve learned working in the eclipse community. So 10 things, each will take a little over a minute. Then we’ll have time for questions. My name is Kim Moir and I’ve been working on eclipse for a long time. I work for IBM in Ottawa, Ontario, Canada. I’m a release engineer for the Eclipse and Equinox projects. Release engineer is kind a boring job title. I prefer to think of it in more glamorous terms. James Bond has a license to kill.
- I’m a committer with a license to build. Enough about me. Let’s talk about you. The eclipse community.
- Transparency is one the core tenets of open source. This requires a change in thinking as a software developer. You’re not writing code that nobody else will read. With open source, everyone can see what you do. They can see your triumphs And they can see your failures. Break the build four times in a row? Everybody saw that. Release a bug to the launcher so that Eclipse doesn't start? Everyone sees that too. On the other hand, if you ship on time every year, year after year, people notice that too. It’s good to keep us honest. And the feedback we receive from the community is invaluable. Brutal sometimes. But priceless.
- When I first starting working on eclipse, I quickly realized that I have to say no a lot. I only have a couple hundred bugs in my bucket. Not many compared to some of my committer friends. I have a friend. Let's call him Paul. He has about 1300 bugs assigned to him in the Eclipse 3.x stream. He can solve 20-30 bugs a milestone. Each milestone is six weeks. That's excellent fix rate. So thousands of bugs. Can't fix them all. We'll never have a zero bug count. In the beginning, I would close bugs with something like "Sorry, I'll never have time to fix this". This isn't a way to win new friends in the community. I've learned that the way you say no makes a difference. You need to say no in a way that will make others say yes. How do you do that? For instance, say I'm spending a lot of time working on a plan item for 3.6M7. I really don't have time to fix a new bug that a member of the community has just opened in my bucket. But, I can be helpful and give them pointers to where the code needs to be changed. Here's the repository location of the code. Here are the JUnit tests. I can offer to provide guidance, but you need to take ownership of this problem if you want to get it fixed. Taking ownership means transparency. People will be watching you. This community grows by letting others to step up to the plate.
- The eclipse.org ecosystem has a huge wealth of talented people with a broad range of experience. They are willing to help. They love talking about what they do. In fact, sometimes it’s hard to get them to stop. Go out into the hallway after this presentation and I guarantee you'll find someone who won't stop talking about their project. We are passionate about open source software. So, if you don’t understand something ask for help. Bugzilla , forums , mailing lists , Twitter , IRC . Sometimes I arrive for work in the morning and see a post on planeteclipse from someone who's ranting at an eclipse project. It can be ugly. If this is a project under the Eclipse or Equinox umbrella, I often look and see if the blogger has opened any bugs or asked questions on newsgroups or mailing lists. A lot of the time, they haven't. Don’t get angry, just ask. We’re listening. We can help. Once you're armed with knowledge, you can help others find their way. And you too, can become a mentor .
- Sometimes the people have unusual perceptions of what constitutes participating in open source. Open a feature request. Done! Someone else is going to fix my problem! Nope. It’s not a viable business plan to expect others to fix the bugs that you care about. If you want to ensure that your issue gets fixed, get involved in the process. Ask how you can help. This gives you credibility in the community. As a committer, I'm much more likely to look at a bug if the person offers to help. Once you get your hands dirty with all that delicious open source code, perhaps you'll decide to that you want to do more. Triage a few bugs. Verify several fixes. Write some patches. You're walking along the path to becoming a cook committer too.
- Communication. Sometimes as software developers this isn't a natural skill. But it’s essential. Communication is just as important as code. You can have an incredible eclipse project. You understand it because you've spent months working on it. But if no one else understands it. They won’t use it. Or if they try to, they will blog about how hard it is to use. Any publicity isn’t really good publicity. Talk to your community. Get feedback. Get them involved. Or else someone else will talk for your project. And you may not like what they have to say. Help manage your message or someone else will.
- The Eclipse community is sometimes like a large extended family. You have PDE cousins. SWT and p2 Aunts. CDT and WTP Uncles. It’s good to have a shared history so people understand where you're coming from and the perspective you bring to the table. To have people to back you up when times are tough. You can share funny stories. Gossip. Families ask tough questions. In your real family, someone at the dinner table might ask “When are you getting married?”. In Eclipse, the question will be “When is your project going to become more diverse?”. Just a note, in the context of Eclipse, diversity always seems to refer to the number of different companies working on a project. In a more traditional office environment, it would refer to the number of women or visible minorities. Other questions from the Eclipse family might might be: “When are you going to fix that bug that I opened three years ago?”. “You know, that company isn’t really pulling it’s weight. They need to step it up and donate more resources”. Honesty is good. It’s great that we can have candid discussions about the future. The interactions that I’ve had with the Eclipse community over the years have been overwhelmingly positive. However, for me, there have been some awkward moments with the Eclipse family. Here’s a question – what shouldn’t you do with family? Anyone? You shouldn’t flirt with family. No. In the past, I've received some very friendly emails from random members of the community. People that I don't know. There are many fine dating sites on the internet. Eclipse.org isn't one of them.
- In the eclipse community, sometimes there’s public humiliation, and sometimes there’s bribery. Have you ever bought someone a beer to encourage a bug fix? I think many of us have. Asked a pointed question on a mailing list to try to shame people into action? Yes. However, the only real thing that works in the end and that will get people working together is common ground. You both have to care about the same feature or bug fix. Enough that you are willing to commit your own time and effort to get it implemented.
- And the interesting thing is, that once you have a group of people who care about moving forward on the same issue. What do you get? Diversity. Here's a picture of the companies that are contributing to or building products on top of Equinox p2 today. The p2 bundles were released into the Eclipse SDK in 3.4M5 (March 2008). We've come a long way.
- Before Pascal started his new job at Sonatype, his office was across the hall from mine for several years. I learned many unique expressions from him :-). One them was "the proof is in the code". Let me expand on this statement. At its very heart, Eclipse is a meritocracy. The more you do, the more responsibility you have. If you want to drive the direction of a project. You won't get too far by shouting from the sidelines. The proof is in the code. And I say code, I don't just mean actual code. There are many ways to contribute to eclipse. Write documentation. Triage bugs. Respond to newsgroups. You get the idea. Don't promise and not deliver. Going back to transparency theme, everyone will know what you're not doing. Execution matters.
- Everyone has to care. If the webmasters didn’t take care of the servers, we wouldn’t be able to release or build software If the Eclipse.org IP team didn’t do their job we couldn’t use third party libraries or contributed code If companies didn’t release products based on Eclipse, there wouldn’t be anyone to pay the bills :-) If the community wasn’t there to open bugs, work through problems or write articles our software wouldn’t be what it is today. Last, but not least, if the committers weren’t there, getting up each day and caring about the future of Eclipse, we wouldn’t have much progress. We ship together as a team.
- Sometimes, I'm disillusioned with democracy. It's messy and difficult. Don't get me wrong, I wouldn't want to live in a dictatorship. But does my vote really matter? I don't know. When I email my Member of Parliament to express my opposition to a bill, do they really value my opinion? Judging by the generic form letter that I receive in return, I am deeply skeptical. The eclipse community is small which means that as an individual, you can make a difference. At Eclipse, my vote counts. You bug fixes can help people ship new products, make their work day more productive or evern monitor robots on Mars. That's really amazing. People appreciate that and it's great to hear positive feedback on your work on an ongoing basis. You can be the one to make a difference, positive or negative. You can be the one to find a critical bug before release day Or after release day. Nothing is better that working with people who care about what they do. Hands down. Just look at all the people who have won the Eclipse Community awards this year. They made a difference. And that's why I like working in the Eclipse open source community. Thanks to all of you for making this a great experience over the years.