Running an Open Source Project
•Download as PPTX, PDF•
0 likes•211 views
Mike Edwards thoughts on running an open source project. Presented at the Sitecore User Group Conference in Malmo, Sweden, November 2015
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (19)
Similar to Running an Open Source Project
Similar to Running an Open Source Project (20)
Recently uploaded
Recently uploaded (20)
Running an Open Source Project
- 1. Michael Edwards Sitecore Architect and Consultant Sitecore MVP mike@glass.lu www.glass.lu @glass.lu
- 2. New Logo!
- 3. Running an Open Source Project
- 4. Why?
- 5. Why?
- 6. Why
- 7. Why?
- 8. Why?
- 9. Why?
- 10. The Idea
- 11. Why?
- 12. Why?
- 13. The Idea
- 14. The Idea
- 15. The Idea
- 16. The Idea
- 17. The Idea
- 18. Consider
- 19. Consider
- 20. Consider
- 21. Consider
- 22. Consider
- 23. Building It
- 24. Is it yours?
- 26. Building It
- 27. Building It
- 28. Building It
- 29. Building It
- 30. Building It
- 31. Building It
- 32. Test
- 33. Building It
- 34. Building It
- 35. Building It
- 37. Building It
- 39. Community
- 40. Community
- 41. Community
- 42. Community
- 43. Community
- 44. Community
- 45. Community
- 46. Community
- 47. Community
- 48. Support
- 49. Support
- 50. Support My code is broken, I am getting this error: System.NullReferenceException as Line 15 of SomeFile Can you help?
- 51. Support
- 52. Support
- 53. Support
- 54. Support
- 55. What next?
- 56. What Next?
- 57. What Next?
- 58. Build a Business
- 59. Support
- 60. Summary
- 61. Michael Edwards Sitecore Architect and Consultant Sitecore MVP mike@glass.lu www.glass.lu @glass.lu
Editor's Notes
- First things first! We have a new logo! Going forward I have decided to update the Glass logo, the beer glass was great but I felt a little limiting. Therefore from today you will start to see this logo in a variety of colour replacing the beer Glass.
- So today I am going to talk about my experiences of running an open source project and what you might want to consider when running yours.
- The first question you need to access your self is “Why do I want to do this?”
- Maybe for some you want to become famous, I can only dream of being as famous or as rich as grumpy cat
- This is my cat, he is neither grumpy or rich,
- For the money….. but it’s open source …?? Can you make money in the open source community?
- Maybe you have been set the impossible challenge and you just can’t refuse a challenge.
- Because you think, I can do that better! You have seen something or you are working on something in the office and you think this can be done so much better! I can do this better.
- You want to make something “perfect” i.e. something you can work on and improve. When working on client projects one of the things that would annoy me most is that I knew that I could make the solution better but the client or agency doesn’t have time. An open source project allows you to spend as much time as you want refactoring and perfecting your code.
- For me it was the challenge. I had seen many solutions to the ORM challenge but none I liked and not I was happy with. I wanted to create something that was more closely aligned with how NHibernate o Entity Framework worked. That avoid using wrappers and the limitations they imposed.
- The most important thing is to pick a reason that works for you. An open source project is like a child, once you have one it will take over your life.
- So you decided to release an open source project but now comes the hard part. Hopefully you have an idea but if not look at the tools you use every day.
- Maybe the same problems just keep occurring over and over and over and… and you just think, won’t some fix this already!!!
- Maybe the client has asked you for a feature which you think would be great for the community. This scenario is difficult because you need to understand who owns the IPR on the software, your company or your client?
- You are using something that is already out there but you think it can be improved!
- Or maybe you just have a moment on inspiration while sat on the toilet one day.
- However you get your idea consider the following
- Do you want a big project or a small project? The bigger the project the more commitment you will need or the more contributors you will need to find.
- How much time do you have? Remember this is an IT project, so however long you thought it would take, double it.
- And how much do you want to see your family? It may use up a lot of your free time, probably time when you should be spending time with the kids, doing some DIY or cooking dinner.
- That no one will want to use it. Therefore it is important that you make something that you will want to use. If nobody else likes it or wants to use it at least you have got some value out of it.
- So the legal bit! I am not a legal adviser so this isn’t legal advice and I would recommend that you seek independent legal advice from your friendly lawyer. But you need to know who owns the code! You may think “I am doing this in my own time, on my own computer, using my own ideas!” and therefore “I own it!”. Unfortunately that may not be true! It depends what is in your employment contract some companies essentially say own all your thoughts. So approach your company and a discuss your open source idea with them and see where you stand. Make sure that you get in writing something that release the IPR to you
- So day 1 you will be like road runner! Hammering on the keyboard as quickly as your brain can think!
- But after two weeks of hammering at your keyboard, trying to fight with another static class in Sitecore it will feel more like a marathon. There are no short cuts in the build phase you just have to keep going.
- As we all know there are lots of free tools out there, VS, Github, Trello but also some of the paid for tools can also be free to open source solutions like Resharper and TeamCity. Often these tools require that you show the project is active before they will give you a licenses so you will still have to do some work first. I am amazed by how much free stuff is out there in the community and how many great things people are giving away..
- Take your time to develop the solution, one of the best things about writing an open source project is that you can take the time to do things correctly or to learn to do things in a different way. You are freed from the demands of timescales, budget limits and client requirements. For me Glass v3 probably took 6 months in duration to complete spending on average about 8 hours a week (I think). It is a lot of a commitment and requires a very patient partner.
- You will hit problems and challenges and this can be very frustrating if you don’t have anyone around to help you find a solution. There are very few people available in the UK at 11pm at night. Luckily now we have the Sitecore Slack community so you will probably find someone on there who can help.
- For SItecore a big problem is the license and this isn’t easy. If you work at a Sitecore partner you will probably be able to use theirs but if you don’t then… you are a bit stuck. If you become an MVP you get a Sitecore license or at least the promise that you will get a Sitecore license some day.
- Try to make you code the best code you can write because everyone gets to see if. However balance that with the fact that you will look back at it in 2 months and think “What the hell was I thinking?” . You also need to get something shipped at some point so obsessing over using a foreach loop vs method chaining may not be useful. Me and Nat have actually done this, we want to see which was the fast way to iterate a set of tasks, many, many hours later I can tell that there isn’t much difference”. Also think about the API that your application exposes. This isn’t an internal application where those working on it will should have an indepth knowledge of the application, uses coming to this will be essentially blind and will need to be guided by the properties and methods that are exposed by your API. Make use of protected and private properties, learn the difference between abstract and virtual, think about how someone will extend your application or might need to modify it. Learn from how you customise Sitecore and the problems you have there. AND WHATEVER YOU DO AVOID STATIC CLASSES AND METHODS!
- Write test to validate what you have done, the Glass project has over 700 unit test and this saves a huge amount of time. Unless you want to regression test before you release then unit tests will save you a huge amount of time. Do you need to do TDD? Well that is up to you, it is your project. Personally I prefer to write my tests after I have written something to validate it. Unit tests also force you to make better design decisions by forcing you to decouple code and break down large methods into smaller units. Also think about how your users will write unit tests against your API when they integrate with it?
- Documentation………………… how many developers like writing documentation? This is where most developers fall down, when given the choice between writing documentation and adding and exciting new feature the exciting new feature normally wins. The best solution is to find someone who likes writing documentation, failing that use something like Sandcastle. Documentation can be useful because it allows you think about how to validate your thoughts.
- You will get times if you are creating a larger project where you will question why you are doing this on top of your day job. For me the answer to this is that I get to do things that my job wouldn’t normally allow you to do. For example unit testing, use a build server, develop a CI process, use new tools. The key to the point is to focus on the why and let that motivate you to finish the solution. This is probably where most open source projects fail, people hit to many bugs, the problem becomes too complex or you hit the more mundane tasks and the fun is gone.
- Hopefully after many nights of lost sleep, tears and shouting at the screen you will hit V1 or at least
- And now it is time to find out if you have built a frankenstein or a ninja kitten carrying a gold gun while riding a unicorn that breaths fire (literally the coolest thing in the world).
- Working on client websites puts us in a very special position. When we deliver vNext to our clients we can just deploy the latest code to our servers and we can quickly forget about vPrevious. However when you build and open source project you can’t forget about vPrevious, you have to worry about the dreaded word “backwards compatibility”. This is difficult because you need to balance making the project better with not breaking the API so much that you have to rewrite everything to upgrade. This is where Semantic Version numbering comes in and is worth learning. Using this correctly will give some indication to your users of the likely impact on their code base of upgrading. However don’t be afraid to break backwards compatibility, to move forward you will need to do this otherwise you project won’t progress.
- So now you need to get people using it, you need to create that dreaded word “Community”.
- To start with you probably need a website. I have used wordpress, GitHub pages and finally I am running my site on Sitecore. Of course starting on Sitecore is probably overkill. I think the best free solution I tried was github pages. It is really simple and allows others to contribute as well. Whichever solution you pick it is essential that you have something somewhere to let the world know about it!
- Time to beg and bribe your friends and colleagues to write blog posts about your project. It is an amazing feeling when you start seeing the community writing blog posts about your project without any prompting! You get to see their real world experiences and how they really use it. How your tool is really used may differ a lot from how you thought it would be used. You will get blog posts that maybe critical of your product, but don’t get angry or attack these people. Criticism is an opportunity to learn and to improve your project.
- You are also probably going to need to do some presentations and this scares everyone! It especially scares me! Presentations take a lot of effort to prepare and to actually perform and they might go wrong, this presentation is probably 10+ hours of work. This is a picture of me presenting at SUGCON 2014 in the Netherlands and it was a disaster. My computer wouldn’t connect to the projectors because I only had a HDMI connection, we then thought we could RDP from one machine to my machine and project that way, but there were two many people on the WIFI! Finally we ended up sharing my screen via a Google Hangout session using somebodies mobile phone as a wifi hotspot. I am still not sure how we ended up there.
- If you have build something awesome you will get your cheerleaders and these folks are amazing! They encourage others to use your project, help answer questions, advocate your product and recommend improvements! When you need motivation to keep your project going these are the guys you need to talk to.
- Building a team can be difficult because it takes a lot of time and dedication. When people join a project they may not realise that at the start. Be prepared for people to come and go it is just part of the project lifecycle.
- However you will receive negative feedback, like your own kid you might love it but others will hate it. Avoid attacking critics or being too defensive. Those who are critical often supply you with tons of information on how to make your project better, they will express concerns or features that are missing. Use this information to improve your project. This bring me onto feedback, this is the hardest thing to get from people. Especially honest feedback, people are generally really nice and don’t want to say bad things.
- Also remember that you might love your project and think that it is the best thing since sliced bread but not everyone will. Again this is my cat, I think he is amazing. My mate Rob, not so keen mainly because my cat likes to bite him but only him.
- If you are like me and you like competition then it is nothing to fear. I find it drives me to innovate and to not become complacent .
- To be honest this is becoming a nightmare, not just for support but just in general! If I was to watch every way that someone could contact me I would never have any time to do anything! I haven’t found a great way to manage this yet, and it feels like a constant fire fight. I try to direct people towards Github because at least that centralise it for me. Also take note that if you need Glass support that is the best place to go.
- You will get people asking you questions like this. I can never understand why! As developer you know how annoying it is when a user doesn’t tell you everything you need to know to replicate an exception but when reporting bugs we fall into the same lazy trap! Don’t be afraid to hit the ball back at the person reporting the bug and get more information.
- Answering support request and diagnosing bug issues will take a lot of your time. Someone may report a bug with your project which you spend a couple of ours investigating only to realise that you can’t replicate it or it is a problem with their code. This can be very frustrating but often there is no way around it. You do start to develop a sixth sense for detecting when something is a genuine problem vs an implementation problem.
- Let your community help you with support, you don’t need to be the first to answer a question. Others will be happy to share their knowledge especially if there are earning points on StackOverflow and gives other the ability to show off what they know. But if no one else can help be there to help in emergencies.
- Version numbers! I mentioned them before but when it comes to support they become critical! Knowing which version someone is using easily allows you to work out if the bug they have reported has been fixed in a later release.
- At some point you will need to say goodbye to something, it might not be the project but it might be just an certain release. For example your latest release might be v3 but someone asks for support on v1. Be ready to tell them that they need to upgrade and that you don’t support the version any more.
- So now that the world knows about your project, the bugs are coming in thick and fast and your community is building itself. What next?
- The obvious thing is to add more features. Can I make it do more? Be careful when doing this, you need to define the boundaries of your tool before you end up with some mega beast that you have to support. Challenge yourself on new features and think are they needed? I work closely with Nathaniel Mann on Glass and we have dropped many ideas because either out of scope of the core tool or add too much support overhead. It is better to make some compact that does its job well than create a monster that does everything. You also won’t have the time.
- So you have hatched one project, maybe you start another? This really depends on the individual and the size of your project. I have had other ideas which I would like to explore but unfortunately I just haven’t had the time. From what i can tell this seems to be common among other devs running open source projects, the seem to focus on just a main project.
- If it is popular you might want to try and build a business off the back of this. This is currently where I am with Glass and I can tell you it isn’t easy but it is a different kind of challenge. You have to come out from behind the computer and start to think about how you are going to connect with people and what you want to sale. Since the product is free the obvious choices are training and consultancy but this is tough. You need to start thinking about marketing, lead generation, email newsletters, promotions, business cards, billing, taxes……. all the things that aren’t code. I am still learning on this one and I am making lots of mistakes but that is half the fun.
- At some point you need to decide if you want to end the project.
- So to summaries: Starting and open source project is a great challenge with the potential to allow you to learn a huge amount. It will allow you to meet huge numbers of the community, I wouldn’t be talking to you know if I had started it Sometimes it will feel like a second job but there are lots of rewards. How far you take your project is your choice.