Your SlideShare is downloading. ×
From open source labs to ceo methods and advice by sysfera
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

From open source labs to ceo methods and advice by sysfera


Published on

From Open Source Labs to CEO_methods and advice by SysFera

From Open Source Labs to CEO_methods and advice by SysFera

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Outline The context Industrializing an open source software Selling a product Conclusion(s)
  • 2. The context
  • 3. Meh CEO@SysFera Previously research engineer @INRIA in the GRAAL AVALON research team (LIP/ENS Lyon)
  • 4. SysFera We provide software for the usage and management of HPC IT infrastructure in a hybrid Cloud mode 12 people located close to the INSA campus (the weirdos doing pixel art on the windows? That's us.)
  • 5. References
  • 6. Where it all began DIET (Distributed Interactive Engineering Toolbox) created in 2001 Middleware for HPC : How to access an application on a distant server in a ASPSaaS fashion Leading implementation of the OGF’s GridRPC standard
  • 7. The Décrypthon project Early adopters, guiding us on the path of industrializing research software The computing platform of the Téléthon : provide a simple to use grid platform for biologists Sponsors: AFM, IBM, CNRS 2007: DIET replaces proprietary middleware (o/) Has been up and running 24/7/365 between 2007 and 2011 Wait... what if we create a company to do that for others?
  • 8. Industrializing an open source software
  • 9. The path May 2008 : Let's create a company ! March 2010 : birth of SysFera Original idea : We must secure the IP and structure the development process Building up a commercial offer around DIET while staying true to DIET's OSS roots
  • 10. Code is IP
  • 11. Code is IP Before creating a company you need to secure the IP from the inside from the outside with the authors
  • 12. Manage your code's IP architecture Code snippets from the Internet? Third-party libraries? License? Any global coherence in the IP’s perspective?
  • 13. Manage your code's IP architecture Possible solutions: Antepedia Suite : They’re coming from INRIA and it’s OSS! {eyes, hands, head, jurist}
  • 14. Software patent? Patents? Publications? Clone of your technology in the real world? Define your innovation/process Study patent claims... VERY accurately.
  • 15. Software patent? Possible solutions: {A consulting firm in IP} {eyes, hands, head, jurist}
  • 16. Manage the past ... It WILL be the most time-consuming part. Check developers’: contract type, lab, institute, faculty, etc. What part of the IP do they produce? Who owns the code? What business model for what business plan? Most of the time authors don’t know anything about that Above all: be patient!
  • 17. Manage the past ... Only solution: Patience, Time and Tenacity
  • 18. ... and the future Who will contribute? What about the community? Will you be able to use that code in any situation? Who will lead the project? What’s the road map? How will you manage the code? (Client/Research)-driven commits?
  • 19. ... and the future Only solution: Clarity, Perpetuity, Serenity
  • 20. But code is also code
  • 21. But code is also code DIET comes from a research lab SYSFERA comes from a research lab All of use were coming from research labs We needed tools and methodology to get the job done, clean and fast So we didn’t follow the (easy) (evil) path of proprietary software!
  • 22. Version your stuff Track every change and revert them Forget CVS and fully embrace Git Prefer atomic changes over monster patches!
  • 23. Build your stuff Tracking bugs takes up half of your time (conservative estimate) The sooner, the better You know where this is going, right?
  • 24. Continuous Integration 1. compile manually 2. automate compilation from repository with cron 3. add up unit tests and crappy mails when compilation fails 4. add quality checks 5. now install a CI server with shiny graphics 6. make developers who break builds bring pastries the next morning!
  • 25. Your build system is your friend Automates tasks Good support of parallel jobs (scons out) Extendable Easy to learn and use (autotools out) Multi-platform We are using CMake + make/ninja
  • 26. Unit Testing Testing is boring Humans don’t like boring stuff However, it saves time by quickly detecting regression it helps detecting dead code We are using Boost Unit Tests Framework
  • 27. Document your code DIET has nice user and developer guides The API documentation, however, not so much Developers hate writing anything else than code (to the coders here: you know it’s true) We are using Doxygen
  • 28. Continuous Integration Automates ! Don't do the annoying stuff Lots of OSS solutions We are using Jenkins
  • 29. Plan things Plan your development sticking to defined release cycles Define priorities Structure your developments through projects Choose your preferred development method (something agile!) Involve your community in the debugging!
  • 30. Be Agile like a monkey!
  • 31. Be Agile like a monkey! Prefer small iterative cycles Plan, test, document... ... The sooner, the better Get your toolbox ready
  • 32. Communicate With your management With your sales and marketing department With your clients With your community ... And others, through projects or events
  • 33. Get a real marketing guy or girl (or a hippie) Or you may end up with such a logo no comment
  • 34. Selling a product
  • 35. Selling a product To create a company (and sell a product) is an adventure itself. Nerd -> CEO
  • 36. Goal Products must be meant to solve customer pain ... ... but in labs you don't meet a lot of customers... ... and a feature for a user is not what we may think it is.
  • 37. Business & Marketing When should we say no (or not now) to a user/customer? How to build a road-map? Nice to have != Nice to buy Innovation can lead to new markets ... ... And unknown application fields! How to know the customer needs when there is no existing market? Being too innovative can be a hard problem -> evangelism/"too much"
  • 38. Technology Framework or not? How to choose between complete modification and slight changes? Be Agile in every way!
  • 39. Techno push vs Market pull
  • 40. Conclusion(s)
  • 41. Sad conclusion Software does not matter UX and User satisfaction matters
  • 42. But being innovative is the key to our success It's hard, but that's the good way And research labs are the best place to find innovation To be here tomorrow: don't fight the change, accompagny it
  • 43. Happy Conclusion Really cool adventure Developers are artists Innovation, agility and user satisfaction are the keys to success It's a pleasure to see customers happy with your code I'm proud to say that 13 people are now working thanks to code developed by researchers from INRIA, CNRS, etc.
  • 44. Thanks Mail : Twitter : DIET website : SysFera website : SysFera@github : @DavidLoureiroFr