

In .NET, open source does not beget open source - bvanderveen
http://bvanderveen.com/a/dot-net-open-source-does-not-beget-open-source/

======
gm
I disagree with the point of the article. I think This is more of a platform
gripe ("I hate it that this stuff is unfamiliar to me!") than an actually
valid argument.

The same could be said for someone learning Linux for the first time, writing
about how difficult it is to get X project compiling, or starting a project
from scratch. Vi, Emacs, no IDE, dependencies, make, cross platform
incompatibilities, etc are all gripes that could be said of any OSS project of
decent size. All with an equally good sob story about just how hard things are
to do.

It boils down to the fact that learning new stuff is hard and inconvenient
because in the environment you have just spent X years developing on it's so
easy.

Which is a fair enough point, just don't mislabel or misattribute it.

EDIT: Also the headline makes no sense. Platforms don't beget open source.
People and open source licenses do. If it does not exist, create it and share
it. Is that not the whole point of OSS?

~~~
rbanffy
> I think This is more of a platform gripe ("I hate it that this stuff is
> unfamiliar to me!") than an actually valid argument

It actually went to great lengths to demonstrate how hard it is to do cross-
platform development with .NET. The article describes the problems of having
IDEs that rewrite makefiles in incompatible ways.

> The same could be said for someone learning Linux for the first time

Makefiles usually work. You may need to install some library through your
package manager or build it yourself, but, then, you are a programmer, not an
icon-dragger.

> It boils down to the fact that learning new stuff is hard and inconvenient

While learning new stuff can be hard or inconvenient, it has nothing to do
with the problem the article describe. The article describe the problem of not
having a clean cross-platform workflow programmers running Visual Studio and
Mono Develop can use to seamlessly collaborate on the same codebase, something
that's really easy for just about anything else.

~~~
recoiledsnake
>It actually went to great lengths to demonstrate how hard it is to do cross-
platform development with .NET.

Being cross-platform has nothing to do with being open source. They are
totally orthogonal. The article conflates both of them.

~~~
Herring
Open source stuff is often ported to other architectures because it's open
source. The point here is using microsoft tools makes that difficult... though
I'm not sure why anyone would find that surprising.

------
jimbobimbo
"Ignore for a second that MonoDevelop and Visual Studio will fight over the
formatting of those files, stomp on each other changes, and add garbage that’s
meaningless to the other. A VS- or MD-generated .csproj will be default import
some target definitions called"

Manual or unrecognized changes in project XML files will be preserved by (at
least) Visual Studio - this is "by design" behavior. If MonoDevelop discard
unrecognized constructions, this must be a bug.

"Microsoft.CSharp.targets. Uh oh, what’s that? Where does that live on my
system? What does it do? What package do I have to install to get that?"

MSBuild.

"Well, I don’t want to include that DLL in source control because checking
binaries into source control is a no-no."

Wrong. Test framework is either a dependency library or a tool and MUST be
included under \lib or \tools folder, under the name that contains version
information (say, "nunit-1.2.3"). Another way is to add library code as an
external dependency and build it every time, but I think this is overkill in
this particular situation. Bottom line: by keeping 3rd-party dependencies
(libs or tools) local you will be getting people up to speed in no time as
opposed to having to maintain detailed instruction on where to get software
and how to install it.

"Pretty nice! I have separate commands for msbuild and xbuild to build the
.csproj files that my IDE understands, but hey, just an implementation detail,
right?"

Or maybe you could create an environment variable / macro that would perform
all required substitution and make your build code easier to maintain.

"Doing it in Ruby is a heck of a lot easier than using the ZIP task in MSBuild
and I don’t have to worry about cross-platform issues."

I think this pretty much summarizes the article: new set of tools + unfamiliar
environment = lots of grief.

About me: I maintain pretty large Windows-only project with tons of
dependencies on 3rd-party .NET and COM binaries; support one-command builds
into multiple release configuration, automatic versioning and hourly builds on
Hudson. It took a couple of weeks in total to setup everything, but in Quick
Start document I have only instructions on how to install Visual Studio and
checkout latest code.

Another project is an ASP.NET MVC project, where my build script in addition
to building the thing, uploads binaries and content onto separate servers and
does some admin stuff over SSH.

I mean, know your tools, as usual.

~~~
hello_moto
Regarding dependencies:

Ruby has Gems

Node has npm

Java has Maven

.NET has ____

I don't argue too much about checking binaries into source control but other
development environments have probably smoother situation compare to .NET when
it comes to 3rd-party libraries.

NuGet is close but not quite there yet.

Regarding Build: MSBuild is akin to that of Ant in Java. Considering that many
of Java developers either have moved or are moving to use Maven, it's quite
clear that .NET is lagging behind.

Correct me if I'm wrong, even Clojure leiningen is very similar to Maven.

There's some truth to his grief. Even if you're familiar with .NET tools,
other platforms provide better experience.

~~~
gecko
.NET has NuGet. You yourself mention it, then throw it out as "It's not there
yet." If you're going to play that game, you have to at least explain what
about NuGet is lacking.

Currently, NuGet:

    
    
      * Is trivial to use
      * Can be set up on your own box for private packages
      * Has a pretty huge collection of packages
      * Avoids jamming libraries in your SCM
      * And pertinent to this article: works fine in Mono
    

I know that Gems/pip/whatever have various trade-offs, but you can't summarily
ditch NuGet without at least explaining why.

~~~
hello_moto
Does it work in Linux?

~~~
gecko
Yes: since at least around October or so, NuGet.exe (the command line) works
just fine under Mono in Linux. This is all you need to create and install
NuGet packages. MonoDevelop does not yet have integration equivalent to
VisualStudio's, but that's not a big deal.

------
hkarthik
OSS authors that write apps in C++ have complained about nearly the exact same
problems and often ignore Windows completely for many of the same reasons.

I think the only viable approach for cross platform OSS on .NET is to take a
Mono-first approach and then package for Windows developers in a subsequent
step using NuGet.

It's kind of a backwards approach by targeting 10% of the market first then
later targeting the 90%, but it's likely the only way to ensure cross platform
OSS when you choose to use .NET.

That being said, I don't miss .NET at all. Dip your toe in other frameworks,
you'll find it's much more conducive to OSS work.

~~~
MartinCron
It's not really backwards to tackle the hard problems first to prove they can
be solved, but it is counter-intuitive. Thanks for this tip.

~~~
aaaaaaaaaaa
you are wrong, imbecil la puta que te pario

------
mmcconnell1618
You make some great points about the difficulties in running a cross-platform
.NET project as open source. However, I think the cross-platform difficulties
are only a small part. Open-source is very new to many Microsoft developers.
Just getting participation in .NET projects that are Windows only is difficult
(but not impossible). Many Microsoft developers have had years of "training"
that open-source == buggy and has support issues just like many non-MS
developers have been "taught" that .NET is a legal trap so don't touch it.

I think the perception has been changing in recent years and open-source .NET
is now well accepted in some circles. As the trend grows I think you'll start
to see better cross-platform tools and support for your package management and
testing problems.

Who knows, JavaScript might just become so dominant that open-source .NET
never reaches its full potential.

~~~
kermitthehermit
The problem is that some people still remember some of the stories about how
Microsoft blackmailed some hardware vendors to stop shipping devices with
Linux and how they sued companies which sell Android based devices. Because of
that reason, it's not that hard to imagine a scenario where Microsoft got
"stabby" and wanted a piece of someone's cake.

node.js / python / php / ruby (with all of their frameworks) are far better
choices than .net. At least they're backed by a lot of people and they all
seem to be doing fine. They're pretty much the same across distributions /
OSes / architectures from the point of view of development and of the
delpoyment (to some extent).

I played with the nancy framework when I was considering an alternative to
python for a small web service which required high rps / server resources.
Needless to say, I decided to stick to python due to the lack of instructions
for compiling on Linux and deploying on mono.

~~~
rbanffy
> remember some of the stories about how Microsoft blackmailed some hardware
> vendors to stop shipping devices with Linux and how they sued companies
> which sell Android based devices.

Sadly, this is not limited to the past. Microsoft _is_ using patent extortion
to get a couple bucks for every Android device sold.

------
teyc
Read the article carefully. This guy has a point.

Zipfs law applies to software stacks. There is always a leader , the second
and third place drops off exponentially. So, in .NET, the leader is obviously
MS with its tooling. However, these tools aren't as lightweight for someone
who came from Ruby and command line tools. While scripting is possible, one
has to patch together the information from various sources.

@jimbobimbo has said that it is possible to script. But it took him weeks.
There is no obvious .NET stack (by stack I mean Build, Test, Deploy) that
champions lightweight systems.

VS writes tools for software stacks. Not quick dirty scripts. This is the only
thing they get paid big $$$ for. However, it is not actually what the customer
wants. The customer wants a solid runtime, easy to debug stacks and fast
turnaround.

I believe NuGet is a step in the right direction, usable from both Powershell
and VS Shell. However, it is going to take another generation before MS starts
to understand how to make the rest of their infrastructure scriptable.

------
jroseattle
While the title of the article is true, the content doesn't really support the
idiom. Lack of familiarity with tools and utilities seems to be the theme
here. It would help if MonoDevelop and Visual Studio played well together, but
they don't. Portability across platforms with .Net isn't easy, that's for
sure.

For OSS .net projects I've been involved with, we've made conscious decisions
about code distribution. Those included unit tests (we chose nUnit) and builds
(VS sln files). Did we forego all those mono developers? Well, yes and no.
Yes, in theory; no, in terms of anyone who was using our code in a Mono
environment. To bridge the gap, we rolled a MonoDevelop project file, and put
up some info about it on our wiki. To date, we never had anyone ask for build
assistance in Mono.

While I get the sentiment, it's not nearly as big a problem as getting .Net
developers engaged in more OSS projects.

------
kiloaper
The only major project that comes to mind using Mono on multiple platforms for
a biggish open source project is OpenSimulator
(<http://opensimulator.org/wiki/Build_Instructions>). I wonder how they
overcome those issues.

------
iso8859-1
Isn't this pretty much what the GPL was designed to solve? Stallman had to
make sure the derivatives were open-source to make GNU going. If he used the
MIT license, people wouldn't have felt the need to try and build something
that could compete. But because they knew their rights were protected they had
a chance against the reigning.

------
radicalbyte
No comparison against Java? That would be the obvious point to compare, given
that it's the most comparible to .Net. Yet he has only listed dynamic (and
mainly interpreted/"scripting") languages.

A few points:

1) GAC Deployment of 3rd Party Libraries

