> Because I'm just a single person and I don't want to offer up my spare time doing support or dealing with feature requests that I don't care about myself [...]
Sort of defeats the point of open source, no? Sublime Text's author could argue a similar case about keeping it closed source himself.
The rest of the same paragraph that you skipped is:
> If you want a feature implemented or a bug fixed, fork it and implement it yourself and submit a pull request when you're happy with the implementation.
And this is exactly the point of open source. You have the source, you can change it, or pay someone to change it, you can contribute back. Not being able to request features for free doesn't make it against the "spirit of open source".
And this is exactly the point of open source. You have the source, you can change it, or pay someone to change it, you can contribute back
while I agree this is at least one of the points of open source, it's also one of the reasons it's pretty hard to get someone who is either not a developper or doesn't have time to play with the source to turn from the commercial to the open source side. In my experience users out there want something that Just Works, or will be fixed within a reasonable time. If they read something like this, they go all like "wtf is this mentality, I'll just buy something instead"
Paying money for software (open or not) is not something immoral, in fact, to me it is the way it should be for most cases.
Also, Open Source should be important to developers. Aren't you a developer? Then be prepared to pay if you want something that's not implemented already. Not being able to program is the illiteracy of this century.
Not being able to program is the illiteracy of this century.
I'm getting pretty tired of hearing this. It isn't the case at all. Not knowing how to use a computer is `the illiteracy of this century', but claiming not knowing how to program is illiteracy is like claiming not knowing how to play piano makes you tone-deaf.
Completely agree. I AM a developer, and I still would have no idea how to help 90% of the projects that I use as dependencies. Each developer has their own area of expertise, and it is completely unreasonable to expect everyone to be able to fix everything they use without an ungodly amount of effort. Sure, I know how to code, but if my graphics driver has a bug, someone telling me "hey it's open source, why don't you fix it?" seems like a completely disingenuous response to me.
But musical literacy does require that you produce music on some instrument or with your voice, and it is rare that any level of musical training would advance very far without a basic understanding of how to use a piano to pick out some notes for reference. You could decide to learn music without ever learning the piano, but you would have to take great pains to avoid it.
Being able to use a computer but having no understanding of how to program it is like being able to operate a record player. Certainly, some people can do masterful work operating a record player -- to the point of an art. You may even learn to operate it in such a way that you could express your own musical ideas. But learning how to operate a record player does not make you musically literate.
I do not think that everyone needs to be a programmer, but I do think that computer education in our schools needs to at least introduce the basics of programming to every child. Even if they do not program for the rest of their life, it will give them a foundation for solving problems and improve their ability to use software others have written.
I agree with you, actually. I just wanted to cover my bases in the event that there's some composer out there who never played an instrument in their life that I'm unaware of.
> I do not think that everyone needs to be a programmer, but I do think that computer education in our schools needs to at least introduce the basics of programming to every child. Even if they do not program for the rest of their life, it will give them a foundation for solving problems and improve their ability to use software others have written.
Totally agree. I actually got an Arduino starter kit for my little sister's birthday for this very reason. It's over her head at this point, but I remember LEGO Mindstorms being over my head when I was her age, yet still being fascinated with it.
Not being able to program is the illiteracy of this century.
While I agree with this sentiment, I think it's patently false. The vast majority of people have a hard enough time using Word or Excel, let alone being able to understand programming concepts or actually being able to program!
I have a hard time using word because it always tries to fight what I am trying to do. It is a complicated piece of software that requires quite a bit of time investment to actually understand how everything works.
In my experience with my other open sourced stuff on Github, others fixing stuff is very rare. Having issues enabled quickly turns into users demanding fixes and no amount of asking for others to chime in aiding with pull requests actually result in pull requests.
IIRC most pull requests come either out of the blue for something new no one has requested before, or they don't come at all until I explicitly say "I'm not going to fix this" and close the issue.
I've had several bugs fixed in quite a few of my open source projects. Even bugs I've posted on my own projects. And they have only a fraction of the attention yours does.
Why not open the issues up and see if it works out? If anything, you can close them if it's becoming a burden.
In any case, thanks for open-sourcing this project.
Then they can fork it and allow people to post issues on their fork... but this does get me to thinking about how many people even involved in the FOSS world don't understand it very well. Perhaps I am the one wrong here.
I suppose, but then you also need to remember no software is bug free (especially not new software). Maintenance is not a step of software development you can just gloss over.
So the only thing I can think if I were to decide using this software is that I will be happily coding along until something breaks. I'll look for a place to open a bug or issue, and see I can't!? At that point I would just go back to some other properly supported editor.
That's true. But if few more developers start issuing pull requests, then the maintenance team could arise out of that, and project would eventually start to also accept bug reports and feature requests. But in this phase, it's obviously that in this time frame the goal of the main and only developer is to get to the point that he has something that "works for him" and has a solid foundation he likes before making it usable to others.
So yes, it's perfectly in the spirit of open source. And no, it's not (yet) production ready for general (non Go coder) audience.
So the only thing I can think if I were to decide using this software is that I will be happily coding along until something breaks. I'll look for a place to open a bug or issue, and see I can't!? At that point I would just go back to some other properly supported editor.
The benefit of free software (open source plus the freedom to modify and distribute) is that you don't have to do this. You can fix the bug yourself and continue on your merry way. There are many, many stories of companies/people that lost thousands (or sometimes millions) of dollars just because they depended on a piece of proprietary software that became unsupported (for whatever reason) and there was nothing they could do about it.
You could contact the dev and have a discussion with him! If the dev doesn't want it to be a feature in his software, you can post your changes as a plugin/add-on. Effort spent on improving a software rarely goes wasted.
> Effort spent on improving a software rarely goes wasted.
Rarely wasted? Have you seen how many open issues and pull requests on github just languish there forever by unconcerned maintainers? Or projects with a million forks because the maintainer has moved on?
Stating up front that you're not going to even entertain bug reports definitely has an impact on those wishing to improve the software and contribute back. For one, it precludes an entire class of supporters (users who report bugs) from even helping out at all.
For this project in particular in its current state, I don't need people pointing out where it's broken. I know that it's broken and close to useless in fact and that there's a huge list of things to fix, implement or improve.
So if closing up the issues section gets rid of this unneeded negative reinforcement, that's a good thing and working exactly as intended.
It is absolutely your choice to have issues or not and as you describe the current project status it is almost certainly the right choice for the moment.
If you intend to the issues up when you reach another state (e.g. widely usable) then indicating that the not accepting issues is a temporary state would be good. I completely understand not wanting issues raised when you already have dozens of things that you know that you need to do already.
From a user point of view the issues list is something I often look at before even using a project to see the activity, scale of the current problems people are having. I also find it a useful source of answers/workarounds. That doesn't mean that you can't be decisive about what issues you choose to work on (from a user perspective a clear response of "no time to work on this issue, send a PR if you sort it" is better than silence).
If you file the issues yourself, you can show to everyone else that you're working on them. That's exactly the kind of communication ST is lacking. Plus, you'll learn about bugs you didnt encounter, so they can be fixed (by you or others) before you have to hit them yourself.
Give the guy a chance to write a functioning editor first. I'm sure he'll reconsider opening up the issue tracker after the thing is actually useful, and maybe has a few more contributors to share the load.
No one is entitled to anything with open source, not even support or a bug tracker. The author is trying to provide an open source alternative to a closed source product controlled by an uncommunicative company. He deserves support and help, not people telling him what to do.
Try walking a mile on his shoes. Bug triaging is a burdensome task. It is perfectly understandable that, for a one man team working in an incomplete software, his decision is to focus 100% in development of his vision.
Or are you volunteering to do the bug triage part?
You're exactly right. I've heard a lot of developers burn out over the sheer amount of work github generates, let alone the amount of entitlement people feel to your labor once you publish your code. If we want to do social coding, we need to be sociable about it.
On various open source projects I have been running, people have requested that I implement this or that feature of zero interest to me. Most are presented as suggestions but some are rude and demanding. I have never understood this mindset. The fact that I am sharing code that I wrote means that I am now obligated to offer support and implement stuff that I don't care about?
The way I see it, the "point" of open source is just that: the source code is open -- for you to see, use and modify if you like. The author is free to do what they want with their time.
This is what professional support contracts are for. If someone really wants something implemented that is of no use to anyone else, then they should pay for it.
Not everybody wants to make a career out of their side project. Just because you offer me money, doesn't mean I should be obligated to take it. (By all means, offer the money to somebody else, just leave me out of it.)
I'm ok with that. What I'm not ok with is when people use open source as an excuse for mediocrity. Many times you do hear "It's open source, I'm doing this for free, just fork it!" when it probably should be "It's a hobby project, it probably won't go anywhere and the code wasn't really made to be used by someone else, but if you can find something useful you're free to use it". There are a lot of active open source projects out there that spend a lot of time maintaining their project and I think it's kind of "meh" to undermine the positive things they've been working for.
I have absolutely 0 problem with this, as long as a disclaimer is listed like the OP did. I honestly think this is the right way to do it. Imagine though if apache had some major security flaw uncovered tomorrow and the maintainers said, "This is just an open source project. You are free to look into the issue and fix it yourself if you want. We will merge the pull request when we get around to it.". Managing expectations is-- as usual-- everything.
You might need to point those people to an open source FAQ stating that you do in fact have a day job and that you cannot find time to support changes you do not care for unless you are getting paid to do so and that if the person wishes they can hire someone to fork the code and implement it themselves and you will be happy to take the pull request
I think the author makes a point here, he is making it Open Source so that anyone who wants to tinker with it can. Fixing people "Issues" is not part of the Open Source culture and more of the closed source model, since the whole point of Open Source is so that you can "fix" things yourself without waiting for the vendor. That's why there's "Use at your own risk" everywhere
I applaud his approach, at it demonstrates respect to other developers by explicitly communicating what others can expect of him. Although it's not required, I would hope that all devs who open source a project without any intention of heeding public issue trackers follow suit and proactively clarify that intention.
(Nothing--philosophically or legally--requires anyone to maintain an issue tracker for an open source project. There was a time when open source typically amounted to a tarball on an FTP server, and maybe a -dev list.)
Yes, but those were also the days when it was super painful to contribute to OSS.
The issue tracker can also be used as a roadmap / task manager which is very helpful. The problem isn't the issue tracker. The problem is the developer does not want to maintain everything for everyone. That is perfectly okay so the solution to me is just to communicate that in the project guidelines. To me, not having an issue tracker at all is equivalent to Sublime Text developers dropping off the map for 6 months.
No. You are free to implement the feature yourself and submit a patch to the original author - or fork the project if he doesn't want your patches. That is the point of open source.
That line right there killed any chance of me downloading or trying this. His first three paragraphs cover how he dislikes Sublime Text for some decently noble reasons. Then the first FAQ is about how he is no different. In fact, probably even worse. The idea that he will only work on things 'only he cares about' says this:
Unless I'm you, I wont care about your project either.
I am only trying to help because I like the idea of this project. However, it's the "Patches Welcome" attitude of devs that kills projects. Honestly, after reading this thread and the attitude portrayed, I suspect this project will die with only a handful of users and no maintenance before everyone resorts back to Sublime Text. -- Maybe he doesn't want an active community of users using his software, which is fine. But then why post it on HN?
Exactly. I'm not sure if there are many examples, I can only think of Lua; the authors of Lua don't share their development progress, discussion or version history. They don't take patches but may implement user suggestions. Still, the releases are free and open software.
There's software I'm scared of releasing as open source because I don't want people to have that opinion about it and I know I won't have the resources to properly maintain it. There is software by leading voices in the free software community with much the same rationale -- the LWN website code comes to mind. Meanwhile, Tarsnap releases their code under a non-open-source license, and everyone thinks they're great, underlining the perverse incentives here.
Let's restore a culture where posting a tarball and licensing it and leaving is okay and wonderful, instead of falling short of expectations.
Or if you don't like the dev's approach here, fork the code and turn on issues. I bet if you're more responsive, people will use your fork rather than the original dev's.
While I can understand the sentiment (barely), the way it's written comes off as "F U".
Better might be "I welcome all feature requests but please understand I am one person with a day job. I would be thrilled for anyone to contribute coded features and pull requests.".
I find it a much bigger "F U" to host an issue tracker and completely ignore it (perhaps while you continue development on other features), or worse, close new items out of hand. At least he's taken the time to clarify what can be expected of him. To me, that's a simple show of respect toward the community.
No, it's not a "F U". He created something, he made it available to everyone to download, build, use and extend. On top of all of that, why would he have to apologize to the world because he doesn't want to hear about feature requests from non contributors at this stage of the project.
> Because I'm just a single person and I don't want to offer up my spare time doing support or dealing with feature requests that I don't care about myself [...]
Sort of defeats the point of open source, no? Sublime Text's author could argue a similar case about keeping it closed source himself.