In February of 2017 I had posed the questions below and received the respective responses from a few veterans in the open source [network automation] community. Though it has been a few years, and I am certain that thoughts and retrospectives have changed since, I think this serves as a good point in time capture of the the author’s thoughts.
A few of the industry best were nice enough to respond.
Original Question: I realized that most channels on here (referring to Network to Code Slack) are either vendor-focused or for a given open source project. Of the latter section, most of these open source projects were started by a people at a company that gave back their work to the community. I wondering if you all would indulge me a bit in commenting on any of the following:
How much time does your employer (or former employer) allow to build project? What is the break down of personal vs “on the clock” time spent?
Matt Oswalt The employer I was working for at the time had a pretty aggressive IP clause in the employment agreement, so I went through legal to get approval first. But other than that, I had an understanding with my boss that I’m a big boy and that I’d take care of my shit. I know not everyone gets that arrangement, but it’s how it worked out for me. Same goes for my current employer – even more so actually because now my day job is open source, so it’s by no means discouraged, again as long as I get my work done. There’s not really a “clock” as long as deliverables are met. (with the exception of scheduled meetings, etc)
Jeremy Stretch NetBox is one of my primary ongoing projects. While my workload varies quite a bit day-to-day, a typical week includes at least a day or two’s worth of time spent on NetBox development.
Jathan McCollum Network Source of Truth (NSoT) is a core product of NetEng at Dropbox and so I am able to spend as much time as necessary working at in on the clock. I’d say t’s about 80% on, 20% off the clock.
David Barroso Hard to tell. I have been lucky enough to work most of the time based on objectives so as long as the job is done nobody really cares what/when/where I do things. In any case, it takes a lot of personal time to manage a project like napalm.
Recap: All of these projects were at least in someway sponsored by a parent company, either formally or informally. These are by in large forward thinking companies that realize the value open source, that the feedback and code provided back far exceed any potential competitor advantage.
Were there any hurdles to open source the project? Was this decision company driven, self driven, other?
Matt Oswalt Again, in my case, I felt compelled to be explicit with my legal department for my employer at the time. I probably could have avoided that and just pushed it, but in my eyes it was simple enough to make my case, and I had the support of my manager, who wanted me to get more involved in open source anyways. So it was a self-imposed hurdle for the most part
Jeremy Stretch No hurdles at all. I’m very fortunate that DigitalOcean is a strong supporter of open source, and was encouraged at all levels to make NetBox public.
Jathan McCollum We started the project as open source from the get go, which greatly simplified things. There wasn’t any legacy cruft or any internal implementation details to factor out. It helps that Dropbox has a very pro-open-source attitude, so starting new projects openly is encouraged.
David Barroso It was mostly driven by me. The hardest part is certainly managing the project; making sure everybody involved goes in the same direction, that issues are handled properly, PRs reviewed, new versions released… it’s hard and requires a lot of work (DM me if you want to be a PM for napalm xD).
Recap: Being self driven or taking an open source first mentality is helpful. Going through the legal process is often not well understood on either side, and making this an outside in approach is not a bad approach.
How did word spread about your project?
Matt Oswalt Tbh, I don’t know of one particular way that word spread….I know there was a pretty popular reddit thread a while back, and I’ve done episodes for Ivan and Packet Pushers, so that’s probably been the biggest avenue. One thing that surprised me was that people actually brought it up in my latest job search – in fact, one entire interview was “explain to me how ToDD works”. No joke!
Jeremy Stretch I announced the open source release on my personal blog, which provided the initial publicity. Word spread pretty quickly, and hosting it in DO’s already-popular GitHub account surely helped.
Jathan McCollum Mostly through the NTC community, GitHub, and IRC. @jedelman8 also invited me to speak last year about NSoT at Interop in Las Vegas. I’m sure that helped!
David Barroso Talks, slack, podcasts, social media, word of mouth… Any free form of communications :stuck_out_tongue:
Recap: A mix of mostly self promotion and good ideas got these projects moving. A healthy dose of leveraging external platforms such as Slack, talks, and podcasts is certainly helpful. I also think one thing not captured here is the maintenance on all of these projects is high. It is really not an easy task to keep up with open sourcing a project, there are many barriers to entry most of all is time.
Did open sourcing make it easier or harder to maintain? What is the best and worst part about the larger community?
Matt Oswalt Easier. Getting folks like @vcabbage on board that have more Go experience than I do was super helpful.
Jeremy Stretch It’s definitely harder to maintain as an open source project, simply because I can’t control the pace at which issues are opened. Sometimes the influx of requests and bugs is difficult to keep up with, but overall the feedback is invaluable.
Jathan McCollum Open sourcing an existing project will definitely make it harder to maintain at first, primarily because of the internal reviews and refactoring of internal implementation details into configurable settings or plugins.
I already have experience maintaining projects in the open because of my other project, Trigger. Since NSoT started as an open source project, it was much easier to frontload any issues of internal settings to matters of configuration settings within the project.
I feel that in the long-run open source projects become much stronger and easier to use than internal projects because of the requirement to always consider how others who don’t have access to your internal services might utilize the project. The best part about larger community: Having people you might not ever meet or work with help you solve complex problems you just haven’t had time to get to, can’t reasonably prioritize yourself because of business requirements, or catching typos in docs you overlooked. The self-selection of the technical community around the projects is inspiring.
The worst part about larger community: Bad contributions. People who don’t know how to read docs, aren’t native English speakers, who don’t understand things like code style and unit testing… They can be a drain and a time sink and you sometimes have to make the hard call to say “No I can’t help you” or “No, I will not accept your pull request”.
David Barroso Certainly harder. You have to take into account things you might not otherwise. For example, documentation is harder as you can’t assume knowledge or expertise, code has to be more generic and avoid business logic… It certainly adds a lot of overhead. The best of working with the larger community is certainly the community itself. I never imagined how “big” (by some definition of big) napalm was going to become and how many people would get involved and get passionate about it. It’s great. The worst, having to manage the project :stuck_out_tongue:
Recap: A mix bag of answers here, which is somewhat to be expected. There is inherently a pro & con to open sourcing a project. One through line is documentation, you truly have to consider a much different audience for this to work correctly. Also contributions are simply not that cut and dry.
If you “had” to do it all over again, what would do different? e.g. different language, design more upfront, use data-driven model, less feature, more features, etc…
Matt Oswalt I built ToDD to force myself into learning Go primarily – my goal was never to have any sort of productized or even remotely popular project. However, the idea held water after a bit, so I guess the only thing I regret is that I didn’t try a simpler project first, so I could ensure things were as idiomatic as possible. That’s sorting itself out as I grow, and as folks like @vcabbage contribute, but still there’s a lot of tech debt. Also, and this is because of the same reason, I regret not following TDD. I’m used to Python where I can just mock everything and anything – and in languages like Go, you have to design things to be testable. So I wish I had started down this path earlier, much earlier
Jeremy Stretch I would have stripped out the undocumented (and pretty awful) RPC functionality before releasing the project. And maybe invest a bit more time into the installation documentation.
Jathan McCollum – Should have implemented Python3 support from the get-go. It’s still Python2 only. :disappointed:
- Should have decoupled the web UI from the backend, because I’m not that good at fron-end dev & it’s lagging in feature parity. The GUI is still an important part of NSoT, I just don’t think it makes sense for it to be a core part anymore.
- I would have started using Django from the get-go. We decided to build the app around Tornado at first, because Dropbox uses it. Not long after the project kickoff this turned out to be a bad decision and cost a LOT of time in refactoring everything around Django.
David Barroso I don’t think I would do anything different. Not because the project was perfectly done from the beginning (far from the truth) but because every mistake had positive consequences. Either it meant assumptions/simplications that allowed the project to grow faster or it meant learning valuable lessons for the future. Improving/refactoring/deprecating code is part of the process.
Recap: Another mix bag of answers here. The primary through line is, you can’t get it right first and you should take an iterative approach. This is likely true of any programming project, and echoed throughout much of the available literature on the topic.
Similarly, any lessons learned to pass on?
Matt Oswalt This is a lesson I’ve not only learned in my OSS projects (side and dayjob) but also in previous code related jobs. Stop worry about what your code looks like. Everyone wants to just push a single big commit, only when it’s perfect. Please don’t do that – if you have code you want to work on, work on it in the open. Make at least one commit a day, even if it’s shit (and push it to github!). No one that cares to read your code is going to call you dumb…..they’re going to help you. And you’ll naturally insist on higher quality just knowing that it’s going to be public in a few minutes. If you’re working on an idea, do it in a “work in progress” PR….we do this all the time on the stackstorm team, when we’re working on a PR that we’re not quite done with. That way, people can see where we’re at and let us know if we’re about to go off a cliff.
Jeremy Stretch Decide on and establish your primary medium of communication before the public release. I had set up a subreddit initially, then pivoted to a mailing list, which has caused some confusion.
Jathan McCollum Don’t be afraid to share your code! I’ve seen many network people afraid of the scrutiny of their code being on GitHub because “they aren’t coders”. Don’t let that hold you back. The majority of people in open source genuinely want to help and spend their free time doing this FOR FREE. Never forget that. I want to see your code because it shows me how you think, and to a more selfish degree: I want you to help me make my projects better! So never forget that either: There is no selfless act, especially in the open source community.
David Barroso This is no different from any other project you have already worked on. People with different levels of expertise might jump in and people will have opinions. Don’t take things personal and try to learn and have fun.
Recap: Do not suffer from imposter syndrome! I have heard Matt speak about this a few times, and I think he does a good job recapping here. It is certainly vulnerable to put yourself out there, but the pros far exceed the cons here.