For many libraries it isn't required. Many libraries are fine with simply
shipping the DLL.

Sure, a lot of the Microsoft libraries/frameworks do require a GAC deploy, but
that's to be expected. They've pretty much been designed for clicky-clicky
"developers". Coders tend to avoid these like the plague : as should you too.

2) Testing

nUnit works fine on both Mono and Visual Studio. What's the problem with using
it? That you want to integrate with TFS? If so then your problem's clear.

~~~
gm
FWIW, the MS world has a lot of hard-core scary-smart coders.

And GAC deployment does not have much to do with clicky stuff. GAC has to with
with DLL hell, and you need to jump through some extra hoops to deploy there
(ie, <http://support.microsoft.com/kb/324168>). Or maybe you intended
something else in your comment, but I missed it. Is the GAC inferior (since
you put the word developers in quotes) because it allows the programmer to
find references without searching through folders? Sorry, I just miss the
point of the comment.

~~~
radicalbyte
The original article was complaining about the requirement to GAC deploy
libraries and being hard to test: my reply was that it's often not required.
Microsoft's own products being a prominent exception (think Entity Framework,
Workflow and System.Globalization).

The Microsoft World is split into two camps:

a) The kind who like using the drag-and-drop tools and having all of their
code generated for them. these are generally the less technical crowd.

