Posts Mentioning RSS Toggle Comment Threads | Keyboard Shortcuts

  • Mike 8:41 pm on August 20, 2008 Permalink | Reply  

    Why not an Open Source contribution tax deduction? 

    Have you heard of the Artists-Museum Partnership Act? Probably not. It didn’t even have a wikipedia article until I wrote it. In a few words the act would:

    amend the Internal Revenue Code of 1986 to allow taxpayers who create literary, musical, artistic, or scholarly compositions or similar property a fair market value (determined at the time of contribution) tax deduction for contributions of such properties, the copyrights thereon, or both…

    The artists put a lot of time, creativity, experience, and thought into their work, and then they donate it to museums so that the public can share in this art at a free or deeply reduced cost. This bill allows those artists to be justly compensated for their work. So its good for the public and good for the artist right? Maybe, depends on your political views I’d suppose. And just to be straightforward with you, this is only a proposed bill. It has not been made law yet despite the fact that it was introduced two years ago and has made it through the senate.

    So the question is, if artists can work on their art only to donate it and receive a tax deduction, then why don’t open source project leaders and contributors deserve equal rights? Well first, there are some issues to consider.

    Art is Understood

    Actually art is quite subjective, but that’s not what I meant. Art has been around since the beginning of time, so when it comes to writing and developing federal laws, congress has time and experience on their side. There are hundreds if not thousands of laws governing art. Computers, software, and information technology on the other hand is still very new. Most of it is still not regulated, and the geezers who are writing the regulation don’t know the difference between broadband and a pickup truck. It will still be many years before they get a handle information technology.

    Fair Market Value

    How do you determine the fair market value of open source software? Lines of code? That is a pretty lame metric. How about prevalence in the market place – is more users equal to a great worth? What about cutting edge software? Usually those to enter the market first make a little extra something for the risk and the know how. Forget about the code. What about documentation? And the size of the community. It’s going to be extremely hard to apply any type of accurate value to most open source projects.

    Many contributors

    Open Source software typically has many developers. From the project leaders and major contributors to the developers who simple submit a patch or two. But also consider issues that are reported, documentation, mailing lists, and other support channels. They are in some way or another contribute to the software as a whole and are important to making the software useful. So how do you determine each individual contributor’s value and thus determine their share of the deduction?

    Long development periods

    With art, you have a creation period, then a final release. With software, we have  creation periods that can last years, with many intermittent releases – some of which add value to the software others of which may actually make the software less valuable. So you could take the value of this release less the value of the last release to come up with this releases value. Careful. If you introduce too many bugs, the value could be negative, and could owe the IRS. Wow.

    Difficult to track

    Artists produce a single artifact that is sold or donated. Software is reproducible and is almost free to do so an infinite number of times. The usage of the software is very important in determining its value. For example, a project with a couple of users probably is not worth as much as a project with hundreds of users. Your Pumpkin Path is no where near as prominent as Apache’s Web Server – or is it. How do we know? There needs to be some way to determine an exact user count or at least to determine what grade you might be in, be int 1-10 users, 10-100, users, 100-1000 users, etc. I run Architecture Rules and I honestly don’t know if I have 10 users, or 100. You could look at download counts, but maven downloads aren’t tracked. And what about when one user downloads the artifact and puts it in their organization repository. There could be 100 users from that one download. This would be a hard number to come up with, and even harder the more successful a project becomes.

    Your Next 1040EZ

    The bill is not law yet, but if artists deserve tax deductions for their donations, then so do open source contributors. But we are along way away from properly regulating the computer and software industries. I have also outline a number of major hurdles before us before we can even begin to determine how big that deduction might be. So next April when your filling out your tax forms (yeah, April, because you waited until the last minute) think about how much value you have created with your open source projects and how long its going to be before you see any of that value put back into your wallet.

    The one thing that we can do from here is to keep an eye on this bill. If it goes into the books, then we have something to start fighting for and it might be time to call your less-than-computer-literate congressman or woman and start pressing them for your fair share.

     
    • Mike 1:19 pm on August 28, 2008 Permalink

      Looks like France beat us to this one…

      This summer, an economic commission set up by French President Nicolas Sarkozy recommended tax benefits to stimulate even more open source development.

      Read the rest of the article found at http://ossspyglass.com/

    • Chris 5:04 pm on March 8, 2009 Permalink

      Odd that you mention this — a few days ago there was a Slashdot article on a bill that does exactly what you describe:

      http://assembly.state.ny.us/leg/?bn=A06380

    • George 5:08 pm on March 8, 2009 Permalink

      It’s a great idea in theory, but nearly impossible to implement in practice. There’s no way one can accurately calculate fair market value. Many OS projects only realize their true value to the community many years later.

      Foundations are a more workable model for rewarding open source contributions by programmers. Rather than having to calculate fair market value, foundations may compensate programmers for their actual effort. Donors are rewarded with tax deductions for their contributions to the foundation.

      There are many open source foundations today that take advantage of this model. The Free Software Foundation is one of the oldest around, but there’s also Linux, Apache, and Mozilla Software Foundations, just to name a few.

    • Mike 7:54 pm on March 8, 2009 Permalink

      Thanks Chris, for linking to that.

      NewYorkCountryLawyer writes

      “Assemblymen Jonathan Bing and Micah Kellner, along with a number of co-sponsors, have introduced proposed legislation in New York State which would grant a tax credit to individuals acting as volunteers who develop open source programs. The idea of the credit is to ensure that volunteer developers, who could not otherwise deduct their expenses because they are not part of a ‘business,’ should nevertheless be able to receive a tax benefit for their contribution. The credit would be for 20% of the expenses incurred, up to $200. The preamble to the bill notes that the New York State Assembly itself currently uses ‘Open Source programs such as Mozilla for email, Firefox for web browsing, and WebCal for electronic calendars,’ and that these programs have led to significant cost savings to taxpayers. The preamble also cited a 2006 report authored by John Irons and Carl Malamud from the Center for American Progress detailing how Open Source software enhances a broader dissemination of knowledge and ideas.”

  • Mike 9:36 pm on August 3, 2008 Permalink | Reply
    Tags: , Road-Map   

    Architecture Rules 3.0 Roadmap 

    UPDATE Aug-30-2008

    • added API package
    • added Listeners
    • added Configuration Properties
    • added default-architecture-rules.xml

    OK, lets lay out a road map for 3.0. I sent this message to the architecture-rules-user mailing list and the architecture-rules-dev mailing list tonight. I have a few things that I want to see put into it, and I’d also like to hear what you want in it.

    org.architecturerules

    First. The big change is the groupId which is finally going to be moved to org.architecturerules for the core project and the maven plugin. I don’t have the domain yet. I have a fund raiser page where I was hoping to get about $30 to secure the domain for 3 years. So far no contributions : \ Maybe if any of your work for a company that uses the project, and the company has donated money in the past, you could ask your boss for a small $30 contribution to this project. Regardless, we’ll get it eventually and the project needs to get off of com.* and the maven plugin needs to be the same groupId.

    architecture-rules-ant

    I want to refactor the ..architecturerules.ant package to its own jar so that:

    • User’s who want to use the ant interface and include this jar.
    • By including the jar, you get the Ant jars and dependencies. If you don’t use Ant, you don’t need the jar or the ant libraries.
    • As we add new functionality to architecture rules someone else could take on the task of keeping the ant task up to date on their own schedule.
    • This module also acts as an example of how to extend the core project.
    • Allows us to develop new ant features and fix ant issues without doing a major release of the core. There are a couple of open ant-related issues in the issue list.

    The downsides is that the API is broken, but I think that is OK given in the release  the packages are all changing to org.architecturerules so the API will be broken anyway.

    Issue 59: DependencyConstraintException should report the violating class

    This is sort of a tough issue. We utilize jDepend which only looks at packages. However, Mykola brought Classycle to my attention (which I included on the alternatives page) which looks at class dependencies rather than package dependencies. We could move off of jDepend and switch over to using Classclye to find dependencies, or we could continue to use jDpend, and when a rule is broken, we can jump over to Classycle to figure out which class is breaking the rule. Another benefit to Classclye is that it is able to detect static dependencies which jDpend is not. I actually got an email from SonarJ, a commercial competitor listed on the alternatives page who congratulated us on developing a good open source architecture risk mitigating project but pointed out that jDepend could not detect static dependencies. I think in the long term we need to support detecting static dependencies so this Classycle might have been an important find.

    Looking to get involved? We’re looking for contributors for this task.

    Issue 60: XML reports

    The only other current issue that I would like to tackle somehow is the output of the XML reports. I sent out a pretty detailed email on this to the user and dev mailing list. I got little response. I put a copy of the email in the issue which includes a prototype for the XML output. The premise would be that the execution of architecture rules results in the output of an XML file that describes all of the rules, the packages that were investigated because of that rule, the dependencies of each package that match that rule, and a list of each violation. One major change would be that instead of throwing an exception when a rule is broken, the rest of the packages would be investigated first and then the XML output is written, and then an exception could be thrown describing all of the rules that were broken – not just the first rule.

    The reason for this XML output is two-fold: first, it provides output for other developers to start processing and developing new tools for which could be good for this project. second: it provides a data source for our maven 2 plugin to use to generate a site report for. Or this could be a new project: maven-architecture-rules-report-plugin. Either way, this is a good stepping stone to new functionality and growth for this project.

    Looking to get involved? We’re looking for contributors for this task.

    FindBugs

    We added the FindBugs report recently to the maven-generated site. We should be able to clear this list for all of our code.

    Remove 3rd party org packages

    I had created an Issue to remove unneccessary dependencies to cut down on the number of libraries that we depended on. But I think this was implemented poorly to the point where it caused a reported bug. Also, we have a pseudo maven repository so that makes this issue almost moot.

    This list encompasses most of the open issues in the issue tracker that I want to see implemented. There are a couple of issues that I am going to leave on hold (such as inverting the project to expect the user to define the accepted packages rather than the exceptional packages) and some that I can not fix with out money (continuous integration server).

    All of these tasks are up for discussion. And most any of them are open to user contributions. If you are interested in taking on one of these tasks, just reply to this email, tell us what you want to work on, what questions you have, and maybe describe how you plan on implementing it. If its a small task, you can submit a patch, if its bigger, we can make you a contributor (for a short term or longer term depending on circumstances)

    UPDATE: Issue 68: Listener Support

    Adding support for event listeners gives us a few different things that we either need or that would benefit us in the future.  This will hopefully invite other developers to begin extending the project. For example someone someday might make a GUI tool or an IDE plugin and want to provide real-time feedback to the GUI as packages are investigated. This also enables us to develop the XML report in a very modular fashion, without littering the services with code that is not related to performing the service that the class is named for. Listeners provide a great point for adding new functionality from too.

    UPDATE: Introduce API Package

    Interfaces will be moved to a new org.architecturerules.api package so that developers who wish to extend the project have someplace to start from. This will break backwards compatibility. But so will migrating to org.architecturerules, so if this is going to be done, it should be done now. Sorry everyone.

    UPDATE: Issue 64: default-architecture-rules.xml

    The initial state of the Configuration entity will be created by reading default-architecture-rules.xml. This essentially just allows us to define the default values via XML rather than defining them with java constants which is what we are doing now. This XML file is easier for the user to read to figure out the default values, is easy to add new default values to as we develop new features, and may be used to demonstrate a sample XML configuration or how features are configured.

    UPDATE: Issue 67: Configuration Properties

    The listeners require some configuration. Some other tools that have yet to be written may also require configuration. We’ll be adding support for arbitrary properties. These allow you to define a set of keys and a values that can be handed off to the Listeners and to other features that may be created in the future. This provides a pretty robust mechanism for providing configuration values for classes that extend the project.

    Maven 2 Plugin SNAPSHOT

    And while I have your attention, Mykola has released a 0.0-SNAPSHOT of the maven 2 plugin. Has anyone tried it yet? Anyone want to try it out?

    Thanks everyone.

    http://72miles.com/architecturerules (and someday architecturerules.org)

     
  • Mike 1:35 pm on August 1, 2008 Permalink | Reply  

    Open Source is Facinating 

    It’s true. Open source is is fascinating. Consider these questions (which have been asked by many):

    How does open source work?
    Why does open source work?
    What motivates the developers?
    Who is making money and how?
    What are the open source business models?
    How ubiquitous is open source?
    What is the future of open source?
    Whats with all of these licenses?

    The questions are asked and answered every day. In books, in podcasts, and in hundreds if not thousands of blog posts. I have been looking for these blog posts and I have found a lot of them – but certainly not all of them. Since I was looking for them and finding them, I figured I might as well share them with everyone else who is interested in what makes open source tick. I setup OssSpyglass.com.

    OssSpyglass.com

    Each day I go out and find these new posts and quote them and link to them on this site. But there is so much out there, I had to find a focus. Here is what i came up with, from the about page:

    We aggregate open source news and analysis from the blogosphere. You’re not going to learn about the next FireFox release here, but you might read about their open source distribution model, or how they transparently develop cutting edge software.

    We are interested in how open source works, why it is successful. We are interested in its past, and its future. We want to know whats going on in the open source communities, and what open source users think. We are interested in analysis and development of the open source movement, culture, and process.

    So hopefully these are topics that interest you or that you find important for the future of your career. If so, come check out the site, and consider bookmarking it or subscribing to the feed.

    OSS Job Base

    A second project that I setup off of OssSpyglass is OSS Job Base, using the open source job board JobberBase. The premise is that there are thousands of open source projects out there looking to find development help be it with coding, documentation, or even testing. There are also developers looking to get onto a project, but don’t want to scour bug lists to find issues to fix.

    This job board is setup for leaders of open source projects to post a task. A typical task post should consist if a couple lines to introduce the project, followed by the description of a task. Then developers can subscribe to these job lists and finally find a worthwhile project to put their time into.

    If you’re an open source project leader, come post a task or two. You might be surprised at how many people want to help you, but just don’t know that you’re looking for help. I am aware of sourceforge’s job list but they are anything but free, and if you have a job listed there I invite you to also post it on the OSS Job Base.

    So come check them out. Comments are are appreciated.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
esc
cancel