27. November 2014 21:11
There is a problem within our industry, particularly around .NET, known as the "no-contrib culture". That is, companies take and benefit from OSS but don't given anything back and also prevent their employees from doing so. A while ago I blogged about
establishing an Open Source Software policy at a proprietary software company that happens to consume and depend on a significant amount of open source libraries. eVision was a typical company in that the standard employment contract had that catch-all clause that they own everything one does on a computer.
With the proliferation of OSS, the fact the platform we predominately build on is going OSS
, and the fact that OSS is a viable business strategy (even within proprietary businesses
), this was a somewhat short-sighted. Indeed, several employees were simply ignoring this; a situation which was in neither party's interest.
Thus I am delighted to announce that we have established a policy that we believe strikes the right balance and have made it available on our github organisation site
In layman's terms, this means that our employees are free to create any sort of open source outside of business hours (as long as it doesn't compete with our business), are free to contribute to open source we depend on at any time, and they own the copyright to that work (or whatever the terms are of the project they contribute to). The only real stipulation is that the project's licence must allow us to use it in our commercial software.
We hope this will have the effect of encouraging contribution to the platform we depend on strengthening it to our mutual benefit. We also hope that engagement with the open source community will have a positive learning effect for our engineers.
I personally hope that more organisations and companies adopt our policy and make it known publicly. Thus, we've released this policy under a creative commons licence. Disclaimer: you should have your lawyer check it over!
To all developers out there, when considering whom to work for I would strongly suggest that you should only look for organisations that have this or a similar policy in place. These are mature organisations that care for the platform and ecosystem they and their staff build upon.
20. April 2011 15:22
Honestly, I don't care if you are a spaces kinda person, or a tabs kinda person, or your class members start with 'm_' / '_' / nothing at all. What ever you choose, just be consistant throughout your code base. It makes your code readable and approachable, especially for someone new to the project. And if you have multiple people commiting use StyleCop to enforce a consistent style. Consistency trumps style preference each and every time. It really helps stave off code rot too.
This test method is from the NuGet source:
The NuGet project is well layed out and very approachable. When contributing to OSS project, you will have a better chance of getting your pull request accepted if it matches the maintainers style. Here we have different casing style for locally declared variables and an unclear rule as to when one should use var or not. All in same method so was probably written by same person. This add a barrier, albeit a small one, to contributing.