b) The engineer type, the type who know what SOLID means know when to use (and
not to use) a range of patterns. They're often proficient in several
languages. This crowd tends to be more technical, and more critical of the
products Microsoft build on top of the CLR.

I'm in the second camp (and I guess that the vast majority of MS HNers are
too).

The first camp are common referred to (and refer to themselves) as "Microsoft
developers".. and they're by far the largest (but least vocal) group.

------
recoiledsnake
What has this got to do with open source? Imagine a open source project hosted
on Team Foundation Server and the contributors all using Visual Studio. Is
that project any less "open source" than other open source projects? Why will
that .NET project beget something that is not open source? Doesn't make any
sense.

The article should be titled something like "Cross-platform development of
.NET is hard". And then go on to talk about how that can be a hurdle for open
source development.

~~~
bvanderveen
Fair.

~~~
sriramk
Completely agree. To use a different analogy, this is like writing ObjC code
using XCode and talking about how hard it is to compile outside the Apple
world of tools (perhaps using GNUStep). It is no less open source.

~~~
aaaaaaaaaaa
Completely agree.....idiot....pelele...la puta que te re pario

------
aaaaaaaaaaa
Enema enema.Enema enema

------
WheelsUpper
Who posted this NOOB .net blog post?

If you don't know how to do this, find someone who does.

